Hay mucha discusión en el mundo de Monolith v/s Microservices. La mayor parte de mi carrera inicial la pasé construyendo monolitos y, por supuesto, a medida que las arquitecturas orientadas a servicios comenzaron a echar raíces, las adoptamos con bastante éxito.

Mi experiencia

No necesito sonar genial aquí y arrojar cosas como la ley de Conway a la gente. Mi experiencia limitada me ha enseñado que hemos tenido individuos, equipos pequeños y equipos grandes, a quienes claramente se les asignó el cargo de un módulo en particular (llámelo un servicio si lo desea). Como parte de su responsabilidad, tenían que hacer lo siguiente:

• tenían que poseerlo
• Tuvieron que mantenerlo
• Tuvieron que comunicarse al respecto.
• Cree API interoperables que respeten los contratos
• Probar su propio software
• Tenga en cuenta las pruebas de integración
• Ser capaz de especificar cómo implementar sus cosas en entornos.
• Depure y, lo que es más importante, rastree una llamada en el esquema general de las cosas.

No se trata de Monolitos o Microservicios

Realmente no hay una bala de plata. No existe un ángulo definitivo para ir a microservicios o ir con un monolito. Cualquiera que hable de ir en un sentido o en el otro no tiene malas intenciones al tratar de influir en usted, pero con el debido respeto, cada organización y sus equipos de desarrollo serán diferentes, sus requisitos serán diferentes, cómo deben evolucionar o apoyarse. los nuevos servicios/dispositivos serán diferentes. Primero deberá estar en el asiento del conductor para comprender su propia organización antes de adoptar ciegamente cualquier punto de vista de una gran empresa o persona influyente.

En ningún momento, ninguna organización debe subestimar la necesidad de administrar equipos de personas, poner orden, automatización, pruebas, dar a los equipos la libertad y flexibilidad para elegir herramientas y, al mismo tiempo, mantenerlos disciplinados y más.

Mantenga el punto de monolitos y microservicios a un lado por un momento. ¿Está abordando preocupaciones fundamentales como la comunicación del equipo, las jerarquías, la toma de decisiones, la disciplina e higiene de la ingeniería de software, la cobertura de pruebas, la automatización, la autonomía y más? Piense en eso por un momento.

¿Qué recomiendo?

En mi libro, prefiero ver una aplicación en su totalidad y, fundamentalmente, ¿por qué existe en primer lugar? Una vez que tenga esas respuestas, observe cuáles son los casos de uso o los recorridos de los usuarios de los clientes en los que los usuarios interactúan con su aplicación. Para mí, finalmente se reduce a lo siguiente:

1. Necesita un proceso eficiente (totalmente automatizado o no) para desarrollar e implementar su aplicación en varios entornos y poder mover versiones entre ellos.
2. Necesita implementar un proceso eficiente para rastrear los cambios de su código fuente a lo que se ha implementado en producción.
3. Por último, y lo más importante, cuando sucede una mierda y cuál sucederá, ¿tiene la capacidad de rastrear y rastrear lo que está sucediendo, ubicar el componente que está causando el problema, depurar de manera eficiente y comprender la causa raíz y luego tener un proceso para implementar el cambios para mitigar los usuarios afectados.

Ahora, si los monolitos y/o la arquitectura de microservicios pueden ayudarlo a abordar eso, dadas las limitaciones de su organización, hágalo. No eres Google, Facebook, Microsoft, Amazon y ellos no son tú. Ni siquiera necesita compararse inmediatamente con otras organizaciones, que pueden ser más inteligentes, ágiles o cualquiera de esas características.

Todo lo que necesita hacer es, en el verdadero espíritu, construir una cultura saludable en su organización que esté abierta a la discusión y comience a medir lo que DORA recomienda:

• Hora de restaurar el servicio
• Tasa de error de cambio
• Plazo de entrega para los cambios
• Frecuencia de implementación.

Mi comentario final es centrarme en lo que hace que entregue su software de manera eficiente (costo, operaciones y todo incluido). Todo lo demás es como un debate de 9 PM News.