En esta entrada os voy a hablar de un patrón que veo cada vez con más en muchos de los proyectos por lo que he pasado, hablamos del patrón sidecar.

¿Qué es?

Cada vez es más frecuente que diversos proyectos requieran de servicios similares relacionadas con por ejemplo la seguridad, la supervisión, registro o configuración. Y que dispongamos de componentes que se repiten en diversas aplicaciones.

Si estas funcionalidades están muy relacionadas con la aplicación se podrían incluir como parte de esta. No obstante hacer esto nos impediría aislar la funcionalidad, además de no poder reutilizarla en otros servicios.

La idea es extender a nuestra aplicación una nueva funcionalidad mediante un proceso que se va a ejecutar en paralelo a esta. Es decir será una aplicación que se ejecutará en paralelo a nuestra aplicación principal. Ya vamos viendo un poco la analogía de sidecar

Al oír todo esto piensas, y por qué no incluir esa nueva funcionalidad como una biblioteca o librería en nuestro proyecto. Y de hecho es lo que se ha venido haciendo tradicionalmente. Con la llegada de los contenedores se abre estas nueva posibilidad, una aplicación con otra aplicación anexa.

Service Mesh o Malla de Servicios

Al indagar sobre Sidecar surge mucho este curioso término que este va bastante ligado. Qué es service mesh o malla de servicios. En la web https://www.aplyca.com/es/blog/service-mesh encontramos la siguiente definición

En términos generales, un service mesh puede ser considerado como una infraestructura de software dedicada a manejar la comunicación entre microservicios. Proporciona y permite aplicaciones basadas en contenedores y microservicios, los cuales se integran directamente desde el interior del clúster. Un service mesh proporciona servicios de vigilancia, escalabilidad y alta disponibilidad a través de una API de servicios, en lugar de obligar su implementación en cada microservicio. El beneficio está en reducir la complejidad operativa asociada con las aplicaciones modernas de microservicios.

Y bien el patrón sidecar nos permite que junto a nuestro contenedor de la aplicación principal dispongamos de otro contenedor más pequeño que vaya enganchado como un sidecar a una moto a nuestra aplicación y nos permite que nuestra aplicación interactúe con esta malla de servicios.

Sidecar vs Librearía vs Servicios externos

@https://www.bbva.com/es/patron-sidecar-en-seguridad

Extraído de esta web tenemos una tabla comparativa con estas tres alternativas, aparte de un artículo muy interesante sobre Sidecar.

Intraproceso (librerías)

VENTAJAS:

• Uso eficiente de los recursos, al estar dentro de la propia aplicación.
• Sin latencia

DESVENTAJAS:

• Sin aislamiento, un problema en un componente puede afectar a los demás componentes de la aplicación
• Una versión por cada lenguaje
• Gestión de dependencias, problemas de integración…

Servicios externos

VENTAJAS

• Uso del lenguaje/tecnología más adecuado
• Gestión de dependencias

DESVENTAJAS

• Latencia
• Distinto ciclo de vida, problemas de integración (interfaces)
• Seguridad, Access Control, etc

Sidecar

VENTAJAS

• Poliglota, permite trabajar con otros lenguajes o tecnologías diferentes a la de la aplicación principal
• Desacoplado de dependencias y librerías
• No compartido, sin problemas de integración
• Transparencia (casi siempre), sin problemas de integración

DESVENTAJAS

• Compite por recursos
• Complejidad

Sidecar y Kubernetes

De igual manera, hablar de sidecar es hablar de contenedores, y en concreto de pods. Como bien sabemos un pod en kubernetes se puede definir de la siguiente forma:

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. A Pod’s contents are always co-located and co-scheduled, and run in a shared context. A Pod models an application-specific “logical host”: it contains one or more application containers which are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host. As well as application containers, a Pod can contain init containers that run during Pod startup. You can also inject ephemeral containers for debugging if your cluster offers this.

Es decir que en un pod podemos tener varios contenedores en ejecución de manera simultanea. Uno podría tratarse de nuestra aplicación principal, y el otro el sidecar interactuando con la malla de servicios; o bien haciendo de poliglota.

Ilustro más abajo un ejemplo:

Esto seria un ejemplo con sidecar para un visualizador de logs.

Spring Boot y Sidecar

@https://cloud.spring.io/spring-cloud-netflix/multi/multi__polyglot_support_with_sidecar.html

Spring Cloud tiene una funcionalidad poliglota que permite utilizar aplicaciones que no sean en java dentro de Spring Cloud y Eureka. Esta solución proporcionada por Spring Cloud Sidecar está inspirada en Netflix Parana. Esta solución no solo implementa la función de puerta de enlace proxy Zuul, sino que también proporciona un servicio HTTP. Explicado de otra manera podemos ponerle un sidecar a una aplicación no hecha en Java para que vaya a través de Spring Cloud con Eureka, de forma que proporcionaría un API HTML Por lo tanto, Sidecar no solo puede representar el servicio de aplicaciones heterogéneas, sino también informar a Eureka si la aplicación se inicia o se cierra a través del resultado de la llamada de su servicio de verificación de estado. Incluyo una imagen a ver si lo puedo explicar de otra forma:

En esta imagen podemos ver cono mediante Sidecar podemos hacer que una aplicación en node dispone de Zuul Eureka y Hystrix.

En esta otra imagen podemos ver otro ejemplo de una aplicación que no es JVM y dispone de de un sidecar para disponer de un api y Eureka.