Servicios de aplicaciones nativos de contenedores

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Cada vez más servicios de aplicaciones son un componente integral de una arquitectura nativa de la nube. Esto explica, en parte, por qué observamos que la responsabilidad sobre estos servicios está pasando de las operaciones de TI a DevOps.

Hacemos un seguimiento de más de 30 servicios de aplicaciones diferentes en nuestro estudio «Estado de los servicios de aplicaciones». Hay más y, cada año, revisamos la lista para decidir cuáles eliminar y cuáles añadir.

Para 2020, agrupamos varios servicios de aplicaciones en categorías más amplias. Por ejemplo, el cortafuegos de red, la protección antispam, los sistemas IPS/IDS y la mitigación del spam se englobaron en «servicios de seguridad comunes». Adoptamos este enfoque por dos motivos. En primer lugar, porque seis años de datos revelaron grupos de servicios de aplicaciones con tasas de implantación muy similares. En segundo lugar, porque queríamos dejar espacio para los nuevos servicios de aplicaciones y no sobrecargar a nuestra ya de por sí muy paciente base de encuestados.

Estos servicios de aplicaciones emergentes son casi exclusivamente servicios de aplicaciones nativos de contenedores. Por lo general, aunque no siempre, se implementan como parte del entorno operativo necesario para ofrecer una aplicación nativa de la nube. Pensemos en el control de entrada, la detección de servicios y la malla de servicios. Las puertas de enlace de API también suelen estar estrechamente vinculadas a las aplicaciones nativas de la nube, aunque su uso se adapta en general a cualquier aplicación basada en API.

Dada su creciente importancia para ofrecer aplicaciones modernas nativas de la nube y las increíbles tasas de implantación que estamos observando, parece un buen momento para aportar algo más de contexto sobre estos referentes de los enfoques nativos de la nube.

Control de entrada

Implementación del informe «Estado de los servicios de aplicaciones 2020»: control de entrada

El control de entrada es un concepto introducido en el mundo de Kubernetes para segmentar y gestionar las solicitudes HTTP. Permite a los operadores asignar fácilmente un URI a un servicio específico de Kubernetes. Esto permite dirigir las solicitudes entrantes (ingress) a la instancia de microservicio adecuada.

No se trataba de un concepto nuevo. Los lectores habituales recordarán que suelo ensalzar las virtudes del enrutamiento HTTP (capa 7), especialmente como componente arquitectónico concebido para facilitar estrategias de escalado más eficientes. Si no lo recuerdas o acabas de incorporarte, esta ponencia magistral te servirá para ponerte al día: ¿Así que crees que puedes escalar?

Lo novedoso es la forma en que se gestionan los «mapas». Los controladores de entrada deben actualizarse dinámicamente en función de las condiciones actuales dentro de un clúster de contenedores. Esto significa que un controlador de entrada debe tener visibilidad del estado actual del clúster, lo que requiere integrarlo con los componentes adecuados de Kubernetes a través de su API operativa.

Esta integración es lo que vincula el control de entrada al entorno y, por tanto, lo integra en la arquitectura de la aplicación. Un controlador de entrada plenamente funcional es intrínsecamente «nativo de contenedores», ya que forma parte de la infraestructura necesaria para escalar y operar una aplicación nativa de la nube.

Descubrimiento de servicios

Estado de la implementación de servicios de aplicaciones en 2020: descubrimiento de servicios

Un dato interesante sobre las aplicaciones nativas de la nube es la vida útil de sus componentes. La naturaleza dinámica de la escalabilidad dentro de un clúster de contenedores implica necesariamente que los «contenedores» cambian constantemente. Los últimos datos de Sysdig muestran un aumento de esta volatilidad: el 39 % de los contenedores dura menos de un minuto y el 54 %, menos de 5 minutos.

El problema es que otros componentes deben poder encontrar esos contenedores.

Esta es la razón de ser del componente de descubrimiento de servicios, que se ejecuta dentro del clúster de contenedores y actúa como «fuente autorizada» de los servicios. Las partes interesadas pueden consultarlo para averiguar cómo conectarse y comunicarse con un servicio determinado. Al realizar un seguimiento de los servicios en tiempo real, el componente de descubrimiento de servicios hace frente a la volatilidad del clúster y permite que otros componentes —como el control de entrada— funcionen correctamente.

Malla de servicios

Estado de la implementación de servicios de aplicaciones en 2020: malla de servicios

La malla de servicios es probablemente el más controvertido de los servicios de aplicaciones nativas de contenedores. No por su valor conceptual, sino por las preferencias de implementación. Las mallas de servicios están diseñadas para abordar problemas de visibilidad, escalabilidad y seguridad dentro de los clústeres de contenedores. Se implementan como proxies hiperconectados —ya sea como sidecars o por aplicación— y ofrecen diversas funcionalidades tanto para desarrolladores como para operadores.

Una malla de servicios no es un servicio de aplicaciones que se encuentre fuera de un clúster de contenedores. Al igual que la detección y el control de entrada, una malla de servicios está estrechamente integrada en el entorno de contenedores. Esto hace que también sea un servicio de aplicaciones nativo de contenedores.

Servicios de aplicaciones nativos de contenedores

Nosotros (tanto el sector como la empresa) nunca habíamos clasificado los servicios de aplicaciones de esta manera. Por supuesto, los clasificamos según su uso principal: seguridad, disponibilidad, rendimiento, movilidad e identidad. Pero estas son categorías de uso generales y ninguna es específica de una arquitectura de aplicaciones.

Sin embargo, la integración en una arquitectura nativa de la nube y las dependencias respecto a ella pueden hacer necesario clasificar de este modo estos servicios de aplicaciones (y cualquier otro que pueda surgir en el futuro). Esto se debe a que el crecimiento de uno (el servicio de aplicaciones) indica claramente el crecimiento del otro (la arquitectura de aplicaciones), y viceversa. Se trata de una situación única, en la que los servicios de aplicaciones y las aplicaciones están tan estrechamente vinculados que ambos registrarán tasas de implantación muy similares.

Del mismo modo que distinguimos entre las aplicaciones móviles para iOS y Android, puede resultarnos útil etiquetar como «nativos de contenedores» aquellos servicios de aplicaciones diseñados para funcionar únicamente en un entorno de contenedores, frente a los que funcionan en cualquier otro entorno.

Independientemente de cómo los clasifiquemos, está claro que están en auge, al igual que las aplicaciones que dependen de ellos.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie