Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud Native Mexico Meetup de Marzo 2018 Service Mesh con Istio y Envoy

264 views

Published on

¿porque es necesario un service mesh?

Published in: Technology
  • Be the first to comment

Cloud Native Mexico Meetup de Marzo 2018 Service Mesh con Istio y Envoy

  1. 1. Service Mesh ¿Qué es y para qué me sirve?
  2. 2. Muchas gracias por venir
  3. 3. Gracias a los patrocinadores
  4. 4. Venue/Catering Swag/Cervezas
  5. 5. Cloud Native
  6. 6. ¿Cloud Native?
  7. 7. 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.
  8. 8. 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.
  9. 9. 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.
  10. 10. Mensaje para Miguel: ¡Aprovisiona el cluster de Kubernetes en Google Cloud Platform por favor!
  11. 11. Proxy Pattern • https://en.wikipedia.org/wiki/Proxy_pattern
  12. 12. Containers Sidecard Pattern
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. Kubernetes Pod • http://bit.ly/k8s-pod
  17. 17. 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.
  18. 18. ¿Ideas?
  19. 19. ¿Que será un Service Mesh?
  20. 20. ¿Suena bien?
  21. 21. Pero, no es suficiente…
  22. 22. Features • Administración de tráfico • Ruteo de peticiones • Espejeo (Mirroring) • Inyección de fallas • Service Discovery & Load Balancing • Monitoreo • Traceo distribuido • Métricas •Inyección automática de sidecar (Envoy Proxy)
  23. 23. Demo Time!

×