5 passos para preparar uma arquitetura de microserviços

Como disse o sábio certa vez: “A primeira regra de qualquer tecnologia usada em uma empresa é que a automação aplicada a uma operação eficiente ampliará a eficiência. A segunda é que a automação aplicada a uma operação ineficiente aumentará a ineficiência.” Alguém duvida que essa filosofia também se aplica aos microserviços? Não preparar sua organização para esta transição provavelmente resultará em falha. É por isso que, neste post, passaremos pelas 5 etapas que você precisa seguir para se preparar para a implementação de uma arquitetura de microserviços.

#1. Comece desenhando

Muitos desenvolvedores cometem o erro de recorrer diretamente ao código ao desenvolver um determinado microserviço. Este é provavelmente o maior erro que se pode cometer. Sim, talvez você tenha sucesso em criar um serviço; no entanto, à medida que seu número aumenta, o todo se tornará uma enorme bagunça.

Como qualquer outro produto que precisa ser criado, o processo deve começar com a concepção. E, por projetar, entenda-se reunir toda a equipe em torno da mesa e, literalmente, desenhar os serviços no papel (ou em um quadro branco). Comece por determinar a função principal do aplicativo que você está construindo. Então, ao fazer uma abordagem de cima para baixo, divida-o nas menores unidades possíveis. Finalmente, apresente a interconectividade de todas essas peças distintas. Estes são os recursos que se tornarão seus microserviços.

devops-kanbanPor exemplo, em uma aplicação de revisão de livros, a principal função é a comparação entre diferentes livros. No entanto, muitos outros recursos devem ser desenvolvidos, como criar perfis de usuários, classificação, comentários, um banco de dados de livros etc. Identificar cada um desses recursos é crucial para refleti-los em uma arquitetura de microserviços.

Esse processo durará mais de um dia e exigirá muitas iterações até a conclusão. Claro, você precisará de informações de muitas pessoas de vários departamentos para obter pontos de vista e opiniões diversos, bem como para garantir que não perca nenhuma funcionalidade do seu sistema.

#2. Microserviços não são unidades organizacionais

Parece natural definir os microserviços de acordo com as unidades organizacionais da sua empresa. Isso pode parecer uma solução adequada se você estiver construindo uma aplicação monolítica. No entanto, pode ser a decisão errada na implementação da arquitetura de microserviços.

Talvez funcione para o departamento de vendas ou serviços ao cliente, mas muitas organizações possuem uma única unidade que lida com todos os bancos de dados. Assim, criar um microserviço para todos os bancos de dados levará a um único ponto de falha. E essa é uma das principais características dos microserviços: justamente NÃO ter um único ponto de falha!

Algumas das funções que você deseja apresentar através dos seus serviços provavelmente se estenderão por vários departamentos organizacionais, ou talvez você precise construir muitos microserviços para um único departamento. E por fim, você deve concentrar a arquitetura nas funções que deseja fornecer, em vez da estrutura organizacional da empresa.

#3. Criando estruturas adequadas de equipe

Alternar para uma estrutura arquitetônica completamente diferente certamente exigirá mudanças nas atividades gerenciais e de monitoramento na empresa. O foco nas duas primeiras etapas foi projetar o aplicativo para fornecer a função certa aos seus usuários finais. Agora, é hora de garantir que você tenha o suporte operacional apropriado para a nova arquitetura.

Você terá que abandonar a antiga estrutura departamental e concentrar as equipes em torno de certos microserviços. Isso significa que cada uma dessas equipes será composta por vários membros com diferentes conjuntos de habilidades, como analistas de sistemas, designers UX/UI, desenvolvedores de backend e frontend etc. Desta forma, as equipes são responsáveis por seu projeto (microserviço) de ponta a ponta – desde o desenvolvimento e implementação até operações, monitoramento e gerenciamento. Isso, por sua vez, aumentará a motivação para criar o produto do qual eles se sentem parte, como co-criadores de alguma forma.

microservices-development-lifecycle-1
O tamanho das equipes será determinado pelo tamanho total da empresa/projeto; No entanto, é recomendável que o tamanho ideal seja de 8 a 10 pessoas por equipe. Além disso, ao contrário da arquitetura monolítica, uma arquitetura de microserviços permite que você dimensione as equipes enquanto se ocupa de fazer crescer o negócio.

É claro que todas as equipes colaborarão ativamente com a finalização de todo o projeto. Isso nos leva ao principal benefício desse tipo de estruturação – uma entrega muito mais rápida do produto final ao mercado.

#4. Desempenho e confiabilidade são importantes, também

Toda a ideia por trás da mudança para a arquitetura de microserviços tem por objetivo criar um produto final com maior desempenho do que o monolito, e também mais confiável (ou seja, com menor risco de inatividade) e, claro, que possa ser entregue ao mercado mais rapidamente.

É importante abordar o desempenho como parte do processo de design para garantir que todos os problemas potenciais sejam considerados logo no início do projeto. Muitas vezes, os problemas surgem do fato de que os projetos de microserviços se concentram principalmente na funcionalidade. No entanto, o serviço se tornará inútil se falhar ou diminuir significativamente a primeira vez que recebe uma carga maior. Todo serviço deve ter dois ou três mecanismos alternativos para usar e continuar operando quando os recursos subjacentes falham, e devem percorrê-los rapidamente se os recursos não responderem dentro de um período de tempo aceitável. Pensar em como preparar seu serviço para maiores variações de carga ajudará seu aplicativo a enfrentar desafios reais, dando-lhe uma vantagem competitiva no mercado.

#5. Planeje as mudanças que virão

É impossível ignorar as alterações de aplicativos ao longo do tempo. Os desenvolvedores adicionam e removem recursos o tempo todo; eles mudam o código, substituem os elementos principais do aplicativo, e assim por diante, o tempo todo. Isso é ainda mais presente com uma aplicação de microserviços. Na verdade, é mais correto dizer que os microserviços estão em constante evolução.

Quando lidamos com atualizações de código várias vezes ao dia, é melhor aceitar que a mudança é uma constante, e não uma interrupção ocasional de um estado estável. Depois de reconhecer isso, você perceberá que é importante integrar a flexibilidade necessária para a mudança desde o início. Uma maneira de certificar-se de que seu aplicativo funciona corretamente o tempo todo é preparar APIs de serviços para que os microserviços individuais possam continuar interagindo uns com os outros, mesmo que mudem. Além disso, você deve incluir o controle de versão para permitir que os serviços incluam interfaces de serviço novas e antigas.

Por outro lado, a evolução do armazenamento de dados é muito mais desafiadora. A evolução dos esquemas de banco de dados para suportar novos recursos tradicionalmente tem sido a parte mais difícil de atualizar em um aplicativo e os microserviços não facilitam. No entanto, a nova tecnologia dos bancos de dados NoSQL é muito mais flexível em termos de adicionar novos campos sem interromper a estrutura existente. Se você espera que seus requisitos de armazenamento de dados evoluam (e quem não?), pense em incorporar o armazenamento de dados evolutivo como parte do esforço de design do dos microserviços.

Podemos concordar que preparar adequadamente a transição para uma arquitetura de microserviços é um fator chave no sucesso de todo projeto. Somente com planejamento cuidadoso, design thinking inovador e estrutura operacional e gerencial adequada é possível obter todos os benefícios que os microserviços oferecem.

Fonte: DZone.com

21