[ETP] Viabilidade de sistemas robustos se tornarem microsserviços

ESTUDO TÉCNICO PRELIMINAR - ETP

O time Titãs realiza as manutenções de diversos sistemas, sendo eles até este momento: SID, Skala, Comunique-se e Cegonha. Devido a um levantamento técnico se cogitou a implementação de serviços que são fracamente acoplados. Para viabilidade desse tipo de implementação, uma sugestão foi aplicar a arquitetura de microsserviços. De forma conceitual a arquitetura de microsserviços permite a entrega rápida, frequente e confiável de aplicativos grandes e complexos.  No entanto, serão expostos neste estudo os aspectos positivos e negativos deste tipo de arquitetura.

 

2 - O QUE É NECESSÁRIO PARA ATENDER A NECESSIDADE

Para atendimento deste tipo de demanda a primeira situação a se considerar é que grande maioria dos sistemas da SETIC possuem arquitetura monolítica, ou seja, possui apenas um aplicativo como uma única unidade implantável. Posto isto, para uma possível implementação é necessário avaliar a arquitetura, processo e organização conforme ilustração a seguir: 

Fonte: https://microservices.io/

No mesmo site da ilustração anterior, está disponível um questionário de avaliação mais detalhado. Este questionário tem por objetivo avaliar o que foi construído e como melhorar, maximizar os benefícios da arquitetura e reduzir o risco arquitetônico e organizacional, vejamos:

• Velocidade de desenvolvimento: Determinar se está se beneficiando totalmente da arquitetura de microsserviços.
• Arquitetura básica: É essencial que a arquitetura base forneça todos os recursos exigidos pelos serviços.
• Infraestrutura de desenvolvimento: Fornecer infraestrutura amigável ao desenvolvedor que disponibilize o suporte necessário para desenvolver seus serviços.
• Organização e processo: Avaliar se a organização e o processo estão corretos para se beneficiar adequadamente dos microsserviços.
• Design de serviço individual: Cada serviço deve ser projetado adequadamente e um bom adepto da arquitetura base.

São necessários passos que antecedem a implementação da arquitetura em questão, seguindo esses pré-requisitos fica mais óbvio os problemas que serão enfrentados. Portanto deve-se ter critério antes de qualquer implementação prática.

 

3 - COMPLEXIDADES DE IMPLEMENTAÇÃO

O autor renomado de padrões de microsserviços, Chris Richardson,  detalha vários antipadrões da adoção de microsserviços que  observou enquanto trabalhava com clientes em todo o mundo. As complexidades de implementação pode diversificar os desafios que as empresas geralmente enfrentam devido aos antipadrões.

Para um melhor entendimento do que seria os antipadrões, será abordado suas definições com base na mesma óptica:

• Pó mágico mágico - acreditando que os microsserviços vão curar todos os seus problemas de desenvolvimento
• Microsserviços como objetivo - com foco na adoção de microsserviços em vez de melhorar a velocidade e a confiabilidade da entrega de software
• Adoção dispersa - vários grupos com uma organização adotam microsserviços e implementam infraestrutura de suporte sem qualquer coordenação
• Tentando voar antes que você possa andar - tentando adotar microsserviços sem as principais habilidades de desenvolvimento, como testes automatizados e a capacidade de escrever código limpo
• Foco na tecnologia - foco na tecnologia legal (de implantação) em vez da essência da arquitetura de microsserviço: decomposição e definição de serviço
• Quanto mais, melhor - desenvolvendo uma arquitetura excessivamente refinada
• Lei de bandeira vermelha - manter em vigor políticas e processos que obstruem a entrega de software rápida, frequente e confiável.

 

 

4 - POSSÍVEIS PROBLEMAS

4.1. Problemas gerais

Um desafio com o uso dessa abordagem é decidir quando faz sentido usá-la. Ao desenvolver a primeira versão de um sistema, muitas vezes não se tem os problemas que essa abordagem resolve. Além disso, usar uma arquitetura elaborada e distribuída poderá retardar o desenvolvimento. Isso pode ser um grande problema para a SETIC, cujo maior desafio geralmente é evoluir rapidamente as entregas e a qualidade.

Em casos de sistemas já em operação que precisam ser migrados o problema é de maior impacto. Pois será necessário utilizar a decomposição funcional e as dependências emaranhadas podem dificultar a decomposição de um sistema monolítico em um conjunto de serviços.

Idealmente, cada serviço deve ter apenas um pequeno conjunto de responsabilidades. Cada serviço faz exatamente uma coisa, geralmente excepcionalmente bem, e deve ser combinado com outros utilitários para executar tarefas complexas.

A aplicação da arquitetura pode facilitar manutenções. Mas é importante se observar que a arquitetura por si só, não fornece somente benefício, pois é extremamente necessário que seja aplicado em um contexto condizente com as vantagens trazidas por ela.

O arquiteto de software Chris Richardson, relata que as autoavaliações são necessárias para criar uma hipótese da implementação das arquiteturas, de acordo com suas próprias definições são elas:

• Prontidão de microsserviços - avaliar se a organização está pronta para adotar microsserviços
• Aplicabilidade de microsserviços - avaliar se a arquitetura de microsserviços é adequada para o aplicativo
• Avaliação da Arquitetura de Microsserviços - avaliar a arquitetura de microsserviços do aplicativo, identificar áreas para melhorar e aprender a como melhorá-las

Por fim, o contexto para implementação dessa arquitetura tem que ser favorável para a organização e para aplicação a ser decomposta, a divisão de times na SETIC pode também ser um ponto a  ser considerar, visto que o time deve ter capacidade de pessoal suficiente para atender as manutenções de uma estrutura em microsserviços.

 

5 - VALOR AGREGADO

Existem inúmeros outros exemplos de empresas que utilizam a arquitetura de microsserviços.

 

6 - CONCLUSÃO DO ESTUDO

O presente ESTUDO TÉCNICO PRELIMINAR, elaborado pelos integrantes TÉCNICOS do time TITÃS, considerando a análise dos desafios técnicos envolvidos e citados, conclui pela RECOMENDAÇÃO DA IMPLEMENTAÇÃO DA ARQUITETURA DE MODO CRITERIOSO, uma vez que foram considerados as vantagens e desvantagens em termos de eficiência, principalmente potenciais problemas que afetem a disponibilidade do serviço. Em complemento, os contratempos identificados são administráveis, pelo que RECOMENDAMOS o prosseguimento da demanda a iniciar pelo sistema CEGONHA, uma vez que, o projeto é recentemente e por isso, mais adepto à novas mudanças.