Meetup DigitalOcean Cloud Native architecture
0 recomendaciones246 vistas
El documento describe los conceptos fundamentales de la arquitectura e infraestructura Cloud Native. Explica que la infraestructura Cloud Native oculta la complejidad mediante abstracciones de fácil uso y está administrada por software para permitir escalabilidad y mantenibilidad. También destaca que Cloud Native no se trata solo de ejecutar aplicaciones en contenedores sino de un enfoque particular para diseñar, construir y ejecutar aplicaciones basadas en microservicios e infraestructura como servicio.
Meetup DigitalOcean Cloud Native architecture
- 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