El costo de los microservicios (2020)

• Un artículo sobre los costos y beneficios de pasar de un backend monolítico a una arquitectura de microservicios
• A medida que aumenta el número de equipos que contribuyen a una sola base de código, los componentes se vuelven cada vez más acoplados, disminuye la productividad y aumenta la complejidad
• Una solución para mitigar estos problemas es dividir un backend monolítico en un conjunto de servicios desplegables de forma independiente que se comunican mediante APIs, es decir, microservicios
• El término “micro” puede ser engañoso, ya que los servicios no necesitan ser “micro”. Un término más apropiado sería arquitectura orientada a servicios
• Al descomponer el backend en un conjunto de servicios con límites bien definidos, basta con un equipo pequeño para desarrollar y operar cada servicio, por lo que aumenta la velocidad de desarrollo de la aplicación
• Cada microservicio puede escalar de forma independiente y adoptar diferentes stacks tecnológicos según sus propias necesidades, lo que facilita experimentar y evaluar nuevas tecnologías
• Sin embargo, una arquitectura de microservicios agrega más partes móviles al sistema completo, aumentando la complejidad y requiriendo cierto nivel de estandarización
• Si se usan distintos lenguajes, librerías y almacenes de datos para cada microservicio, la aplicación puede volverse un caos difícil de mantener y hacer más complicado que los desarrolladores se muevan entre equipos
• Para dar soporte a gran escala a servicios independientes, debe ser fácil crear nuevos servidores, almacenes de datos y otros recursos, lo que requiere una automatización considerable
• Las llamadas remotas son costosas e introducen nuevas formas en que el sistema puede fallar, por lo que se necesitan mecanismos defensivos como timeouts, reintentos y circuit breakers
• La integración continua garantiza que los cambios de código pasen por procesos automáticos de build y pruebas antes de fusionarse en la rama principal
• Las pruebas de integración de todos los microservicios son mucho más difíciles que las pruebas de un monolito; pueden aparecer comportamientos muy sutiles e inesperados cuando los servicios individuales interactúan entre sí
• Los equipos que desarrollan servicios por lo general también son responsables de atender sus llamadas, lo que genera fricción entre el trabajo de desarrollo y los costos operativos
• Depurar fallas del sistema se vuelve más difícil con microservicios, por lo que es importante contar con buen logging y monitoreo en todos los niveles
• Dividir una aplicación en servicios separados implica que el modelo de datos ya no exista en un único almacén de datos, por lo que por lo general hay que aceptar consistencia eventual
• En general, lo mejor es comenzar con un monolito y dividirlo solo cuando sea difícil establecer con precisión los límites entre servicios
• Empezar con un enfoque primero de microservicios solo debería hacerse si ya se tiene experiencia con ello y se ha construido una plataforma para soportarlo, o si se ha considerado el tiempo que tomará construir una