intive Argentina Blog

Amor, Odio, Microservicios

No soy gran seguidor de las arquitecturas en boga, así de sencillo. Muchos nuevos proyectos han enfocado su diseño hacia una arquitectura orientada a microservicios. Hablamos de una evolución (que no necesariamente implica una mejora, sino un cambio) relacionada a muchas iteraciones y planteamientos en el desarrollo de software. Se puede decir que comenzó con la idea de no generar código spaguetti, cuando se empezó a pensar en crear componentes, librerías que sean reutilizables, que se puedan mejorar con el objetivo de crear alta cohesión y un bajo acoplamiento. Todos ellos son conceptos que vienen dando vueltas hace tiempo en la programación orientada a objetos.

Los problemas de las arquitecturas monolíticas

De la arquitectura de microservicios se viene hablando mucho formalmente gracias al apoyo de las metodologías ágiles y la adaptación de empresas como Netflix, Uber o Amazon. En el siguiente video se puede ver como Netflix ha logrado crear un ecosistema de miles de microservicios:

Los microservicios han venido a solventar los problemas de aplicaciones que se han transformado en monolitos (inserte aquí la película 2001: Odisea en el espacio, justo en la escena que cae una piedra enorme del cielo frente a un montón de monos). Nos referimos a los siguientes problemas:

  1. El esfuerzo enorme que implica para los equipos hacer un testing fuerte sobre toda la aplicación al momento de realizar su lanzamiento.
  2. Lo complicado del crecimiento de la infraestructura, que se vuelve más proclive a escalar de manera vertical ya que es más costoso hacerlo horizontal. De esta manera las opciones de escalabilidad se reducen.

¿Cómo ayudan los microservicios?

Los microservicios permiten trabajar de manera independiente con cada funcionalidad.

  • Adoptar cualquier tecnología o lenguaje que se crea conveniente para cada una de ellas.
  • Escalar fácilmente las más importantes y con alto uso, sin tener que escalar otras que no tienen el mismo impacto.
  • Lanzar nuevas versiones en cualquier momento y volver atrás sin un impacto alto (cabe decir que esto depende en gran medida de la criticidad del microservicio).

Las desventajas de los microservicios

El desarrollo de microservicios puede ofrecer varios inconvenientes.

  • Para el equipo de infraestructura y los arquitectos puede ser un dolor de cabeza solucionar problemas que van apareciendo como -por ejemplo- la latencia en la red, el formato de los mensajes, el balanceo de carga y la tolerancia a fallas.
  • Igualmente, el equipo de infraestructura deberá emprender su propia lucha: múltiples máquinas virtuales o contenedores y el despliegue de aplicaciones y versionamiento harán que los microservicios se vuelvan algo complicado.

Las precauciones a la hora de optar por microservicios

Entonces, ¿cómo podemos asegurar mejores resultados?

  • Cuando se define la arquitectura de microservicios se recomienda tener un repositorio separado para cada microservicio (servidores, bases de datos y demás), ya que se busca tolerancia a fallos. Por ejemplo, en la siguiente imagen podemos ver una muestra de la comunicación entre los diferentes microservicios de Netflix

  • Para poder lograr el máximo potencial de los microservicios, se recomienda automatizar y orquestar la infraestructura, ya que con esto también facilitamos la redundancia y la tolerancia a fallas.
  • Los microservicios casi obligan a los desarrolladores a organizarse en equipos multidisciplinarios más chicos, desarrollando productos que tienden a desarrollarse en períodos de tiempo más cortos.
  • Desde el punto de vista de una metodología de DevOps, la automatización es clave para facilitar el trabajo, y esencial cuando se incrementan los microservicios y la complejidad de la arquitectura (Libro del Vagabundo, capítulo “Trabajo y ahora descanso toda la semana”).
  • La comunicación entre equipos es clave como en toda metodología ágil.
  • La documentación es una ayuda enorme, y apreciada cuando se tiene que dar soporte a un microservicio que lleva tiempo sin ser cambiado (Del libro “Debí haber escrito la documentación”, capítulo de “Pensamientos reflexivos en tiempos de crisis”, primera edición).
  • Las pruebas automatizadas son como el queso en la hamburguesa, necesarias e imprescindibles (Filosofía básica del gordo en potencia).

¿Entonces?

Aunque los microservicios permiten adaptar cualquier lenguaje o tecnología mientras se respeta el formato de los mensajes, y si bien esto ofrece una oportunidad de experimentación e innovación, al mismo tiempo es posible que la arquitectura se vuelva un zoológico de tecnologías. El mantenimiento y la rotación de los desarrolladores se volverá una cruzada sin Indiana Jones. Tener en cuenta los consejos anteriores nos ayudará a sobrevivir para poder ver el final de Juego de Tronos.

Rodolfo Cordero

Rodolfo Cordero es desarrollador en la compañía desde junio de 2016. Es Licenciado en Desarrollo de Software, graduado de la Universidad Latina de Costa Rica, país del cual es oriundo. Asiduo lector y melómano, hizo cursos de coctelería y barismo, habilidades con las que deleita al staff de intive en los afters organizados por la compañía.

Deja un comentario