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