Microsserviços e arquitetura de microsserviços
Aprenda os prós e contras dos microsserviços e como eles diferem dos monólitos.
Não faz muito tempo que o jeito preferido de criar aplicativos era a arquitetura monolítica, uma unidade individual e autônoma. Essa abordagem funcionou bem para muitos desenvolvedores até os aplicativos ficarem mais complexos. Quando um pequeno trecho de código é alterado no sistema monolítico, é preciso reconstruir tudo, fazer testes e implementar uma versão nova do aplicativo.
Depois vieram os microsserviços, a abordagem que divide sistemas de software em unidades menores desenvolvidas e implementadas com autonomia. A arquitetura de microsserviços foi impulsionada pelo movimento DevOps, que busca fazer atualizações, como novos recursos, correções de bugs e melhorias de segurança, com frequência. Em muitos casos, ela também se tornou um caminho para empresas reescreverem aplicativos herdados usando linguagens de programação modernas e atualizações para a pilha de tecnologia.
Os microsserviços são uma coleção de unidades menores que sempre entregam e implementam aplicativos grandes e complexos.
O que são microsserviços?
A arquitetura de microsserviços, também conhecida como "microsserviços", é a abordagem de criação de aplicativos como uma série de serviços com implementação independente e desenvolvimento descentralizado e autônomo. Esses serviços são pouco integrados, implementáveis com independência e fáceis de manter. Enquanto o aplicativo monolítico é criado como unidade indivisível, os microsserviços dividem essa unidade em uma coleção de unidades independentes que contribuem para o todo. Os microsserviços são parte integral do DevOps, pois são a base para práticas de entrega contínua que permitem que equipes se adaptem com rapidez aos requisitos do usuário.
Um microsserviço é um serviço web responsável por parte da lógica de domínio. Vários microsserviços são combinados para criar um aplicativo, e cada um representa uma funcionalidade para o domínio. Os microsserviços interagem uns com os outros por meio de APIs, como REST ou gRPC, mas não têm conhecimento da atividade interna de outros serviços. Essa interação harmoniosa entre microsserviços é a arquitetura de microsserviços.
Com a arquitetura de microsserviços, desenvolvedores podem se organizar em equipes menores especializadas em serviços diferentes, com pilhas distintas e implementações dissociadas. Por exemplo, o Jira é formado por diversos microsserviços, e cada um representa uma funcionalidade específica, como pesquisa de itens, visualização de informações sobre o item, comentários, transições de item e muito mais.
Características dos microsserviços
Não existe definição formal para a arquitetura de microsserviços. No entanto, há padrões ou características comuns que valem a pena conhecer.
Componentes autônomos
O elemento básico da arquitetura de microsserviços é o componente, que pode ser um pacote de software, serviço web, recurso, aplicativo ou módulo com várias funções relacionadas. A explicação de Martin Fowler é mais simples: "componentes de software são aqueles que podem ter substituição e upgrades independentes".
Na arquitetura de microsserviços, cada componente pode ser desenvolvido, implementado, operado, alterado e reimplementado sem comprometer o funcionamento de outros serviços ou a integridade do aplicativo.
É possível combinar vários componentes para proporcionar uma experiência ao cliente ou agregar valor comercial. Os mais comuns são serviços e bibliotecas, mas também há diversos outros conceitos que podem ser aplicados à arquitetura de microsserviços, como ferramentas de CLI, aplicativos para dispositivos móveis, módulos de front-end, pipelines de dados, modelos de aprendizado de máquina.
Interfaces limpas
Depois que cada componente é escolhido, é necessária uma quantidade considerável de lógica para que eles se comuniquem por meio de mecanismos como RPC, REST por HTTP ou sistema baseado em eventos. Esses mecanismos podem ser métodos síncronos ou assíncronos, e os microsserviços podem usar uma combinação de ambos.
O aspecto mais importante é que cada microsserviço deve ter um contrato claro e intuitivo, que descreva o uso para o consumidor do serviço. Em geral, a API publicada junto do serviço conta com essas informações.
Você cria, você gerencia
A filosofia de DevOps "Você cria, você gerencia" enfatiza que não é possível mudar para a arquitetura de microsserviços sem pensar em como as equipes estão estruturadas. O DevOps realinha as motivações de todos os cargos funcionais — desenvolvimento, controle de qualidade, engenharia de lançamentos, operações — na equipe com o objetivo compartilhado de criar software de alta qualidade. Práticas de DevOps, como integração contínua/implementação contínua, testes automatizados e sinalizadores de funcionalidade aceleram a implementação e ajudam a manter a estabilidade e a segurança do sistema. Além disso, cada equipe pode criar e implementar microsserviços próprios sem afetar outras equipes.
A evolução da nuvem simplificou a criação, a implementação e a operação dos microsserviços. Técnicas de automação de infraestrutura, como integração contínua, entrega contínua e testes automatizados, ajudam as equipes.
Arquitetura orientada ao serviço vs. microsserviços
A arquitetura orientada ao serviço (SOA, na sigla em inglês) e os microsserviços são dois tipos de arquiteturas de serviço web. Assim como os microsserviços, a SOA é formada por componentes reutilizáveis, especializados e independentes. A distinção entre os dois tipos de arquiteturas é a classificação burocrática dos tipos de serviço.
Uma SOA tem quatro tipos básicos de serviço:
- Business
- Empresarial
- Aplicação
- Serviços de infraestrutura
Estes tipos definem as respectivas responsabilidades específicas para os domínios dos serviços subjacentes. Em comparação, os microsserviços têm apenas dois tipos de serviço: funcional e de infraestrutura.
Ambas as arquiteturas compartilham o mesmo conjunto de padrões em diferentes camadas de uma empresa. A arquitetura de microsserviços só existe por causa do sucesso do padrão da SOA. Portanto, o padrão da arquitetura de microsserviços é um subconjunto da SOA. Aqui o foco principal é a autonomia do tempo de execução de cada serviço.
Benefícios dos microsserviços
Agilidade
Equipes pequenas e independentes costumam criar serviços dentro dos microsserviços, o que é um incentivo para a adoção de práticas ágeis. Assim elas ganham autonomia e rapidez para trabalhar, o que encurta o ciclo de desenvolvimento.
Escalabilidade flexível
Os microsserviços são distribuídos por natureza e podem ser implementados em clusters. Assim, é possível ter escalabilidade horizontal dinâmica em todos os limites de serviço. Se o microsserviço atingir a capacidade de carga, novas instâncias desse serviço são implementadas com rapidez no cluster que o acompanha para ajudar a aliviar a pressão.
Lançamentos frequentes
Uma das principais vantagens dos microsserviços são os ciclos de lançamento frequentes e mais rápidos. Como elemento importante da integração e da entrega contínua (CI/CD), os microsserviços permitem que as equipes experimentem novos recursos e revertam caso algo não funcione. Assim, fica mais fácil atualizar o código, e o tempo de entrada no mercado para novos recursos diminui.
Flexibilidade tecnológica
Arquiteturas de microsserviço não costumam seguir uma abordagem definida com uma cadeia de ferramentas, mas permitem que equipes tenham a liberdade de escolher as ferramentas com que querem trabalhar.
Foco na qualidade
A separação dos problemas comerciais em microsserviços independentes garante que a equipe responsável pelo serviço esteja concentrada na entrega completa da qualidade.
Alta confiabilidade
Ao separar funcionalidades, os microsserviços reduzem o risco de destruir o aplicativo ou a base de código na hora de lançar atualizações. Além disso, é fácil isolar e corrigir falhas e bugs em serviços individuais. É possível implementar alterações apenas em um serviço específico sem afetar o aplicativo todo, o que aumenta a confiabilidade.
Desafios dos microsserviços
Dispersão do desenvolvimento
Mudar da abordagem monolítica para os microsserviços gera mais complexidade, pois são mais serviços, em mais locais, criados por várias equipes. Pode ser difícil ver como componentes distintos se relacionam entre si, quem tem determinado componente e como evitar o impacto negativo em componentes relacionados. Se essa dispersão não for gerenciada, o desenvolvimento vai ficar mais lento e o desempenho operacional vai ser ruim. Conforme o sistema cresce, é necessária uma equipe de operações experiente para administrar reimplementações constantes e alterações frequentes na arquitetura.
Falta de propriedade clara
Fica difícil saber quem é responsável pelo que na arquitetura de microsserviços. A equipe de DevOps pode gerenciar uma combinação de APIs, bibliotecas de componentes, ferramentas de monitoramento e imagens do Docker para que os usuários implementem um aplicativo. É importante ter informações sobre proprietários, recursos e relações em evolução entre outros componentes. Portanto, é fundamental ter comunicação e coordenação precisa entre diversas equipes, para que todos possam encontrar com facilidade o conhecimento necessário para entender o produto.
Custos exponenciais de infraestrutura
Cada novo microsserviço adicionado à implementação de produção vem com o próprio custo de pacote de testes, esquemas táticos de implementação, infraestrutura de hospedagem, ferramentas de monitoramento e muito mais.
Sobrecarga organizacional maior
São necessárias mais comunicação e colaboração para coordenar atualizações e interfaces entre equipes de arquitetura de microsserviços.
Depuração
Pode ser difícil depurar um aplicativo com vários microsserviços, cada um com um conjunto próprio de registros. Além disso, o processo de negócios pode ser executado em várias máquinas em momentos diferentes, complicando ainda mais a depuração.
Resposta a incidentes
É importante ter uma inteligência de resposta a incidentes com microsserviços que inclua informações como: quem usa o microsserviço, onde ele foi implementado, como foi implementado e com quem falar quando algo dá errado.
Microsserviços e DevOps: cara de um, focinho do outro
Com o aumento de complexidade e dependência entre os microsserviços, práticas de DevOps (como automação da implementação, do monitoramento e do ciclo de vida) agora são vistas como fundamentais para esse tipo de arquitetura. É por esse motivo que, muitas vezes, os microsserviços são considerados o primeiro passo na adoção da cultura de DevOps, que permite:
- Automação
- Escalabilidade aprimorada
- Capacidade de gerenciamento
- Agilidade
- Entrega e implementação mais rápidas
Tecnologias e ferramentas importantes para a arquitetura de microsserviços
Contêineres, Docker e Kubernetes
O conceito de contêiner é simples: um pacote com o aplicativo e todas as dependências, que facilita e consolida a implementação. Como não têm a sobrecarga de um sistema operacional, os contêineres são menores e mais leves do que as máquinas virtuais tradicionais. Portanto, são a combinação perfeita para serviços menores dentro das arquiteturas de microsserviços, porque podem ser iniciados e interrompidos com rapidez.
Com a proliferação de serviços e contêineres, é essencial orquestrar e gerenciar grandes grupos de contêineres. O Docker é uma plataforma popular de conteinerização e tempo de execução que ajuda desenvolvedores a criar, implementar e executar contêineres. No entanto, executar e gerenciar contêineres em escala só no Docker é um desafio. Existem outras soluções, como Kubernetes, Docker Swarm, Mesos e HashiCorp Nomad, que ajudam a lidar com a conteinerização em escala.
A conteinerização e a implementação de contêineres são o novo padrão de infraestrutura distribuída. Docker e Kubernetes empacotam o serviço em um contêiner completo que pode ser implementado e descartado com rapidez. Essas novas ferramentas de infraestrutura são complementares à arquitetura de microsserviços. Com um sistema de gerenciamento de contêineres, fica fácil conteinerizar, implementar e administrar microsserviços.
Gateways de API
Os serviços se comunicam entre si dentro da arquitetura de microsserviços por meio de APIs bem definidas. O gateway de API atua como proxy reverso, pois aceita as chamadas à API, coleta os serviços para processamento e retorna resultados. Além disso, os gateways de API disponibilizam uma abstração que atende a um único ponto de extremidade de API, mesmo que as APIs sejam atendidas por vários microsserviços. Os gateways de API também consolidam preocupações como limitação da taxa, monitoramento, autenticação, autorização e roteamento para o microsserviço correto.
Transmissão de mensagens e eventos
Por causa da natureza distribuída dos microsserviços, equipes precisam de meios para compartilhar mudanças de estado e outros eventos. Os sistemas de mensagens se comunicam entre microsserviços, permitindo que alguns microsserviços processem eventos como parte de sua interface principal. Por exemplo, alterações nas páginas do Confluence resultam em um evento que aciona reindexação de pesquisa e notificações para as pessoas que estão seguindo a página.
Registro e monitoramento
Com os microsserviços, fica difícil identificar e resolver um item em vários serviços. É importante ter ferramentas de observabilidade para registro, monitoramento e rastreamento, que ajudem a entender como os microsserviços se comportam, identificar e resolver possíveis problemas e depurar falhas.
Entrega e integração contínuas
Uma das principais vantagens dos microsserviços são os ciclos de lançamento frequentes e mais rápidos. Como elemento importante da integração contínua/implementação contínua, os microsserviços permitem que as equipes experimentem novos recursos e revertam caso algo não funcione. Assim, fica mais fácil atualizar o código, e o tempo de entrada no mercado para novos recursos diminui.
Portal do desenvolvedor
À medida que as arquiteturas distribuídas ficam cada vez mais complexas, as equipes de desenvolvimento podem se beneficiar de uma ferramenta que consolida informações sobre os resultados de engenharia e a colaboração da equipe em um só lugar. Por exemplo, o Atlassian Compass foi criado para ajudar a controlar a dispersão dos microsserviços com dados e insights em todas as cadeias de ferramentas DevOps.
Futuro dos microsserviços
A conteinerização e a implementação de contêineres são agora um padrão comum de infraestrutura distribuída. Ferramentas como Docker e Kubernetes empacotam o serviço em um contêiner completo que pode ser implementado e descartado com rapidez. Essas novas ferramentas de infraestrutura são complementares à arquitetura de microsserviços. Com um sistema de gerenciamento de contêineres, fica fácil conteinerizar, implementar e administrar microsserviços.
A adoção de microsserviços deve ser vista como uma jornada em vez de um objetivo imediato para uma equipe.
Comece aos poucos para entender os requisitos técnicos do sistema distribuído e escalar componentes individuais. Depois, extraia mais serviços à medida que ganha experiência e conhecimento.
Gerencie microsserviços com o Compass
O Atlassian Compass ajuda a gerenciar a complexidade da arquitetura de microsserviços distribuída e escalável. É a plataforma extensível para experiência do desenvolvedor, que reúne informações desconectadas sobre resultados de engenharia e colaboração da equipe em local central e pesquisável. Além de ajudar a controlar a dispersão de microsserviços com o Catálogo de Componentes, o Compass ajuda a estabelecer práticas recomendadas e mensurar a integridade do software com Indicadores de desempenho, bem como disponibilizar dados e insights em toda a cadeia de ferramentas de DevOps usando extensões criadas na plataforma do Atlassian Forge.
