Qual a sua estratégia para migração de aplicações na sua organização?
Em vários clientes que estamos atendendo, existem cenários que nos deparamos com inúmeros componentes legados nas organizações. Muito destes, são cruciais e fundamentais para o funcionamento dos negócios, porém, existem os desafios de fazer com que eles sejam modernizados da forma mais aderente as demandas de todas as indústrias no mercado.
Padrão de Estrangulamento de Aplicações (Strangling Pattern)
O Padrão de estrangulamento se tornou muito popular, tendo sido documentado no site microservices.io (https://microservices.io/patterns/refactoring/strangler-application.html), o objetivo deste padrão é fazer com que aplicações legadas possam ser alteradas de forma paulatina, mudando os serviços de maneira que os consumidores e os canais sejam impactados o mínimo possível.
Estágio 1 | Os canais consumidores acessam 100% do Serviço Legado |
Estágio 2 | Criamos uma Fachada, que também é uma estratégia inspirada no Pattern Façade (GOF) - https://en.wikipedia.org/wiki/Facade_pattern, mas neste caso, podemos criar uma especialização deste patter que é o API de Fachada (API Façade - https://cloud.google.com/static/files/apigee/apigee-api-facade-pattern-ebook.pdf ). O objetivo desta fachada é abstrair a comunicação dos canais com as extremidades de serviço, neste caso, pode ser que o acesso seja 80% nos componentes legados, e 20% em componentes já modernizados. |
Estágio 3 | A medida que as funcionalidades do sistema legado sejam modernizadas em serviços menores, ou seja, quebrando este monólito em serviços menores (micro ou macro serviços), digamos que neste estágio os canais consumidores via o API Façade, já possam acessar muito mais as funcionalidades dos serviços modernizados e não mais todas as capacidades dos serviços legados. |
Estágio N | Em algum momento, o resultado desta estratégia é simplesmente desligar os legados. |
Tipos de Componentes Legados mais encontrados por nosso time de Consultoria
Stored Procedures e componentes de Bancos de Dados
Há mais de 20 anos atrás, era muito comum a construção de aplicações no modelo cliente-servidor (Client-Server), que poderia ser dividida em duas formas: Thin Client/Fat Server e Fat Client/Thin Server. Devido a capacidade computacional muito maior no lado servidor, o modelo Fat Server foi muito mais utilizado, o que resultou na criação de aplicações Desktop usando Delphi, Visual Basic, Fox pro, Oracle Forms, acessando Bancos de dados como inúmeras funções (Stored Procedures), devido ao grande poder dos bancos de dados da época, a exemplo, o Oracle, que possui o PL/SQL, que tem uma capacidade incrível para não só concentrar regras de negócios mas várias funções que facilitaram a construção de aplicações extremamente robustas. Vamos usar aqui um exemplo de arquitetura feita para um cliente com a combinação Delphi com Oracle:
Muitos clientes possuem inúmeras regras de negócios, até integrações construídas com PL/SQL. Com a questão de suporte ao Windows, muitas destas aplicações por exemplo Delphi, mas até mesmo outras tecnologias da década de 90/2000 poderão ter problemas para continuarem em execução, por essa razão, algumas destas empresas estão literalmente desesperadas e a razão é "Como posso migrar para outro sistema essa solução, sendo que todas as minhas regras não conseguimos portar?"
Qual foi a nossa proposta?
Adquirir um novo ERP seria complexo, pois ainda haveria o problema de migração de regras de negócios. Sendo assim, o que sugerimos?
1- Um novo front-end single page application com Angular, portando a experiência de usuário do desktop, adicionando todas as melhorias dos dias modernos.
2- Esta nova aplicação SPA acessaria APIs REST, que atuam como fachadas para acesso a todas as funcionalidades e regras que estão ainda no Banco de Dados Oracle.
3 - O foco foram funcionalidades críticas, e com isso, novos usuários começaram a usar esse novo frontend, que interagia com os mesmos dados da aplicação legada Delphi.
4- Aos poucos, todas as funcionalidades foram portadas para a SPA, fazendo com que estas fossem 100% compatíveis com as funcionalidades da aplicação desktop Delphi.
5- Com os usuários migrados para essa nova UI na aplicação SPA, a aplicação desktop deixou de ser usada.
6- Com o uso das APIs, toda e qualquer funcionalidade escrita em PL/SQL poderia dar lugar a um novo microsserviço usando tecnologias como docker, kubernetes, protcolos como WebSockets etc.
7- A nova arquitetura além de microsserviços, agora possui 3 bancos de dados, algumas coisas ainda em Oracle, mas também convivendo com MongoDB e Redis.
Benefícios para o Cliente e o Negócio
Economia: O cliente não precisou investir num novo ERP, que seria um investimento significativo.
Redução de Riscos de Migração e Customizações: Customizar um ERP trazendo regras já existentes é uma das tarefas mais arriscadas e também caras para modernizações neste sentido.
Melhoria de Experiência: Usuários tiveram preservadas as funcionalidades do Desktop, com a riqueza de uma aplicação Single Page Application, com todas as melhorias aplicadas pela disciplinas de UX (User Experience).
Atendimento de novos canais de negócios: Para acesso de terceiros ou parceiros, estes podem integrar através da APIs que agora agem como camada de entrada central para todos os serviços.
Conclusão
Este é um exemplo de trabalho que fazemos em vários clientes, atentando a particularidade de cada um deles, aplicando uma metodologia que chamamos de RNC(https://www.skalena.com/modernizacao-legados-skalena), em breve nós publicaremos a Parte II deste artigo, onde falaremos sobre estratégias para modernização WebServices/SOAP e na Parte III, sobre o conceito de Lift & Shift.
Quer bater um papo, tomar um café ou até uma sessão de 30 minutos de conversa sobre estes e outros assuntos? Mande uma mensagem para a gente:
Comments