Sharing data between microservices

 

Since I started working with microservices, I learned a lot of basic rules like:

 

•        The microservices must be isolated.
•        The microservices must be small and they must have only one responsibility into business.
•        The microservices must be developed by isolated and multidisciplinary teams.
•        The only way to access to microservice business is using the API.
•        One database can´t be shared by two microservices.

 

And about this last rule I want to discuss because, in my opinion, there are a lot of points of view we have to keep in main to reach the best approach that fits to our company. Everybody agrees that only one microservice can modify the data in one data base but … Who bad would it be if each microservice will be able to read all databases that the microservice need?

 

One rule said that API is the only one microservice contract but if the development team are using the same technology to implement the microservices then microservices develop teams can sign other contracts like libraries that other  microservices develop teams can use it for accessing the data directly without access to the API.

 

Keep in mind, nowadays, the databases technology has a high performance and the databases are implemented with a great users connection capacity. If we only have a one application (the microservice) using the database then we are losing the database performance. In addition, the connection that should be used by other microservices are read only connections. It means that other improvement more because the connection will be read only.

 

Then, may be, the two contracts case would be able to much bad idea.

 

I am going to describe the “two contracs case” by JAVA implementation library. A common communication between microservices would be:

 

 

 

If microservice client “data layer - read” is treated like an API then no development teams lose their independency only sing a other contract. “two contracts case” would be:

 

 

How you can see in the pictures, the sales microservice saves the book microservice call and use the same library to get the books data (the microservice books development team is free to make any change). This solution allows to keep the low couple and avoid inconsistency data (only the owner can write data into database).

 

In conclusion, I know  “two contracts case” is anti-pattern microservice but it would be able to fit to your environment and solve the performance issues. If the  “two contracts case” doesn’t fit your environment at least I recommend you using CQRS but you should not create a view or using other data base. Use the same database for both microservices where one microservice can read/modify data and the other microservice is a query microservices.

 

Jenkins para gestión de despliegues en Kubernetes. ¿Desplegar el Jenkins dentro del cluster de kubernetes o fuera del cluster?

No cabe duda de que Jenkins es la opción numero 1 cuando se piensa en automatizar el despliegue de aplicaciones en un clúster Kubernetes. Existen cada vez más opciones (aparte de Jenkins) y más orientadas a Kubernetes Jenkins (Jenkins esta para automatizar cualquier cosa). En este post particularizo en Jenkins, pero los puntos que se exponen a continuación se pueden extrapolar a la mayoría de los mecanismos de automatización.

Cuando una empresa piensa en automatizar sus tareas de desarrollo con Jenkins y tener una estrategia de CI/CD para despliegue en un clúster de Kubernetes una de las primeras preguntas es ¿El Jenkins se despliega en un pod dentro de algún namespace del clúster de Kubernetes o fuera del cluster de kubernetes con alguna otra solución?

Vamos a analizar puntos relevantes para tomar esta decisión

Modo de instalación y mantenimiento

Para desplegar en Jenkins en el cluster de Kubernetes se deberán crear los ficheros que creen los objetos Kubernetes correspondientes (deployment, Pod, configmaps,etc..) mientras que en una maquina fuera del cluster de kubernetes se puede instalar de cualquier manera (incluso usando tecnologías de contenedores como docker que utilizan métodos parecidos a los usados por Kubernetes). Por lo que este punto las cuestiones son:

• Se va a usar imágenes para las aplicaciones de mi negocio (ya que se quieren desplegar en un cluster de kubernetes) pero ¿quiero una solución basada en imágenes para todos los elementos de TI? Recordemos que Jenkins no es para negocio, es para los técnicos.
• ¿Existe alguna normativa en la empresa que me obliga a seguir un procedimiento determinado? ¿Ese procedimiento es incompatible con el despliegue en un clúster de kubernetes?
• El equipo técnico ¿se tiene más conocimiento en algún tipo de instalación diferente al de kubernetes y se identifica como más fiable?
• Analizar el mantenimiento de Jenkins como aplicación (ampliar recursos, plugin, tolerancia a fallos, etc..). Tras analizarlo ¿se ajusta mejor desplegarlo en un clúster de kubernetes o fuera del clúster de kubernetes?

Explotación

En este punto si que estoy claramente en contra de desplegar Jenkins en el clúster de kubernetes (pero esta es mi opinión y pude no ajustarse a la realidad de la organización) por los siguiente:

• En un clúster de kubernetes, por regla general, se deben desplegar aplicaciones que sigan la filosofía de microservicios (es decir, ligeras que van a requerir escalado, etc..) y Jenkins no sigue dicha filosofía.
• En un clúster de kubernetes, los pods luchan por lo recursos y Jenkins es una aplicación que va a “dar guerra” cuanto mas se use por lo que no se puede justificar el hecho de que no funcione una aplicación en el clúster de kubernetes porque esta Jenkins.

 Continuidad del servicio de Jenkins

Este punto cabria en el anterior, pero me lo he encontrado en tantas ocasiones cuando he tenido que implantar Jenkins en una organización que prefiero destacarlo a parte. Si se cae el clúster de kubernetes ¿Merece la pena que siga funcionando Jenkins? La respuesta es sí por dos grandes motivos:

• No todas las tareas que se incluyan en Jenkins tienen porque actuar sobre el clúster de kubernetes por lo que si desplegamos Jenkins en el cluster de kubernetes estamos perdiendo esa funcionalidad.
• Los clústeres de kubernetes son un sistema muy robusto y raramente he visto un cluster de kubernetes caerse. El clúster de kubernetes, antes de caerse, hace que las aplicaciones no funcionen (los famosos estados “Evicted” de los pods) por falta de recursos. Pero se puede seguir trabajando con ellos. Es decir, si Jenkins esta desplegado en un clúster de kubernetes y este cluster entra en este estado entonces Jenkins no funcionaría, pero si estuviera fuera del cluster de kubernetes podría seguir trabajando con Jenkins y Jenkins atacando al cluster de kubernetes. El gran problema sería que no veríamos las aplicaciones que Jenkins a desplegado en el clúster de kubernetes, pero estas aplicaciones están declaradas en el cluster y una vez solucionado el problema de los recursos del cluster de kubernetes todo funcionar correctamente, por lo que nunca se ha perdido la funcionalidad.

 

Conclusion

El negocio y los programadores

Durante el desarrollo de una aplicación software desde cero, los programadores suelen centrarse en las tareas técnicas muchisimo mas que en entender la funcionalidad de la aplicación. Esto provoca que muchas veces los programadores no sepan como afrontar desarrollos cuando el gestor piensa que si que podrian ya que han hecho en el pasado desarrollos parecidos.

Este efecto no pasa con aplicaciones en mantenimiento ya que la necesidad de innovar, inventar, etc.. es menor. Suelen ser todas las tareas sota, caballo y rey. Esto abre la mente de los programadores a problematica mas funcional.

Formar un equipo de desarrollo

Cuando te encuentras en mitad de un nuevo desarrollo (una aplicacion nueva) y el procesa avanza y ves que faltan "manos" (necesitas mas programadores), lo primero que viene a la cabeza es que necesitas una persona que ya tenga experiencia en desarrollos y esto se acentúa si el proyecto usa tecnologias muy nuevas. Este es la deducción mas logica pero ojo con esto porque una persona con experiencia tiene cosas buenas:

- Ha pasado batallas y sabe como afrontarlas. Trabaja mas con presión.
- Programan mas rapido y un software de mayor calidad.
- Ect..

pero tienen cosas que pueden no aportar en el desarrollo:

- No estar de acuerdo con demasiadas cosas. Esto no deberia ser malo pero si es malo cuando la actitud es derrotista o catastrofista.
- Ser muy rigido en su forma de trabajar ya que si tiene que adaptar otra forma puede ponerse a la defensiva ya que se ve como un junionr.
- Etc..

Respecto a la nueva tecnologia, lo bueno es:
- Curva de aprendizaje baja (o no necesaria).
- Aporta conocimiento al grupo.
- Programara mas rapido

pero lo malo es

- marcar pautas y no justificarse lo suficiente. Al ser el conocedor de la tecnologia se usan frases como "es asi porque es asi" o " esto esta mal" o "esto es un desastre" y no decir nada mas. En general, no justificar porque toma decisiones.

- olvidarse del trabajo en equipo.


En resumidas cuentas, una persona con experiencia y/o conocimiento de las nuevas tecnologias te puede venir bien en el equipo pero te puede venir mal. Lo que nunca hay que perder de vista que sea una persona constructiva y que no olvide que somos un equipo que tenemos que entregar un trabajo (una aplicacion que alguien tiene que usar).

Pro mucho que no nos guste, no somos artistas y la gente no nos va a pagar por algo que puede estar muy bien hecho pero lo importante es que funcione.

Estado real del proyecto.

A lo largo del desarrollo (sobre todo si es durante un periodo largo) algun stakeholder (normalmente algun jefe) querra conocer el estado del proyecto y en ese momento es dificil dar una respuesta sencilla ya que al avanzar muchos frentes a la vez no se puede especificar con claridad, pongamos un ejemplo en el que tenemos 4 funcionalidades que implementar (empleados, costes, informes y ventas) y cada funcionalidad esta en nivel distinto de desarrollo como muestra la grafica:

¿Cual el estado?

Una funcion que indica el grado de avance de todo

El mas retrasado

Etc.. Hay muchas posibilidades pero realmente nunca es cuestion de que eleccion usemos sino que es cuestion de como espera los stakeholders que le indiquemos la información. Este punto es muy importante porque ofrece mucha informacion:

• Sabemos cuales son las partes que tienen mas valor para los stakeholders.
• Necesitamos buscar un leguaje comun con los stakeholders.
• Se necesita un integrador que se preocupe no solo de poder definir el estado del proyecto, ademas se encargue de encajar todas las piezas que definen el proyecto.

Muchas veces tenemos casos como el siguiente:

• Todo empleados funcionando y costes esta parado porque no tiene una parte que depende de empleados. Pero si empleados esta todo acabado ¿que esta pasando?

En casos como este, es la figura del integrador en que entra en juego. Un integrador es la persona capaz de saber que costes podria estar terminado ya que sus depedencias estan resultas. Si al integrar se detecta un fallo es el integrador el que busca a los implicados y los coordina para que solucionen el problema.

Un integrador es la persona que puede decir el estado del proyecto.

La politica de la gestión de desarrollo

De las partes mas simples es facil hablar mientras que de lo mas complicado se suele confiar en una persona que sabe hacerlo. Por ejemplo, si un equipo tiene que definir si el color azul es mejor que el verde para el fondo de una pagina web nos podemos tirar horas debatiendo y opinara desde el becario hasta el jefe de proyecto pero si tenemos que hablar de la mejor solucion para la "arquitectura de comunicaciones" seguramente solo opinen dos personas del proyecto y la mayoria de personas de del desarrollo no diran nada y esperaran que otro lo solucione.

Es como la politica, la mayoria de gente quiere opinar y ver que su opinion se tiene en cuenta pero no van a ser ellos lo que van a gobernar. Lo dificil que lo haga otro.

Una solucion muy politica para mentener un buen ambiente de trabajo en e desarrollo es observar la mayoria de opiniones triviales que suele tener el equipo y aplicarlas ya que:

- No suelen tener gran impacto.
- Te permiten decidir lo realmente importante a los gestores del equipo.
- Da la sensacion a los miembros del equipo (que no es solo una sensacion es cierto) de que han puesto su granito de arena.

Mantener la coherencia en el estilo del desarrollo

Cuando se empieza un desarrollo de proyecto de software esta implícito que el grupo de programadores va a programar el software que se desea conseguir. Cuando el software es medianamente grande te das cuenta de que no vale con que el programador consiga terminar una tarea, ademas debe:

• Seguir las normas que se han establecido para programar.
• Seguir la arquitectura que se haya definido.
• Tomar la decision correcta ante una situación que aunque no este especificada expresamente se deduce a partir de los puntos anteriores. 

Si no se resuelven estos puntos entonces al final el software es un conjunto de miles de tareas cuyo conjunto no hacen lo que queríamos al planificarlo al principio.

Es imposible conseguir que un grupo de programadores programen igual pero ¿Como hacer que varios programadores sigan unas normas?

La mejor solucion consiste en tener un integrador en el equipo que compruebe que se siguen las normas y si no se siguen las normas se le indica al programador y lo apunta en una lista que ira rellenando de semana en semana. Cada semana se debe juntar con el equipo y repasar dicha lista e indicar lo que crea relevante. Estas charlas son la clave para ir formado al equipo en las normas y el estilo que deben seguir los programadores.