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 Development in the JVM

247 views

Published on

In this talk, I will talk about what Cloud Native is and why it's important in the design of applications.
I will also address the challenges involved in writing Cloud Native applications in the JVM. The topics in details that will be discussed are:

Microservices arquitecture
Containers
Orchestration
Observability
CI, CD and Continuous Deployment
Security

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Cloud Native Development in the JVM

  1. 1. Cloud Native development in the JVM
  2. 2. Agenda • ¿Que es Cloud Native? • Principios • JVM
  3. 3. 12 factores • Heroku • Circa 2011 • Considera buenos principios de diseño
  4. 4. Varias definiciones •Pivotal ~2015 https://pivotal.io/cloud-native •Container Solutions 2017 •http://container-solutions.com/what-is-cloud-native/ •Information Week 2015 •https://www.informationweek.com/cloud/platform-as-a-service/ cloud-native-what-it-means-why-it-matters/d/d-id/1321539?
  5. 5. Cloud native es un enfoque para crear y ejecutar aplicaciones que aproveche las ventajas del modelo de entrega de Cloud Computing. Cloud native trata sobre cómo se crean e implementan las aplicaciones, no dónde se ejecutan.
  6. 6. "Un enfoque para diseñar, construir y ejecutar aplicaciones basadas en infraestructura como servicio combinadas con nuevas herramientas y servicios operativos como integración continua, motores de contenedores y orquestadores. El objetivo general es mejorar la velocidad, la escalabilidad y finalmente el margen.".
  7. 7. Cloud Native utiliza una stack de software de código abierto para ser: • Containerized: Cada parte (aplicaciones, procesos, etc.) se empaqueta en su propio contenedor. Esto facilita la reproducibilidad, la transparencia y el aislamiento de los recursos. • Dinámicamente orquestado: Los contenedores se programan (scheduled) y gestionan activamente para optimizar la utilización de los recursos. • Orientado a microservicios. Las aplicaciones se segmentan en microservicios. Esto aumenta significativamente la agilidad general y el mantenimiento de las aplicaciones.
  8. 8. Cloud Native 2018 • Declarativo:API declarativas respaldadas por la infraestructura como software (no como código estático) que convergen en un estado deseado. Esto se aplica a infraestructura, políticas, implementaciones de aplicaciones, ¡todo! • Dinámico: debido a la alta tasa de cambio y la realización de implementaciones frecuentes (aplicaciones e infraestructura). • Service Discovery,Testing patterns, Service Mesh, etc.
  9. 9. Cloud Native 2018 • Resiliente: a los cambios y descubrimiento de ambientes. Microservicios es un patrón para esto, pero también puede incluir otras opciones. La flexibilidad permite la fiabilidad, que es el factor más importante de los sistemas complejos • Escalable: las aplicaciones se deben empaquetar de una manera para escalar horizontalmente en lugar de verticalmente. Idealmente, esto sería contenedores pero también puede ser lo que llamaría "contenedores accidentales" para cosas como lambda, motor de aplicaciones o cualquier PaaS donde no empaque explícitamente su código en una unidad ejecutable.
  10. 10. Microservicios “automáticos” • Auto-provisioning: aprovisionamiento automático de entornos “as code”, inmutables. • Auto-scaling: monitoreo/observabilidad de los diversos componentes de tu aplicación y asignación de recursos automáticamente cuando sea apropiado • Auto-redundancy: cloud-native apps son resilientes a la falla. En caso de un problema, el procesamiento de la aplicación se traslada instantáneamente a otro servidor o centro de datos de forma automática y sin problemas.
  11. 11. A considerar • Las operaciones se transformarán en un mundo cloud native • Tus workloads necesitarán ser priorizadas. • Los desarrolladores necesitarán codificar un contrato. • Necesitarás una plataforma ¿construir o comprar?
  12. 12. Cloud Native Infrastructure • Infraestructura “escondida” debajo de abstracciones consumibles por APIs manejadas por software. • Crea una capa nueva responsable de controlar la capa de IaaS que tiene debajo. • Permite escalar, mantener y aprovisionar más fácilmente. • Los patrones influencian no solo a la infraestructura, si no también las aplicaciones y personas que la operan.
  13. 13. ¿Qué no es? • Correr infraestructura en nube pública. • No es correr aplicaciones en contenedores. • No es solo correr un orquestador. • No es microservicios o Infrastructure as code.
  14. 14. Cloud Native Applications Una aplicación cloud native es desarrollada para correr dentro de una plataforma y es diseñada para resiliencia, agilidad, operabilidad y observabilidad.
  15. 15. Características de una aplicación Cloud Native • Microservicios • Reportes de salud • Telemetria • Resiliencia • Declarativo, no Reactivo
  16. 16. Service Mesh
  17. 17. ¿Qué es un Service Mesh? • Es una capa de infraestructura configurable y que está encima de nuestros microservicios. • Nos provee service discovery, load balancing, seguridad entre muchas otras cualidades según la alternativa que usemos. • Usualmente se implemente utilizando proxys (llamados sidecars) en cada uno de nuestros servicios.
  18. 18. Sidecars • Se encarga de las comunicaciones interservicio, monitoreo, seguridad y cualquier cosa que pueda ser abstraída de los servicios individuales. • De esta manera los desarrolladores solo manejan el desarrollo y mantenimiento de las aplicaciones, y las operaciones se mantienen como otra capa.
  19. 19. Alternativas •Linkerd •Conduit •Istio •Consul
  20. 20. Istio ●Load balancing para trafico HTTP, gRPC,WebSocket, y TCP. ●Routing rules, retries, failovers y fault injection. ●Access controls, rate limites y quotas. ●Metricas, logs y trazabilidad. ●Ingress y egress. ●Seguridad servicio a servicio.
  21. 21. Plataformas • Kubernetes • Servicios registrados en Consul • Servicios corriendo enVMs individuales.
  22. 22. Arquitectura • Data plane: Se compone de un set de proxies inteligentes (Envoy) encargados de mediar y controlar toda la comunicación de los microservicios. • Control plane: Maneja y configura los proxies. Configura también a Mixer para verificar que las políticas sean cumplidas y la telemetría sea recolectada.
  23. 23. ENVOY • Es un proxy altamente performante escrito en C++, media la entrada y salida de todo el tráfico. • Es desplegado como sidecar en el mismo pod donde habite cada aplicación.Aprovechando este modelo no es necesario rehacer la arquitectura ni reescribir código.
  24. 24. ¡Nuevas herramientas!
  25. 25. Microservices
  26. 26. Microservices •Propósito único •Unidades de despliegue y operación separadas •Interfaz simple bien definida •Modular e independiente •Persistencia aislada •Reemplazable sobre mantenible •Ideal para grandes sistemas
  27. 27. Los microservices no son más que SOA hecho correctamente
  28. 28. Principios de arquitectura • Un microservice es un componente de despliegue independiente, de alcance limitado que admite la interoperabilidad a través de la comunicación basada en mensajes. • La arquitectura de microservices es un estilo de ingeniería de sistemas de software altamente automatizados y orientados a alta disponibilidad.
  29. 29. Principios • Pequeño en tamaño (Subjetivo) • Mensajería habilitada • Limitado por contextos • Desarrollado de forma autónoma • Desplegable de forma independiente • Descentralizado
  30. 30. Más sobre Arquitectura • En una arquitectura de microservices, los servicios tienden a ser más simples, pero la arquitectura tiende a volverse más compleja. • Esa complejidad a menudo se administra con herramientas, automatización y procesos. • Es un hecho que el control y la administración de un sistema de microservices es más costoso que en otros estilos arquitectónicos.
  31. 31. ¿Alguien haciendo Microservices?
  32. 32. ¿y la JVM apá?
  33. 33. Micronaut • Compile timeVS runtime • Modelo de programación conocido • Cloud Native features • Service Discovery • Load Balancing • Observability • Distributed tracing
  34. 34. Demo

×