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.

Meetup DigitalOcean Cloud Native architecture

143 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Meetup DigitalOcean Cloud Native architecture

  1. 1. Cloud Native Arquitectura e infraestructura
  2. 2. Infraestructura • Hardware y software que soportan aplicaciones • Data Centers • Sistemas Operativos • Pipelines de despliegue • Administración de la configuración • etc…
  3. 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. 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. 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. 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. 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.
  8. 8. –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.”
  9. 9. Patrones clave en Cloud Native • Resiliency • Service Discovery • Configuration • Logging • Health Checks • Metrics
  10. 10. ¿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
  11. 11. 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.
  12. 12. 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.
  13. 13. Tooling
  14. 14. 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)
  15. 15. 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
  16. 16. OpenTracing • Permite analizar el comportamiento de sistemas distribuidos usando trazas • Instrumentar el código. Existen implementaciones para muchos lenguajes y bibliotecas.
  17. 17. Jaeger • Distributed context propagation • Distributed transaction monitoring • Root cause analysis • Service dependency analysis • Performance / latency optimization
  18. 18. 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
  19. 19. ¿Suena bien?
  20. 20. Pero, no es suficiente…
  21. 21. 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)
  22. 22. Complejo

×