Praticamente todas as empresas possuem aplicativos que foram construídos para solucionar seus problemas internos e esses foram, em sua maioria, construídos incorporando o máximo de funcionalidades possíveis para que atendessem o maior número possível de requisitos do negócio. Isso gerou grandes blocos, conhecido como monólitos, que precisam ser geridos do ponto de vista de manutenção, estrutura, estabilidade e principalmente evolução. Com as diversas necessidades de atualizações, essas aplicações têm se transformado cada vez mais em obstáculos do que facilitadores do processo, um exemplo, simples implementação de uma regulamentação, como a LGPD, começou a exigir esforços gigantescos para sua concretização, isso tudo porque existe um alto grau de complexidade para essa manutenção.
E usando este ponto como partida, é que normalmente começa a jornada de transformação de uma aplicação, porque qualquer um que seja da área de tecnologia, já ouviu falar dos micro serviços, seja do seu conceito, dos benefícios, das referência de mercado ou até mesmo dos resultados de sua implementação que facilitam as adaptações às mudanças. Entretanto, essa jornada exige requisitos mínimos para garantir seu sucesso, entre eles, domínio do processos de negócios, mapa de contexto, definição de padrões, arquitetura de referência, abordagem DevOps e mais importante a observabilidade dos KPIs, logo diante de tantos requisitos, a simples incorporação dessa transformação se torna arriscada sem planejamento, e estando as empresas migrando para o modelo ágil se faz necessário algum plano antes da ação. Listamos algumas estratégias que podem guiar na obtenção dos requisitos em tempo de execução, ou seja, criar um plano de vôo em tempo de vôo.
Comece Algo Novo com o Novo
Sempre que uma aplicação monolítica necessitar de uma nova funcionalidade você deverá criar um micro serviços para atendê-la e não incorporá-la ao seu monólito, entretanto sabemos que a maioria das funcionalidades com certeza se utilizarão de informações essenciais da aplicação, para isso devemos criar uma interface entre o micro serviço e a aplicação, também conhecida como "Glue Code", que nada mais é que um código para unificar ambos sistemas, que poderá no futuro ser trocado ou ajustado, além de oferecer uma barreira de segurança para que o micro serviço incorpore comportamentos e conceitos do legado. No diagrama abaixo exemplificamos a arquitetura sugerida.
A implementação de novas funcionalidades como micro serviços fará com que seu monólito não cresça mais e ao mesmo tempo oferecerá oportunidades de surgirem novas estruturas independente e acopláveis.
Separe as Camadas
Pensar em separadas as camadas de apresentação das de lógicas e acesso a dados oferecerá uma estratégia para encolher sua aplicação monolítica e muitas informações da situação atual. A ideia é simplesmente separar em um ou mais interface, sendo uma delas, o front-end e as demais em back-ends, preferencialmente em formato de API. Uma vez separados, o front-end irá fazer chamadas remotas ao back-end, o diagrama abaixo mostra essa transformação.
Pode parecer puro retrabalho visto que estamos somente fazendo uma separação física, porém após essa estratégia, você terá várias API que poderão ser consumidas por outros sistemas e que ainda oferecerão estruturas isoladas que facilitarão a manutenibilidade, além de poder escalar separadamente os recursos para suas execuções.
Essas são algumas estratégias iniciais que podem oferecer o primeiro passo para iniciar essa transformação, oferecendo ao longo da sua implementação insumos e conhecimentos iniciais para contextualização do caminho que será necessário para atingir a maturidade na utilização de micro serviços.
Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil