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

1. Cloud Native
development in the JVM

2. Agenda
• ¿Que es Cloud Native?
• Principios
• JVM

3. 12 factores
• Heroku
• Circa 2011
• Considera buenos principios de diseño

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

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

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

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

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

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

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

14. 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?

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

16. ¿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.

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

18. Características de una
aplicación Cloud Native
• Microservicios
• Reportes de salud
• Telemetria
• Resiliencia
• Declarativo, no Reactivo

19. Service Mesh

20. ¿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.

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

22. Alternativas
•Linkerd
•Conduit
•Istio
•Consul

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

24. Plataformas
• Kubernetes
• Servicios registrados en Consul
• Servicios corriendo enVMs individuales.

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

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

29. ¡Nuevas herramientas!

32. Microservices

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

34. Los microservices no son
más que SOA hecho correctamente

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

36. Principios
• Pequeño en tamaño (Subjetivo)
• Mensajería habilitada
• Limitado por contextos
• Desarrollado de forma autónoma
• Desplegable de forma independiente
• Descentralizado

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

38. ¿Alguien haciendo Microservices?

41. ¿y la JVM apá?

44. Micronaut
• Compile timeVS runtime
• Modelo de programación conocido
• Cloud Native features
• Service Discovery
• Load Balancing
• Observability
• Distributed tracing

45. Demo