Non caia na trampa de "Os microservizos son xeniais" e saiba cando seguir a Monolith.

Os monolitos e os microservizos son dous enfoques básicos para crear aplicacións. Algunhas persoas consideran que son legados e modernos, respectivamente. Pero isto non está ben. Elixir entre eles é unha cuestión moi complexa, con ambos os seus pros e contras.

A maioría das novas aplicacións non precisan ser microservizos dende o principio. É máis rápido, máis fácil e máis barato comezar como un monolito e cambiar aos microservizos máis tarde se o consideras beneficioso.

Co paso do tempo, a medida que as aplicacións monolíticas fanse cada vez menos mantidas, algúns equipos deciden que a única forma de resolver o problema é comezar a refactorizar dividindo a súa aplicación en microservizos. Outros equipos toman esta decisión só porque "os microservizos son xeniais". Este proceso leva moito tempo e ás veces supón aínda máis gastos de mantemento. Antes de entrar nisto, é fundamental considerar coidadosamente todos os pros e contras e asegurarse de que alcanzou os límites actuais da arquitectura monolítica. E lembra que é máis fácil romper que construír.

Neste artigo, non imos comparar monolitos con microservizos. En cambio, discutiremos consideracións, patróns e principios que che axudarán:

• saca o mellor do teu monólito actual e prepárao potencialmente para entrar en microservizos;
• proporcionar unha migración sen problemas de monolito a microservizos;
• comprender o que máis pode cambiar coa migración de microservizos.

Monolito modular

O primeiro que debes facer é mirar a estrutura do teu proxecto. Se non tes módulos, recoméndolles encarecidamente que os consideres. Non che fan cambiar a túa arquitectura por microservizos (o que é bo porque queremos evitar todo o mantemento correspondente) senón que lles sacan moitas vantaxes.

Dependendo da súa ferramenta de automatización de construción do proxecto (por exemplo, maven, gradle ou outra), pode dividir o seu proxecto en módulos independentes e independentes. Algúns módulos poden ser comúns a outros, mentres que outros poden encapsular áreas específicas de dominio ou ser específicos para funcións, aportando funcionalidades independentes á súa aplicación.

Dará os seguintes beneficios:

1. Partes desacopladas da súa aplicación.
2. As funcións pódense desenvolver de forma independente, minimizando os conflitos.
3. É moito máis doado incorporar persoas novas xa que non precisan mergullarse en todo o proxecto; en cambio, poden partir de partes illadas.
4. Probas melloradas, porque agora podes probar cada módulo por separado.
5. Se finalmente necesitas migrar a microservizos, tes unha base moi sólida para iso.

Como ves, o monólito modular é o xeito de obter o mellor de ambos mundos. É como executar microservizos independentes dentro dun único monólito pero evitando os microservizos colaterais. Unha das limitacións que pode ter é non poder escalar diferentes módulos de forma independente. Terá tantas instancias monolíticas como requira o módulo máis cargado, o que pode levar a un consumo excesivo de recursos. O outro inconveniente son as limitacións do uso de diferentes tecnoloxías. Por exemplo, non pode mesturar Java, Golang e Python nun monólito modular, polo que está obrigado a seguir cunha tecnoloxía (que, normalmente, non é un problema).

Patrón de figo estrangulador

Pense no patrón Strangler Fig. Toma o seu nome dunha árbore que se envolve e finalmente substitúe ao seu hóspede. Do mesmo xeito, o patrón suxire substituír partes dunha aplicación herdada por novos servizos un por un, modernizando un sistema antigo sen causar interrupcións significativas.

En lugar de tentar unha revisión arriscada e dunha soa vez, actualiza o sistema peza por peza. Este método é beneficioso cando se trata de monolitos grandes e complexos que son demasiado difíciles de manexar para substituír nun só esforzo. Ao adoptar o patrón Strangler Fig, os equipos poden eliminar gradualmente o sistema antigo mentres fomentan o crecemento do novo, minimizando os riscos e asegurando a entrega continua de valor.

Para implementar o patrón Strangler Fig, debes seguir tres pasos:

1. Transformar. Aquí, identifica que parte extraer do monolito e implementalo como un microservizo separado. Reescribe esta parte utilizando tecnoloxías modernas e aborda os problemas da implementación anterior. Aproveita a oportunidade de facelo mellor.
2. Convivir. Cando un novo microservizo está listo para a produción, execútao na túa infraestrutura, mantendo a implementación antiga. Distribúes o tráfico en certa proporción, movendo progresivamente máis e máis tráfico á nova implementación, pero sempre tes a túa versión anterior como reversión.
3. Eliminar. Despois dun tempo, cando creas que o teu novo microservizo é o suficientemente fiable, move todo o tráfico ao novo microservizo e elimina o legado.

Facendo estes tres pasos, gradualmente irá dividindo un monólito en microservizos.

Os principais beneficios de usar o patrón Strangler Fig son:

• Migración gradual. En lugar de fallar e comezar unha revisión completa do sistema oportuna, abrumadora e arriscada, o patrón permítelle facer a transición paso a paso. Podes actualizar lentamente o teu sistema e sincronizar esta transformación cos plans de desenvolvemento de funcións. Por exemplo, podes atopar unha parte do monólito que o desenvolvemento de funcións afectará seriamente e escollelo como candidato para a migración de microservizos.
• Entrega continua. Este beneficio vén da declaración anterior. O proceso de modernización non impide que o teu equipo entregue continuamente novas funcións. Mentres un equipo desenvolve novas funcións, outro refactoriza módulos independentes.
• Mitigación de riscos. O patrón Strangler Fig axuda ao equipo a centrarse na modernización de partes específicas do sistema. Este enfoque permite ao equipo prestar máis atención aos detalles en áreas específicas, atopar posibles problemas antes e minimizar o impacto xeral na aplicación.

Cuestións e consideracións

Ao aplicar o patrón Strangler Fig, debes planificar coidadosamente a estratexia de migración. Inclúe identificar cales son os compoñentes que se deben substituír primeiro, garantir a integración adecuada entre as pezas antigas e as novas e manter modelos de datos coherentes. Os equipos tamén deben establecer canles de comunicación e sistemas de seguimento claros para seguir o progreso e o impacto de cada substitución.

Repercusións da migración de microservizos

Como comentamos anteriormente, a transición aos microservizos trae beneficios. Non obstante, tamén fai que moitas outras cousas sexan máis difíciles e caras.

Por exemplo, os equipos de control de calidade e de desenvolvemento poden enfrontarse a unha situación na que xa non poden probar en máquinas locais porque a capacidade de executar varios microservizos localmente é limitada. Ou os teus rexistros poden ser menos perspicaces porque, en lugar de que un servizo procese un único fluxo, varios servizos o procesan agora. Como resultado, para ver a secuencia de rexistro completa, cómpre implementar a instrumentación e o rastrexo axeitados.

Discutamos algúns aspectos cruciais que debes considerar e quizais planificar antes de que comece a transformación dos teus microservizos.

Implantación e infraestrutura

Monolith e microservizos teñen diferentes requisitos mínimos de infraestrutura.

Cando se executa unha aplicación monolítica, normalmente pode manter unha infraestrutura máis sinxela. As opcións como máquinas virtuais ou solucións PaaS (como AWS EC2) serán suficientes. Ademais, pode xestionar gran parte da escala, a configuración, as actualizacións e o seguimento manualmente ou con ferramentas sinxelas. Como resultado, pode evitar configuracións de infraestrutura complexas e depender de desenvolvedores ou enxeñeiros de soporte sen necesidade de contar cunha ampla experiencia en DevOps.

Non obstante, adoptar unha arquitectura de microservizos cambia esta dinámica. A medida que crece o número de servizos, un enfoque manual e práctico faise rapidamente pouco práctico. Para orquestrar, escalar e xestionar de forma eficaz varios servizos, necesitarás plataformas especializadas como Kubernetes ou, polo menos, un servizo de contedores xestionados, que introduzan unha nova capa de complexidade e demandas operativas.

Capa de plataforma

Manter unha aplicación monolítica é relativamente sinxelo. Se xorde un CVE, actualiza a dependencia afectada nun só lugar. Necesitas estandarizar a comunicación de servizos externos? Implementa un único envoltorio e reutilízao en toda a base de código.

Nun ambiente de microservizos, estas tarefas sinxelas fanse moito máis complexas. O que antes era trivial agora implica coordinar os cambios en varios servizos independentes, cada un co seu ciclo de vida e dependencias. A complexidade engadida aumenta os custos tanto en tempo como en recursos. E a situación empeora cando tes moitos equipos e moitos servizos diferentes.

Polo tanto, moitas organizacións introducen unha capa de plataforma dedicada, xeralmente xestionada por un equipo de plataforma. O obxectivo é crear unha base que todos os microservizos poidan herdar: xestionar dependencias comúns, implementar patróns estandarizados e proporcionar envoltorios preparados. Ao unificar estes elementos a nivel de plataforma, simplificas significativamente o mantemento e fomentas a coherencia en todo o sistema.

Conclusión

Romper un monólito en microservizos é unha transformación arquitectónica importante que require unha coidadosa consideración e planificación.

Neste artigo, comentamos os pasos que podes seguir para prepararte para iso e realizar o proceso sen problemas. Unirse ao patrón Strangler Fig proporcionarache o proceso incremental e garantirá a estabilidade do sistema durante toda a transformación. Ademais, o monólito modular non só pode ser un paso de preparación útil, senón que tamén pode traer beneficios que poden levarche a reconsiderar a túa decisión de transformación de microservizos e evitar a complexidade operativa correspondente.