Todos están hablando de microservicios ahora. Casi todas las reuniones, conferencias y reuniones no están completas sin una historia sobre qué son los microservicios y qué tan buenos son, cómo reducen la complejidad del proyecto, etc.
El mensaje principal de todos estos informes: los microservicios ayudan a escapar de la excesiva complejidad y complejidad del proyecto. Pero, en cuanto a mí, no puedes deshacerte de la complejidad en absoluto, no puedes rehacer el proyecto para que todo se vuelva simple a la vez. La dificultad se moverá de un área a otra.
Por ejemplo: había un monolito enredado muy complicado, lo dividimos en varios servicios, cada uno de ellos se ve muy bien, cualquiera puede descifrar el código, pero ¿qué pasa con el entorno? La complejidad está creciendo: se trata de transacciones distribuidas que deben registrarse para comprender que se trata de una transacción única; CI / CD y entrega se agregan para cada servicio; El esquema de interacción se vuelve no trivial.
Las tesis o declaraciones más controvertidas que he escuchado en los informes y con las que estoy listo para discutir:
Entrar en un proyecto monolítico es más costoso para los nuevos miembros del equipo . Por alguna razón, es habitual evaluar el costo de unirse a un proyecto según la rapidez con la que un nuevo desarrollador comienza a realizar tareas. Sí, lo resolverá en un pequeño servicio muy rápidamente y emitirá la tarea muy rápidamente (especialmente de acuerdo con la especificación, "lo que escribieron, luego lo hice").
¿Pero qué hay de los otros miembros del equipo?
El nuevo probador se ocupará del modelo de integración. Probar un servicio es bueno, pero además de probar un contrato de servicio, debe verificar un proceso comercial que afecte a varios servicios.
Al principio, el nuevo analista puede incluso romperse la cabeza, hasta que comprenda todas las complejidades de los desafíos internos.
Los microservicios le permiten liberar más a menudo . Los microservicios son más rápidos de refinar, ya que se dividen en varias tareas paralelas que se desarrollan y prueban en paralelo, y solo queda verificar la integración (sin tener en cuenta el tiempo de análisis).
También puede hacer esto con un monolito, todo depende de la descomposición de la tarea. Muy a menudo, al principio habrá una tarea: hacer una funcionalidad general (corregir la base de datos general o modificar la interfaz), y luego todos verán sus subtareas y las darán para que las prueben.
Y el tiempo de lanzamiento de funciones que paga el negocio será el mismo. La función se cerrará solo cuando se liberen todos los componentes. Los microservicios pueden resolver el 99% de las tareas, pero hasta que se cierre la última característica, no se lanzarán a la batalla.
¿De qué más no están hablando?
La dificultad está creciendo
Cuando se utilizan microservicios, la
infraestructura es complicada . Esto se debe al hecho de que necesita admitir el trabajo de no una sola aplicación, sino muchos servicios. Es necesario monitorear el desempeño de todos los servicios, comprender bien las dependencias de los servicios por versión, tener planes de CI / CD para ensamblar servicios y entrega, y mecanismos para responder a fallas de servicio para que todo lo demás no se caiga.
Parece que son cosas simples, y en un monolito debemos hacer lo mismo. Solo en el monolito trabajamos en una aplicación, y con el aumento en la cantidad de servicios, la complejidad crece, lo que requiere mayores habilidades para ser soportadas.
Los microservicios agregan complejidad : nuevas bibliotecas, nueva funcionalidad para admitir transacciones distribuidas, para manejar errores de otros servicios, enviar solicitudes repetidas, revertir transacciones. En su mayor parte, estos mecanismos serán comunes, y la mayoría de los desarrolladores no entrarán en las entrañas, sino que solo los usarán.
Pero puede haber errores en ellos que deberán corregirse. Si hacemos frente a la reparación sin ningún problema, para implementar los cambios en los servicios 200-300, llevará tiempo y se desarrollarán los controles. Y si necesita reconstruir los servicios con la biblioteca actualizada, o incluso rehacer las llamadas (lo arreglaron así, no lo proporcionaron), entonces todo esto no será divertido.
Monolito: no es una gran bola de barro
¿Cómo suelen comenzar las historias sobre el hermoso mundo de los microservicios? "Teníamos un monolito, era una masa sólida de lodo, en el que todo es confuso e incomprensible", además, mostrarán una imagen terrible. Y el monolito ya se ha convertido en algo aterrador, "trabajarás mal, tu proyecto se convertirá en un monolito".
Pero NOUn monolito puede ser (y debe) ser claro, estructurado, con un código 'bueno', con documentación, al igual que un proyecto de microservicio puede convertirse en una bola de tierra aún más grande si no participa en los procesos de desarrollo y no supervisa la calidad del desarrollo.
Entonces, ¿qué usar?
Buena pregunta, y solo tú puedes responder. Porque solo usted sabe qué problemas comerciales decide, cuál será el proyecto. No hay una bala de plata, no hay una arquitectura ideal que pueda usarse y siempre habrá "felicidad".
Y en el monolito y en los microservicios, siga la documentación y manténgala actualizada. Con documentación es mejor que sin ella.
Cree un proceso de desarrollo en el que la calidad del código solo crecerá (revisiones, pruebas unitarias). Pero sobre la calidad puede escribir un libro completo, este es un tema para una gran conversación por separado.
El código simple y comprensible no se trata de microservicios, el código debería ser así a priori.
La automatización de pruebas también se trata de la calidad del código.
Automatice todo lo que pueda automatizar: CI / CD. Probablemente hay una pila de tecnología que es muy difícil de incorporar a CI / CD, pero el 99% de los ensamblajes / entregas se pueden automatizar.