Microservicios

notas del libro Microservices Patterns,Chris Richardson, capítulo 1 y 2.

Lo primero es entender que existen varias dimensiones en la arquitectura de software, es decir un sistema puede estar usando varias arquitecturas al mismo tiempo por ejemplo una arquitectura de micro-servicios con arquitectura hexagonal, o una arquitectura monolítica con arquitectura de 3 capas.para explicar esto el autor usa las 4+1 vistas y un escenario y un sistema de coordenadas x,y,z para representar las diferentes dimensiones de la arquitectura.

una arquitectura de micro-servicios es una arquitectura en la que la aplicación está generada por múltiples servicios independientes y desacoplados(cuando se dice que los servicios deben ser desacoplados en una arquitectura de micro-servicios esto significa que los servicios deben comunicarse por api y que cada servicio debe tener su propia base de datos)

y una arquitectura monolítica es una arquitectura de aplicación con un solo desplegable/ejecutable.

la arquitectura de micro-servicios tiene como es usual ventajas y desventajas que el autor explica en 3 partes

1. las fortalezas de la arquitectura o lo bueno que trae
2. el contexto resultante o como queda el sistema después de aplicar la arquitectura con que debilidades y que fortalezas
3. y los patrones relacionados como un diagrama en el que se relaciona que otro patrón podría reemplazar a esta/cubrir sus problemas/ mejorarlo/o si este patrón es mejora de otro.
   

Para él es claro que si una empresa startup está empezando es mejor que esta empieze con una arquitectura monolítica y luego realiza el refactor a un arquitectura de micro-servicios. 

en qué punto hacer ese refactor es una línea delgada pero hay indicadores para reconocerlo por ejemplo.

• si el equipo de desarrolladores son muchos +7 seguramente tiene mas sentido dividir las responsabilidades, para con esto balancear el costo de la comunicación entre tantas personas es muy improductivo
• si la base de código es muy compleja y no le cabe en la cabeza a una sola persona, seguramente implica que no la deba trabajar una sola persona sino dividirla para diferentes partes las trabajen diferentes personas
• cuando la cantidad de usuarios es muy alta y el escalamiento es muy complejo. por ejemplo por que una parte de la aplicación requiere mucha memoria por una in-memory database, otra tiene una red neuronal y requiere gpu etc. escalar es complejo porque cada instancia de la aplicación va requerir la suma de recursos que necesita la app como todo para correr
  

Incluso con estos indicadores mutar o irse del monolito a una arquitectura de micro-servicios es peligroso y puede salir mal en el peor de los casos se termina con un monolito distribuido un engendro que suma las desventajas del monolito y las desventajas de los micro-servicios. 

Al mismo tiempo y siendo complejo en cierto punto hace más sentido realizar micro-servicios porque la curva exponencial para realizar entregas en el monolito se vuelve insostenible, y muchas empresas que han escalado mucho muchísimo lo han podido hacer por las capacidades que les proporciona una arquitectura de micro-servicios.

el autor recomienda juntar micro-servicios con una arquitectura hexagonal(o de puertos y adaptadores) pues esta encaja bien con DDD( domain driven design) que al mismo tiempo encaja muy bien con la división de un servicio monolito en micro-servicios, en otras palabras un triángulo virtuoso.

y describe 3 pasos generales para cambiar de una arquitectura monolítica a una micro-servicios.

1. reconocer los procesos que realiza la organización(estos se traducen usualmente a llamados o endpoint rest)
2. Reconocer los servicios: a través de los procesos fundamentales de la organización oa través de subdominios identificados por DDD.
3. identificar las api. es decir las interfaces de comunicación(de los servicios o atravesar de llamadas rest o eventos por mensajería)
   

yo creo que  plantear una arquitectura de micro-servicios es inevitable en cierto momento cuando las organizaciones crecen y su modelo de negocio tiene una base tecnología, y aunque tiene muchas complejidades lo único que queda es hacerlo lo mejor posible para no terminar solo con desventajas y/o más problemas

Helm plantillas para los recursos de kubernetes

Ya de por sí tener kubernetes si se usa con archivos que nos definan los recursos de infraestructura es un gran ventaja por que tenemos una forma replicable, usualmente versionada de la infraestructura que nos permite rastrear errores con facilidad. 

Los desarrolladores en general van y siguen automatizando/generalizando más para ganar velocidad y evitar que con la réplica de copiar/pegar se generen errores inesperados en este caso en la definición de recursos de kubernetes.

Es que un problema que puede ser frecuente es tener un recurso desplegado en algún proveedor de nube que debemos definir para un ambiente de desarrollo y para un ambiente de producción, usualmente con pequeñas diferencias como:

• en uno se puede estar usando una url diferente
• tener habilitado un mecanismos de seguridad adicional en producción
• usar un espacio de nombres diferentes
  

Al final es como si tuviéramos un plano del recurso y en puntos específicos quisiéramos definir valores dependendiendo de lo que necesitamos del recurso y esto es lo que permite hacer helm

Una forma de definir plantillas para los recursos de kubernetes que podemos aplicar con diferentes valores usualmente una para cada ambiente pero también una sola plantilla se puede estar usando múltiples veces para un recurso del mismo tipo en el mismo ambiente por ejemplo si un equipo realiza spring-boot.

para definir un recurso de esta manera lo primero es definir un chart que nos permite colocar entre otras cosas un nombre,una descripción, quienes mantienen esta plantilla etc
(Chart.yaml)

apiVersion: v2

name: <the-name>

description: <the description>

version: 1.0.0 # chart version

Luego creamos una carpeta templates y dentro definimos nuestro recurso o recursos de kubernetes con la ubicación de los valores que vamos a definir en otros archivos. incluso podemos colocar condiciones if para que dado que un valor se defina una configuración o no
templates/<uno o muchos archivos>.yaml

{{ .Values.host }} # para obtener valores de la definicion de values que

 tengamos

{{- if .Values.tls.enabled }}

{{- end }} # hay que tener cuidado respetando la indentacion 

nos permite poner definiciones dinamicas solo si es true el 

codigo en el medio entre if y end se agrega 

 

finalmente definimos un archivo de valores que se van a aplicar a nuestros templates
(values-xxx.yaml)

host: dev.example.com

tls:

enabled: false

para instalar esta definición con nuestra plantilla podemos usar el comando(previo a estar conectado a nuestro cluster sea el proveedor de nube o un cluster corriendo en la maquina propia como minikube)

$ helm install -f <whatever-name> values-xxx.yaml .

instalar el nombre que le pongamos el archivo values qué le vamos a aplicar a la plantilla con el . osea chart en el directorio actual
y si realizamos algún cambio sea en las plantillas o en los valores después de haberlo instalado podemos actualizarlo con 

$ helm upgrade -f <whatever-name> values-xxx.yaml .

Otra herramienta en la misma línea de helm es kustomize. helm se recomienda para aplicaciones propias en las que buscamos definir todo mientras kustomize se recomienda cuando vamos a definir despliegue de aplicaciones de terceros a las que solo queremos sobrescribir pequeños detalles con la configuración propia(por ejemplo una url).