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.