¿Cuándo usar microservicios? Repaso de las ventajas y desventajas

¿Cuándo usar microservicios? Repaso de las ventajas y desventajas

En el post anterior, además de hacer una introducción a lo que son los microservicios, también vimos algunos conceptos claves que le podemos asociar.

La siguiente pregunta que podemos pensar es, ¿cuándo usar microservicios? Algo natural que suele pasar, y más en el rubro IT, es querer usar la última tecnología disponible o aquello que está de moda (que es un poco lo que pasa a día de hoy con los microservicios). Pero como suele pasar con muchas preguntas, la respuesta es: depende.

Para responder eso, primero debemos profundizar en algunas de las ventajas y desventajas que tienen los microservicios:

Ventajas:

Ciclo de vida de aplicaciones independiente: Cada uno de los microservicios que componen la solución es 100% independiente del otro desde el punto de vista tecnológico (arquitectura interna, lenguaje de programación, etc.), del equipo que lo trabaja y cómo se organiza. Esto permite que cada uno de esos microservicios evolucione, crezca o disminuya de forma independiente al resto de los microservicios.

Orientación a la evolución tecnológica: Al ser aplicaciones independientes cada una puede estar en un lenguaje o arquitectura diferente. Esto puede ayudar a hacer pruebas de nuevos conceptos o tecnologías en algún microservicio puntual que, dada la función de negocio particular que debe cumplir, se adapte a eso. Lo mismo ocurre con la actualización tecnológica, es mucho más simple actualizar versiones de SDKs y librerías de un microservicio puntual (o varios) que de una aplicación grande y monolítica. Esto último lo digo con experiencia, me ha pasado en aplicaciones grandes que actualizar una librería era una cuestión de estado en el proyecto. Y actualizar el SDK, era presentar una propuesta de páginas a los sponsors explicando el porqué se necesitaba hacer eso. Ahora mismo por ejemplo en el trabajo estamos actualizando microservicios en Go y Java de forma independiente a medida que cada equipo tiene tiempo y sin afectar en nada al resto de las aplicaciones.

Evita cuellos de botella: Al ser aplicaciones distribuidas, no estamos con la situación donde tenemos una sola aplicación centralizada que gestione todo el tráfico y ante una degradación de performance se vea afectada de forma completa. Al ser distribuida, si habría degradación debería ser solamente en ese microservicio, sin afectar al resto.

Además de que es mucho más fácil escalar estas aplicaciones de forma vertical (más hardware en la misma instancia, alto costo y límites) pero principalmente de forma horizontal (N instancias corriendo en paralelo). Esto está promovido por el uso de containers y de que cada microservicio es reducido en tamaño y dependencias, permitiendo que rápidamente se pueda reaccionar a aumentos de tráfico.

Promueve la resiliencia: Tener múltiples microservicios en vez de una sola aplicación monolítica tiene como ventaja de que no hay un sólo punto de fallo. Si un microservicio sufre una afectación/caída va a tener un impacto (sino nos deberíamos preguntar qué hace ese microservicio por si mismo), pero debería estar limitado a un contexto puntual y el resto de microservicios no debería verse afectado de forma directa.

Así mismo, al tener una naturaleza distribuida el diseño de las mismas promueve ya mecanismos de respaldo ante fallos de otros microservicios (ya que hay interacciones de distintos microservicios entre si) y cómo recuperarse cuando el mismo esté disponible.

Trabajo más efectivo por parte de los equipos: Cada equipo suele trabajar en un conjunto limitado de microservicios, generalmente enfocados en una parte común del negocio. Eso logra que el equipo conozca en mayor detalle tanto el negocio que tienen que resolver (algo que es fundamental) como la parte técnica de los mismos. Eso, sumado a que cada microservicio es reducido, hace que el trabajo sea ágil y efectivo. Si a su vez a eso le sumamos a varios equipos trabajando en paralelo en múltiples microservicios, se puede llegar a tener nuevas funcionalidades en plazos más cortos, con calidad y algo rendimiento.

Desventajas:

Requiere experiencia previa en esta arquitectura: Después de todo, los microservicios son una implementación de una arquitectura distribuida de aplicaciones lo cual no es algo sencillo sin haberlo trabajado con anterioridad. En una arquitectura distribuida se maximizan los posibles problemas y errores de diseño que podemos tener en una aplicación monolítica estándar.

Mayores costos: Desde la perspectiva de que tenemos muchas aplicaciones corriendo en vez de una (aunque son varias más chicas en vez de una grande) ya tenemos un mayor costo de procesamiento. Esto sumado a que cada microservicio debería correr en instancias totalmente aisladas con respecto a los otros, por lo que se tienen N plataformas (sistema operativos y plataforma de ejecución del lenguaje) corriendo en vez de una sola. Esto claramente es una ventaja, porque se pueden escalar aplicaciones en infraestructura de forma separada, pero dependiendo del tipo de empresa y aplicación pueden ser costos totalmente innecesarios.

Otro costo que tenemos también son los tiempos, ya que al ser una solución más compleja y con una mayor escalabilidad vamos a necesitar más tiempo para tenerla productiva si partimos de crear una solución de cero y sin experiencia previa. Cosas sencillas y naturales como puede ser la transaccionabilidad en el guardado de información al ser distribuido se pierde y debemos ver cómo resolverlo (pronto vamos a ver en un post cómo resolver esto).

Mayor configuración de la infraestructura: El aislamiento que mencionábamos en el punto anterior, viene dado generalmente por el uso de containers para desplegar y ejecutar cada microservicio. Eso implica la configuración de los mismos, del proceso de CI/CD (integración y despliegue continuo), herramientas de monitoreo y de métricas (no podemos tener N aplicaciones sin un chequeo constante del estado interno y performance de las mismas).

Dificultad para pruebas integrales: Si bien las pruebas sobre cada aplicación son mucho más sencillas, la complejidad aparece cuando queremos probar soluciones completas, implicando un flujo que conecta varios microservicios. Además de gestionar que cualquier cambio que se haga a un microservicio no afecte la normal operación de los otros con los cuales se relaciona. En una aplicación monolítica nos daría un error de compilación y problema resuelto, acá en cambio si no se gestiona y comunica de forma adecuada puede hacer que el problema se encuentre con usuarios reales en producción.

Dificultad para debugging y búsqueda de problemas: Si tenemos una aplicación estándar (o monolítica) ante cualquier problema está claro dónde buscar el detalle para entender qué es lo que está pasando, tanto para errores en producción como en desarrollo. Si hablamos de una aplicación distribuida usando microservicios, cada uno de ellos debe ser capaz de registrar su estado y saber cuándo falla y por qué. Recordemos que, como mencionamos anteriormente, generalmente tenemos muchos equipos trabajando, cada uno en un conjunto de microservicios. No sería práctico ni escalable que ante un problema cada uno se ponga a revisar el estado de su aplicación.

Para el desarrollo en el entorno local y debugging también tenemos mayor complejidad, ya que no podemos ejecutar todos los microservicios relacionados localmente, y menos usar los productivos. Por lo tanto, menos el servicio en el cual estemos trabajando, los demás microservicios deberán estar disponible en algún entorno de pruebas para todos los desarrolladores, o bien se pueden usar mocks de las respuestas esperadas (básicamente en vez de hacer una llamada se lee un archivo json con la respuesta que se espera).


Entonces, ¿cuándo es recomendable usarlos?

Habiendo repasado estos puntos, ¿cuándo es recomendable usar microservicios?

Mi opinión personal es que nos pueden dar un paso adelante o evolución en muchos aspectos (técnicos de los equipos que desarrollan, de los productos que hacemos en incluso de las soluciones que le damos al problema de negocio). La clave es ser conscientes de que hay algunas características para usar microservicios en un proyecto nuevo y que no le agreguemos riesgo de problemas desde el punto de vista tecnológico:

  • Se cuenta con experiencia previa: eso no quiere decir que equipos que no tengan experiencia no usen microservicios, sino el cómo obtendrán esa experiencia. Pero si es el caso, no sería ideal pensar en hacer una aplicación completa usando microservicios, sino mejor usando la experiencia previa para hacer una aplicación bien modularizada y que permita escalar luego individualmente aquellos puntos que sean necesarios en microservicios.
  • Tamaño de empresa y del producto a realizar: muchas veces pasa que una empresa chica, con poco presupuesto, tiene una idea que quiere poner en marcha. En esos casos el tiempo y no excederse con los presupuestos disponibles es fundamental, lo cual no quiere decir que no debamos usar microservicios. Hay que usarlos si es necesario y si su uso nos da una ventaja para lograr los objetivos. Sino, siempre habrá una oportunidad de evolución a futuro.
  • Madurez de la empresa y sus procesos: diseñar y llevar adelante una aplicación usando microservicios requiere una madurez de la empresa en sus procesos, ya que debe tener bases sólidas en diseños de arquitecturas, buena comunicación y coordinación entre los distintos equipos, procedimientos de CI/CD, métricas y monitoreo.

Esto no quiere decir que no debamos usarlos si no cumplimos con todas estas características, pero hay que ser conscientes de sus características para decidir cuándo comenzar a usarlos y de qué forma.

Lo que sin dudas puedo recomendar es intentar buscar la oportunidad para hacerlo, tal vez en algo puntual que querramos empezar a separar de nuestra aplicación de tipo monolítica, o bien cuando tengamos una parte de nuestra aplicación que puntualmente requiera alguna característica puntual de escalabilidad y separemos sólo esa parte en un microservicio.

Cuando se empieza a tomar práctica en el diseño e implementación de microservicios, vamos a poder ver cómo pensamos soluciones con mayor calidad y robustez, a la vez que podemos usarlo como mecanismo para ir evolucionando y mejorando los procesos de la empresa. Además de que nos pueden dar herramientas para ayudar a la escalabilidad del negocio y agilidad a la hora de realizar cambios y adaptaciones.

Tenes alguna otra ventaja o desventaja importante que parezca importante agregar? O una opinión distinta? Si es así espero tus comentarios..

Gracias por leer!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s