Charla impartida en el Meetup de DigitalOcean México, sobre arquitectura Cloud Native

1. Cloud Native
Arquitectura e infraestructura

2. Infraestructura
• Hardware y software que soportan aplicaciones
• Data Centers
• Sistemas Operativos
• Pipelines de despliegue
• Administración de la configuración
• etc…

3. Infraestructura Cloud Native
(Antecedentes)
• 12-Factor Applications de Heroku (Referente)
• Principalmente es sobre hacer que los devs sean
eficientes al permitir separar la lógica de los datos,
automatizando lo más posible, creando diferentes
ambientes para para construcción, distribución y
ejecución.

4. Infra Cloud Native
• Infraestructura que esta oculta mediante una abstracción con un API de
fácil uso.
• Estas abstracciones a menudo imponen limitaciones sobre las diversas
tecnologías.
• Administrada por software. Habilita escalamiento, resiliencia,
aprovisionamiento y mantenibilidad.
• No es correr tus cargas de trabajo en la nube pública.
• No es ejecutar aplicaciones en contenedores. Ni que sean Microservicios.
• Mucho menos es utilizar un orquestador de contenedores (Mesos/
Kubernetes)

5. 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.

6. 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.

7. 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.
• Telemetría y salud: La aplicación es responsable de proveer un mecanismo para
determinar si esta disponible o si su estado es optimo (saludable), de igual forma
debe permitir obtener métricas clave sobre su funcionamiento.
• 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.

9. –Domingo Suarez Torres
“Cloud Native no es una solución a todos los
problemas, las organizaciones deben conocer su
alcance y tomar lo que es mejor para ellas.”

10. Patrones clave en Cloud Native
• Resiliency
• Service Discovery
• Configuration
• Logging
• Health Checks
• Metrics

11. ¿Como implementar dichos Patrones?
• ¿Bibliotecas?
• No olvidar que con Microservices es común y en
ocasiones recomendado en ocasiones, tenerlos escritos
en diversos lenguajes de programación.
• Hay que buscar bibliotecas para cada lenguaje de
programación.
• Sidecar

12. Sidecar 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.

13. 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.

14. Tooling

16. Kubernetes
• Orquestar todo el ciclo de vida de contenedores
• Docker
• rkt
• Linux Container
• Administra recursos de nodos (VMs)
• Basado en 16 años de experiencia de Google (Borg)

18. Prometheus
• Extrae métricas de nuestros componentes (Exporters)
• Base de datos de series de tiempo
• Lenguaje de consultas muy poderoso
• Gestionar alertas
• Delega la creación de dashboards a herramientas
externas como Graphana

20. OpenTracing
• Permite analizar el comportamiento de sistemas
distribuidos usando trazas
• Instrumentar el código. Existen implementaciones para
muchos lenguajes y bibliotecas.

22. Jaeger
• Distributed context propagation
• Distributed transaction monitoring
• Root cause analysis
• Service dependency analysis
• Performance / latency optimization

24. gRPC?
• Stands for ‘gRPC Remote Procedure Call’
• Open source project from Google hosted by the Cloud Native
Computing Foundation
• High Performance, general purpose standard base, RPC
framework.
• Open sourced of ‘Stubby RPC’ at Google

28. ¿Suena bien?

29. Pero, no es suficiente…

33. 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)

35. Complejo