Viabilidade de sistemas robustos se tornarem microsserviços

1. Glossário de Termos

2. Introdução

3. Desenvolvimento - Viabilidade de sistemas robustos se tornarem microsserviços

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.1. 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.

Para que a implementação da arquitetura não possua as mesmas vantagens e desvantagens de uma aplicação monolítica, é necessário levar em consideração técnicas contra antipadrões nos projetos, essas práticas acabam dificultando uma série de vantagens e ainda aumentam a complexidade de implementação envolvida.

3.2. 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.

3.3. Valor agregado

Para dimensionar o valor agregado da aplicação da arquitetura se faz necessário citar empresas que estão utilizando os padrões de microsserviços em sua totalidade, vejamos como exemplos: Uber, Netflix e Ebay. Para melhor exemplificar, a Uber como muitas startups, começou sua jornada com uma arquitetura monolítica, construída para uma única oferta em uma única cidade e posteriormente devido a necessidade de expansão, foi necessário transformar os serviços em microsserviços.

4. Conclusão

4. Referências