Microservicios en la implementación de Docker

Estamos escribiendo nuestros primeros microservicios utilizando contenedores Docker con Amazon fargate. Tenemos muchas dudas sobre el nivel de implementación con Spring Boot

Tendremos múltiples microservicios en el proyecto, si es una buena práctica, estamos escribiendo todos los microservicios en un solo contenedor o tengo que crear un contenedor Docker separado para microservicios separados. De una manera rentable, utilizamos un solo contenedor, pero ¿eso plantea algún problema para la estructura de nuestro proyecto en el futuro?

Estamos planeando implementar la aplicación en AWS fargate y nuestra aplicación tendrá una gran opción para extenderse en el futuro y esperar alrededor de 100 a 150 microservicios diferentes. En este caso, ¿es rentable si también estamos cargando todos estos microservicios en diferentes contenedores?

Lo más importante para recordar con los microservicios es que no se trata principalmente de resolver problemas técnicos, sino de problemas organizacionales. Entonces, cuando miramos si una organización debería usar microservicios y cómo se implementan esos servicios, debemos ver si la organización tiene los problemas que resuelve el estilo de microservicios.

La respuesta a su pregunta sobre su arquitectura, entonces, dependerá principalmente del tamaño de su equipo de tecnología, la estructura organizativa, la antigüedad de su producto, sus prácticas de implementación actuales y cómo es probable que cambien a mediano plazo.

Como ejemplo, si su organización:

• tiene menos de 25 técnicos,
• organizado en 1 o 2 equipos,
• cada uno de los cuales funciona en cualquier parte del producto,
• que tiene menos de 12 meses,
• y se implementa de una vez de manera regular (por ejemplo, diariamente, semanalmente, mensualmente)
• y la organización no está a punto de crecer rápidamente

entonces casi definitivamente quieres olvidarte de los microservicios por ahora. En una situación como esta, el equipo todavía es nuevo en aprender sobre el dominio, por lo que probablemente no sepa todo lo que necesitaría saber para comprender realmente cuál sería una excelente manera de dividir el sistema en una arquitectura distribuida. Eso significa que si lo dividen ahora, probablemente desearán cambiar los límites más adelante, y eso se vuelve muy costoso cuando ya tiene un sistema distribuido, mientras que es mucho más simple en un monolito. Además, con solo un pequeño equipo que puede trabajar (y apoyar) cualquier parte del sistema, hay pocas razones para invertir en la construcción de una plataforma donde los equipos individuales puedan implementar y mantener servicios individuales. Una organización en esta etapa generalmente estará mucho más preocupada por encontrar clientes e iterar el producto rápidamente, tal vez incluso pivotar el producto, en lugar de hacer que los equipos sean autónomos y construir una arquitectura resistente y de gran escala. Una arquitectura monolítica tiene sentido en este punto, pero unmonolito bien diseñado , con límites claros de componentes impuestos por API y acceso a datos encapsulados, lo que facilita la extracción de servicios en procesos separados más adelante.

Veamos un poco más adelante y consideremos una organización que es ...

• Más de 50 técnicos,
• organizado en 7 equipos,
• cada uno de los cuales solo funciona en áreas específicas del producto,
• que tiene 3 años
• y tiene equipos que desean desplegar su trabajo independientemente de lo que otros equipos están haciendo.

Tal organización definitivamente debería estar construyendo una arquitectura distribuida. Si no lo hacen, y tienen todos estos equipos trabajando en un monolito, se encontrarán con todo tipo de problemas organizativos, con equipos que necesitan coordinar su trabajo, los lanzamientos se retrasan mientras el equipo finaliza el control de calidad en su nueva característica, parche implementa ser una gran molestia para el personal y los clientes. Además, con un producto maduro, la organización debe saber lo suficiente sobre el dominio para poder dividir sensiblemente tanto el dominio como los equipos (en ese orden; ver la Ley de Conway) en unidades sensibles y autónomas que pueden progresar mientras minimizan la coordinación.

Parece que ya has elegido microservicios. Dependiendo de dónde te sientes en las escalas de arriba, tal vez quieras revisar esa decisión.

Si desea seguir desarrollando con microservicios pero desplegándolos todos en un contenedor, sepa que no hay nada de malo en esosi se ajusta a la forma en que trabaja su organización en este momento. ¿Creará problemas para la estructura de su proyecto en el futuro? Bueno, si tiene éxito y su organización crece, probablemente llegará un momento en que esta implementación de contenedor único ya no sea la mejor opción, en particular cuando los equipos comiencen a poseer servicios y quieran implementar solo su servicio sin implementar toda la aplicación . Pero esa autonomía tendrá el costo del trabajo extra y la complejidad, y puede que no le brinde ningún beneficio en este momento. El hecho de que no sea el enfoque correcto para su sistema en el futuro no significa que no sea el enfoque correcto para hoy. El truco está en vigilarlo y saber cuándo hacer una inversión adicional.

No hay problema si está utilizando un contenedor único para sus microservicios, pero el objetivo principal de los microservicios es mantener cada servicio por separado, cada servicio debe estar acoplado libremente y cada servicio debe tener una base de datos separada (si desea lograr una arquitectura de base de datos por servicio). Así que trate de lograr esto, ejecute sus servicios en un contenedor separado y orquestar esos servicios con Docker Swarm o Kubernetes. Sé que el costo es importante, pero si lo hace de la manera correcta, verá el poder de la arquitectura de microservicios.