El documento habla sobre Service Mesh y Cloud Native. Cloud Native se refiere a un enfoque para diseñar, construir y ejecutar aplicaciones basadas en infraestructura como servicio e incluye principios como microservicios, automatización, contenedores y orquestación. Un Service Mesh es una implementación de este enfoque que administra el tráfico entre microservicios a través de proxies sidecar, proporcionando funcionalidades como ruteo, monitoreo y seguridad.
8. Cloud Native
• "Cloud Native" es el nombre de un enfoque particular para
diseñar, construir y ejecutar aplicaciones basadas en la
infraestructura como servicio, combinada con nuevas
herramientas y servicios operativos como integración
continua, container engines y orquestadores.
• El objetivo es mejorar la velocidad, la escalabilidad y
finalmente el costo/margen.
• No olvidar: Cloud Native es principalmente sobre como se
diseña y construye, más que en donde se ejecuta.
9. Estrategia Cloud Native
• Se trata de reducir el riesgo técnico.
• En el pasado, el enfoque tradicional para evitar el peligro
era moverse lenta y cuidadosamente.
• El enfoque de Cloud Native se trata de moverse
rápidamente pero tomando pasos pequeños, reversibles y
de bajo riesgo.
• Esto puede ser extremadamente poderoso pero no es
gratis y no es fácil. Es un gran cambio filosófico y cultural,
así como un desafío técnico.
10. Principios arquitecturales
• Infraestructura como servicio: se ejecuta en servidores que pueden
aprovisionarse de manera flexible bajo demanda.
• Diseñar sistemas que los utilicen o evolucionar hacia una
arquitectura de microservicios: los componentes individuales son
pequeños y están desacoplados.
• Automatice y codifique: reemplazar tareas manuales con scripts o
código.
• Containerize: procesa paquetes con sus dependencias, haciéndolos
fáciles de probar, mover e implementar.
• Orquestar: abstraiga los servidores individuales en producción con
herramientas de gestión y orquestación listas para usar.
15. Necesidad
• Las aplicaciones y servicios a menudo requieren
funcionalidades relacionadas, como monitoreo, registro,
configuración y servicios de red.
• Estas tareas periféricas se pueden implementar como
componentes o servicios separados.
• Pueden ejecutarse en el mismo proceso que la
aplicación, haciendo un uso eficiente de los recursos
compartidos.
16. Sidecard Pattern
• http://bit.ly/sidecard-pattern
• Empaquetar un conjunto cohesivo de tareas con la aplicación principal, con su propio proceso o
contenedor, proporcionando una interfaz homogénea para los servicios de plataforma en diversos
lenguajes de programación o runtimes.
17. Ventajas
• Un sidecar es independiente de su aplicación principal en términos de
entorno de ejecución y lenguaje de programación, por lo que no es
necesario desarrollar un sidecar por lenguaje.
• El sidecar puede acceder a los mismos recursos que la aplicación
principal. Por ejemplo, un sidecar puede supervisar los recursos del
sistema utilizados tanto por el sidecar como por la aplicación principal.
• Debido a su proximidad a la aplicación principal, no hay una latencia
significativa cuando se comunica entre ellos.
• Incluso para las aplicaciones que no proporcionan un mecanismo de
extensibilidad, puede usar un sidecar para extender la funcionalidad
adjuntándola como proceso propio en el mismo host o subcontenedor
que la aplicación principal.
19. A pod is a group of one or more
containers, with shared storage/
network, and a specification for how to
run the containers. A pod’s contents
are always co-located and co-
scheduled, and run in a shared context.