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 microsserviç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 microsserviços.
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 microsserviços.
Por 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 microsserviç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.
Parece natural definir os microsserviç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 microsserviç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 microsserviç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 microsserviç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.
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 microsserviç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.
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 microsserviç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.
Toda a ideia por trás da mudança para a arquitetura de microsserviç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 microsserviç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.
É 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 microsserviços. Na verdade, é mais correto dizer que os microsserviç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 microsserviç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 microsserviç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 microsserviços.
Podemos concordar que preparar adequadamente a transição para uma arquitetura de microsserviç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 microsserviços oferecem.
Fonte: DZone.com
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.