Como implementar seu projeto de microsserviços (parte 3)

Empresários trabalhando em um espaço de escritório híbrido

Como implementar seu projeto de microsserviços (parte 3)

Nesta série de seis partes sobre o desenvolvimento de aplicações de microsserviços, fornecemos um contexto para a definição de um projeto piloto baseado na nuvem que melhor se adapte às necessidades atuais e se prepare para uma decisão de adoção da nuvem em longo prazo.

Aqui, na parte 3: fornecemos um método para implementar seus próprios projetos de microsserviço.

Evolução de uma aplicação existente

Agora, nos aprofundamos em como traçar um caminho para jornadas específicas de desenvolvimento de aplicativos de microsserviços de diferentes escalas e com vista a uma possível progressão de transformações de menores para maiores escalas de aplicações existentes.

Embora a criação de projetos de microsserviços sem uma aplicação prévia seja relevante ou importante, concordamos com uma abordagem de "prioridade no monólito" na construção de microsserviços. Resumindo, isso significa que você constrói sua aplicação da maneira que puder para validar sua ideia primeiro. Em seguida, você aplica os princípios desta série do blog para escalar e evoluir seu monólito inicial para um projeto de microsserviço. Não há valor na criação de microsserviços arquitetonicamente puros que não agregam valor ao negócio.

Existem três áreas que você precisa conhecer para implementar um projeto de microsserviços bem-sucedido: sua empresa, sua cultura e conjunto de habilidades e sua tecnologia.

Entenda e defina suas necessidades de negócios

Por que você está pensando em migrar para microsserviços? Muitas empresas precisam de práticas mais eficientes no desenvolvimento e na operação de software para agregar valor ao negócio de forma mais rápida e oferecer melhores experiências ao usuário.

Antes de compreender o impacto de um projeto de microsserviço em suas aplicações e infraestrutura existentes, você precisa compreender quais partes de sua empresa estão avançando lentamente para produzirem resultados satisfatórios. Em muitos casos, os sistemas de engajamento (SOE) da organização estão causando a desaceleração. Esses sistemas estão disponíveis por meio de muitos canais: web, dispositivos móveis, APIs etc. A falta de velocidade é o principal motivo para migrar para uma arquitetura baseada em microsserviços.

Antes de adotar uma abordagem orientada a microsserviços, você e os stakeholders de sua empresa precisam saber o que não está chegando ao mercado rápido o suficiente. Quais partes da aplicação precisam de melhorias e modificações para torná-las mais rápidas? A resposta a essa pergunta envolve quais partes do monólito existente devem ser direcionadas para a evolução de microsserviços.

Use fluxos de experiência do usuário ou diagramas de arquitetura para ajudar a equipe a criar rapidamente seções do monólito existente por meio de anotações no estilo de mapa de calor. Por exemplo, usando a escala Vermelho-Amarelo-Verde para prioridade de pontos problemáticos, aqui está um arquivo de aplicação web para uma loja:

 
Diagrama mostrando a arquitetura de uma aplicação Storefront WAR. Ele contém cinco módulos em stack rotulados de cima para baixo: "loja", "catálogo", "recomendações", "inventário" e "faturamento". Cada módulo é representado como um bloco horizontal colorido dentro do contêiner geral do Storefront WAR.

Neste ponto, sem ser exaustivo e com uma abertura para ser iterativo, os principais objetivos da avaliação são:

  • Identificar as funções de negócios separadas que seu monólito está fornecendo

  • Entender a velocidade relativa e a complexidade necessárias para mudar essas funções de negócios

  • Entender o desejo do proprietário da empresa para ver ciclos de feedback mais rápidos para funções comerciais específicas

Entenda sua cultura e conjunto de habilidades

Embora não seja específico das arquiteturas baseadas em microsserviços, uma compreensão completa das equipes, da cultura e do conjunto de habilidades de uma organização é crítico para uma transformação digital bem-sucedida.

Normalmente, nos monólitos de engenharia, a maioria das organizações é incorporada em silos, com as equipes participando conforme necessário ao longo do ciclo de vida de desenvolvimento de software. Isso muitas vezes cria limites bem definidos, com funções e responsabilidades restritivas ao longo desses limites.

Texto alternativo (em inglês): diagrama mostrando uma estrutura de equipe dividida em funções e serviços. As linhas representam Serviço A, Serviço B e Serviço C. As colunas representam Proprietários de Negócios (amarelo), Líderes de Projeto (roxo), Desenvolvedores (vermelho), Operações (verde) e Arquitetos (azul). Cada serviço tem um membro de cada função, indicado por ícones coloridos de usuário alinhados em uma grade.

As arquiteturas de microsserviço só têm sucesso quando as equipes têm o poder possuir o ciclo de vida completo de desenvolvimento e operações de software.  Criar equipes multifuncionais representando todas as funções e responsabilidades é fundamental na implementação de arquiteturas baseadas em microsserviço.  Todos, do projeto ao desenvolvimento, das operações e ao proprietário do negócio, trabalham em estreita colaboração e, muitas vezes, estão colocalizados.

Como cada stakeholder é representado na equipe por projeto, desenvolvimento e operações, o trabalho pode migrar mais rápido, eficientemente, e com foco claro em melhorar a experiência do usuário para atingir os objetivos de negócios.

Diagrama mostrando uma estrutura de equipe multifuncional. As linhas representam o Serviço A, Serviço B e Serviço C, cada um delineado com caixas vermelhas para destacar os agrupamentos de equipes. As colunas representam funções: Proprietários de Negócios (amarelo), Líderes de Projeto (roxo), Desenvolvedores (vermelho), Operações (verde) e Arquitetos (azul). Cada serviço inclui um membro de cada função, enfatizando a colaboração entre as disciplinas.

Uma equipe multifuncional também apoia o rápido crescimento de habilidades individuais em toda a equipe.  Quando uma equipe possui tudo pelo qual o microsserviço é responsável, desde o projeto até as operações e os dados de tempo de execução, nenhum membro da equipe realiza uma única tarefa. Frequentemente, os engenheiros de front-end desenvolvem habilidades de administração de banco de dados, enquanto os membros da equipe orientados para operações aprendem mais sobre as diferenças nos frameworks de interface do usuário. Expandir o conjunto de habilidades dessa forma ajuda toda a organização a ter sucesso com microsserviços, pois é muito mais fácil construir novas equipes de membros bem-sucedidos do que procurar constantemente especialistas para preencher papéis muito específicos.

Entender a tecnologia

A menos que você lide com o problema de negócios e a cultura e o conjunto de habilidades de sua equipe, você não conseguirá implementar a tecnologia de microsserviços com eficácia e manterá os mesmos processos e estruturas em funcionamento.

A análise adequada das stacks de tecnologia existentes varia muito de uma organização para outra, mas a abordagem simplificada que descrevemos ajuda a garantir o sucesso inicial e sustentado dos seus projetos de microsserviços. Começar aos poucos e definir sucessos iterativos e progressivos é uma abordagem muito mais viável e frutífera do que uma abordagem chamativa de transformar tudo de uma só vez.

Diagrama "Entenda a tecnologia"

A primeira fase do entendimento da sua tecnologia é identificar os serviços detalhados que estão no monólito existente.  A identificação desses serviços detalhados do curso ajuda você a entender a complexidade das estruturas de dados, o nível de acoplamento entre os componentes atuais, as equipes responsáveis por esses novos serviços detalhados e assim por diante. Uma avaliação detalhada dos serviços oferece uma compreensão clara dos limites dos dados, tanto dentro de um determinado serviço quanto entre serviços.

Depois de identificar os serviços de baixa granularidade, você deve criar um plano de como evoluir esses serviços de granularidade média para microsserviços de baixa granularidade. Esses microsserviços, com base em seu trabalho anterior, devem estar trabalhando com dados semelhantes, possuindo seus "próprios" dados e entendendo quais dados eles precisam ler de onde e escrever em outros serviços. A partir daqui, você pode identificar e implementar a resiliência, a escalabilidade e a agilidade dos microsserviços individuais finos.

APIs e microsserviços são duas partes de um todo maior.  Depois de ter uma melhor compreensão dos seus microsserviços detalhados, você também terá uma melhor compreensão das suas interfaces, quais interfaces estão no caminho crítico, quais interfaces são opcionais e quais interfaces você não precisa mais.  Se você não conseguir mapear uma interface ou API existente para um de seus microsserviços, provavelmente você pode eliminá-la.

Dimensionamento do esforço de microsserviços

O trabalho pesado de entender o negócio, entender a estrutura da equipe e entender a tecnologia garante que suas equipes e a organização maior estejam preparadas para compreender toda a evolução dos microsserviços de qualquer monólito, seja em um escopo de prova de conceito, escopo piloto ou escopo de evolução em grande escala.

Com todo o trabalho de análise e planejamento concluído, a próxima etapa é definir cronogramas, velocidades de entrega e resultados.

No próximo post, consideraremos padrões de desenvolvimento e operações que você pode aplicar ao realizar uma transformação de microsserviços.

O que fazer a partir daqui:

Roland Barcia (IBM Distinguished Engineer/CTO) e Rick Osowski (Membro Sênior da Equipe Técnica) colaboraram com Kyle neste post.

Autora

Kyle Brown

IBM Fellow, CTO

IBM CIO Office