Existe la sensación de que los microservicios a menudo se colocan como una "bala de plata" para reemplazar el monolito. Pero no a todos les gusta este enfoque. De hecho, a veces se usa de manera incorrecta o inapropiada. A continuación se presentan ejemplos de problemas que tuve la "suerte" de enfrentar cuando utilicé microservicios en diferentes compañías y que no quiero repetir en el futuro.
Escalabilidad fantasma
La ventaja del enfoque de microservicio es la escalabilidad. Un flujo infinitamente grande de usuarios y una gran carga se consideran inevitables. Debido a esto, se dedica mucho tiempo a la optimización preliminar y no a funciones comerciales útiles. De hecho, una carga alta no siempre está presente.
La primera víctima de la optimización previa es un proceso comercial lineal. Se descompone en muchos microservicios. Una especie de reserva para el futuro, por razones de división de responsabilidades o escalas ilusorias. Como resultado, se vuelve más difícil para las empresas navegar el panorama de TI y hablar el mismo idioma que TI, sin mencionar los problemas de navegar a través del código fuente para los propios desarrolladores.
Problemas de interacción del servicio
Los servicios recibidos se encuentran dispersos desde monorepa en repositorios separados. Los servicios en sí mismos son cada vez más difíciles de conectar. En este caso, la versión de la API de microservicio puede comenzar a diferir de la versión de la misma API en los clientes de microservicio. Luego, el viejo JSON se reemplaza con Protobuf y HTTP con gRPC para obtener rendimiento, mecanografía y versiones de API convenientes.
Desafortunadamente, las soluciones como gRPC + Protobuf no están libres de errores. Los servicios pueden fallar constantemente debido a la propagación de un error y una incompatibilidad entre entrada y salida del servicio conocido. La base de código se está haciendo más grande, los servicios de depuración son mucho más difíciles que con los datos de texto sin formato, lo que trae consigo un montón de problemas.
Este problema debe resolverse mediante un proceso de prueba normal. En particular, pruebas de integración. Pero las pruebas de integración deben escribirse y ejecutarse para cada microservicio y su grupo dentro del proceso comercial. Esta es una tarea bastante complicada, a la que generalmente no quieren dedicar más tiempo. En este caso, la prueba de integración de microservicios se puede reducir a la forma de una prueba unitaria para un monolito.
Viejas restricciones y hábitos
Con todo esto, las limitaciones habituales para un monolito vagan en microservicios. Ejemplos vívidos: un lenguaje de programación y una base de datos para todos los microservicios. En el primer caso, esta es la primera limitación del monolito, en el segundo, es un legado que se esfuerza por convertirse en el "cuello de botella" de todo el sistema. Debido al hecho de que los desarrolladores y la administración no aceptan la posibilidad de un sistema heterogéneo construido en diferentes lenguajes de programación, se pierde la posibilidad de elegir herramientas adecuadas para resolver problemas urgentes.
Además de lo anterior, los microservicios individuales pueden no tener desarrolladores responsables de ellos. Todos comienzan a apoyar todo, nadie es responsable de nada. En este caso, nadie tiene conocimiento sobre la operación de servicios individuales, excepto la última persona que cambió su código. Hay una desincronización de los desarrolladores, una pérdida de comprensión de la esencia del trabajo de los microservicios en relación con las tareas resueltas dentro del área temática.
Burocracia de infraestructura
Los microservicios son más difíciles de mantener que un monolito. La infraestructura, un antiguo par de servidores, se está convirtiendo en una pequeña nube privada. A los desarrolladores les lleva mucho tiempo dar soporte a tales soluciones y crea problemas para la administración en el futuro. Hay una necesidad exagerada de burocracia adicional. Se contratan empleados individuales, se crean procesos separados.
En tales casos, los conjuntos de reglas para trabajar con microservicios pueden exponerse para mantener la integridad del bucle de microservicios. El peor de los casos es negar incluso la posibilidad de ejecutar un script o migración de una sola vez, evitando el acceso directo a la ruta. En pocas palabras: el script se ejecuta como un servicio completo, agregando una línea más a la larga lista de microservicios.
Futuro
El resultado es un sistema que tiene muchas veces más ruido que una señal útil. En todas partes: desde la infraestructura hasta el código de un servicio específico. Desde la comprensión del desarrollador del esquema de interacción del servicio hasta la gestión de la empresa. Los programadores se convierten sin saberlo en maestros para resolver acertijos.
Por supuesto, el monolito clásico no es mejor. Es lento, mantiene su estado, es difícil de procesar, no está cubierto por pruebas unitarias o de integración, etc. ¡Pero lo podemos hacer mejor! Gracias al mod para microservicios, entre muchas otras ventajas, vimos el aumento de CI / CD y trabajamos en las pruebas. Ahora podemos aplicarlos también a otros enfoques, no solo a microservicios.
La próxima vez que desarrolle un nuevo sistema o recicle uno viejo, sea cual sea su tamaño, piénselo dos veces. ¿La empresa necesita escalabilidad? ¿Necesita la capacidad de manejar cargas altas? ¿Estás realmente preparado para microservicios? ¿O es mejor comenzar con arquitecturas más conservadoras?
Tal vez no construir un cohete, sino construir un scooter simple, porque solo necesita llegar al final de la calle.