Servicios de aplicaciones nativas de contenedores

Un número cada vez mayor de servicios de aplicaciones son un componente integral de una arquitectura nativa de la nube. Esta es, en parte, la razón por la que observamos un cambio en la responsabilidad de los servicios de aplicaciones, desde las operaciones de TI hacia DevOps.

Realizamos un seguimiento de más de 30 servicios de aplicação diferentes en nuestra investigación sobre el estado de los servicios de aplicaciones . Hay más y cada año revisamos la lista para determinar qué eliminar y qué agregar.

Para 2020, consolidamos varios servicios de aplicaciones en categorías más amplias. Por ejemplo, el firewall de red, el antispam, IPS/IDS y la mitigación de spam se agregaron en "servicios de seguridad comunes".  Decidimos adoptar este enfoque por dos razones. En primer lugar, porque seis años de datos indicaron agrupaciones de servicios de aplicaciones con tasas de implementación muy similares. En segundo lugar, porque queríamos hacer espacio para los servicios de aplicaciones emergentes y no queremos abrumar a nuestra base de encuestados, que ya es muy paciente.

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 entregar una aplicação nativa de la nube. Piense en control de ingreso, descubrimiento de servicios y malla de servicios. Las puertas de enlace API también suelen estar estrechamente relacionadas con las aplicações nativas de la nube, aunque su uso está ampliamente alineado con cualquier aplicação basada en API.

Dada su creciente importancia para la entrega de aplicaciones modernas nativas de la nube y las increíbles tasas de implementación que estamos viendo, parece un buen momento para brindar algo de información sobre estos campeones de los enfoques nativos de la nube.

Control de ingreso

Estado de la implementación de servicios de aplicação 2020: Control de ingreso

El control de ingreso es un concepto introducido en el mundo de Kubernetes para segmentar y dividir las solicitudes HTTP. Permite a los operadores asignar fácilmente una URI a un servicio de Kubernetes específico. Esto permite el enrutamiento de solicitudes entrantes (de ingreso) a la instancia de microservicio correcta.

Este no era un concepto nuevo. Los lectores ávidos recordarán que a menudo elogio las virtudes del enrutamiento HTTP (Capa 7), particularmente como un componente arquitectónico diseñado para ayudar en estrategias de escalamiento más eficientes. Si no lo recuerdas o recién te unes a nosotros, esta conferencia magistral es un buen repaso: Entonces ¿crees que puedes escalar?

Lo novedoso es el modo en que se gestionan los “mapas”. Los controladores de ingreso deben actualizarse dinámicamente en función de las condiciones actuales dentro de un clúster de contenedores. Esto significa que un controlador de ingreso necesita tener visibilidad del estado actual de un clúster. Esto significa integración con los componentes apropiados de Kubernetes a través de su API operativa.

Esta integración es lo que vincula el control de ingreso al entorno y, por lo tanto, lo incorpora a la arquitectura de la aplicación. Un controlador de ingreso completamente funcional es inherentemente "nativo del contenedor" porque es parte de la infraestructura necesaria para escalar y operar una aplicação nativa de la nube. 

Descubrimiento de servicios

Estado de la implementación de servicios de aplicação 2020: Descubrimiento de servicios

Un dato interesante sobre las aplicações nativas de la nube es la vida útil de sus partes compuestas. La naturaleza dinámica de la escalabilidad dentro de un clúster de contenedores significa necesariamente que los "contenedores" están en constante cambio. Los últimos datos de Sysdig muestran cantidades crecientes de flujo: el 39 % de los contenedores viven menos de un minuto y el 54 % vive menos de cinco minutos.

El problema con esto es que otros componentes necesitan poder encontrar esos contenedores.

Ésta es la razón de ser del componente de descubrimiento de servicios . Estos componentes se ejecutan dentro del clúster de contenedores y sirven como "fuente autorizada" para los servicios. Las partes interesadas pueden consultar este componente para descubrir 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 aborda la volatilidad de un clúster y permite que otros componentes, como el control de ingreso, funcionen correctamente. 

Malla de servicios

Estado de la implementación de servicios de aplicação 2020: Malla de servicios

Service Mesh es probablemente el servicio de aplicaciones nativo de contenedores más controvertido . No por su valor conceptual, sino por preferencias de implementación. Las mallas de servicio están diseñadas para abordar problemas de visibilidad, escala y seguridad dentro de los clústeres de contenedores. Se implementan como proxies hiperconectados (sidecar o por aplicación) y ofrecen una variedad de funciones tanto para desarrolladores como para operadores.

Una malla de servicios no es un servicio de aplicação que encontrará fuera de un clúster de contenedores. Al igual que el descubrimiento y el control de ingreso, una malla de servicios está íntimamente integrada con el entorno de contenedores. Esto también lo convierte en un servicio de aplicación nativo del contenedor. 

Servicios de aplicaciones nativas de contenedores

Nosotros (la industria y la corporación) nunca hemos categorizado los servicios de aplicação de esta manera antes. Ciertamente, los categorizamos según su uso principal: seguridad, disponibilidad, rendimiento, movilidad e identidad. Pero estas son categorías de uso amplias y ninguna es exclusiva de la arquitectura de una aplicación.

Pero la integración y las dependencias de una arquitectura nativa de la nube pueden hacer que sea necesario hacerlo para 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 la aplicación) indica claramente el crecimiento del otro (la arquitectura de la aplicación), y viceversa. Se trata de una situación única, en la que los servicios de aplicaciones y las aplicaciones están tan íntimamente entrelazados que ambos tendrán tasas de implementación muy similares. 

De la misma forma que distinguimos entre aplicaciones móviles iOS y Android, puede resultarnos útil etiquetar aquellos servicios de aplicaciones diseñados para operar solo dentro de un entorno en contenedores como "nativos del contenedor", en comparación con aquellos que operan en cualquier otro lugar.

Independientemente de cómo los clasifiquemos, definitivamente están en aumento, junto con las aplicaciones que dependen de ellos.