Os microsserviços têm muitas vantagens para as equipas Agile e de DevOps. A Netflix, o eBay, a Amazon, o PayPal e outras estrelas da tecnologia evoluíram de uma arquitetura monolítica para uma arquitetura de microsserviços. Mas o que é e quais as vantagens desta arquitetura?
A arquitetura de microsserviços é um método distinto de desenvolvimento de software que tenta concentrar-se na construção de módulos com funções únicas e com interfaces e operações bem definidas. A tendência tem crescido nos últimos anos à medida que as empresas procuram tornar-se mais ágeis e avançar para um modelo de DevOps mais independente.
Sistema monolítico vs. Microsserviços
Ao contrário dos microsserviços, um sistema monolítico é construído como uma unidade única e autónoma. Assim, quaisquer alterações ao sistema são lentas, uma vez que o afetam no seu todo. Uma alteração feita numa pequena parte do código pode exigir a implementação e implantação de uma versão totalmente nova do software. Assim, escalar uma funcionalidade específica de uma aplicação significa também escalar toda a aplicação.
Os microsserviços resolvem os desafios dos sistemas monolíticos ao serem tão modulares quanto possível. Na sua forma mais simples, ajudam a construir um sistema como um conjunto de pequenos serviços, cada um a funcionar no seu próprio processo e a ser implementado de forma independente. Estes serviços podem ser escritos em diferentes linguagens de programação e podem mesmo utilizar diferentes técnicas de armazenamento de dados.
Embora isto torne as coisas mais escaláveis e flexíveis, precisa de uma remodelação dinâmica. Os microsserviços estão frequentemente ligados através de APIs e podem tirar partido de muitas das mesmas ferramentas e soluções que cresceram no ecossistema RESTful e de serviços Web. Os testes a essas APIs funcionam através da validação dos caminhos de comunicação e do fluxo de dados em toda a implantação (deployment) dos microsserviços.
Vantagens de utilizar esta arquitetura
| Mais simples de entender | O código é mais fácil de entender uma vez que as funcionalidades são isoladas e menos dependentes. |
| Reutilizável em toda a empresa | Pode partilhar pequenos serviços, como sistemas de pagamento ou de início de sessão, em toda a sua empresa. |
| Isolamento mais rápido de problemas | Quando um serviço é interrompido, é possível corrigir o erro mais rapidamente. |
| Risco minimizado de mudança | Evita o bloqueio de tecnologias ou linguagens – pode mudar rapidamente com um risco mínimo. |
Compreenda a arquitetura de Microsserviços
Tal como não existe uma definição formal do termo microsserviços, também não existe um modelo “padrão” que esteja representado em todos os sistemas baseados nesta arquitetura. Mas a maioria dos sistemas de microsserviços partilham alguns traços comuns:
1. Componentes Múltiplos
Estes sistemas podem ser divididos em vários serviços para que cada serviço possa ser implementado, ajustado e reimplementado de forma independente sem comprometer a integridade destes mesmos sistemas. Desta forma, pode ser necessário alterar apenas um serviço distinto em vez de reimplementar aplicações inteiras.
Mas esta abordagem tem as suas desvantagens, incluindo pedidos remotos caros, APIs remotas de maior granularidade e maior complexidade na redistribuição de responsabilidades entre componentes.
2. Construídos para o negócio
O estilo de microsserviços é normalmente organizado em torno das funcionalidades e prioridades do negócio. Ao contrário de uma abordagem de desenvolvimento monolítico tradicional – em que diferentes equipas têm um foco específico em, por exemplo, interfaces de utilizador, bases de dados, camadas de tecnologia ou lógica do lado do servidor – a arquitetura de microsserviços utiliza equipas multifuncionais.
Cada equipa é responsável por criar produtos específicos com base em serviços individuais. Nos microsserviços, uma equipa é proprietária do produto durante o seu tempo de vida, como na máxima frequentemente citada da Amazon: “You build it, you run it“.
3. Routing simples
Os microsserviços atuam, de certa forma, como o sistema UNIX clássico: recebem pedidos, processam-nos e geram uma resposta em conformidade. Isso é o oposto de como muitos outros produtos, como ESBs (Enterprise Service Buses), funcionam.
É aí que são utilizados sistemas de alta tecnologia para routing de mensagens e aplicação de regras comerciais. Pode dizer-se que os microsserviços têm endpoints inteligentes que processam a informação e aplicam a lógica, e “dumb pipes” através dos quais a informação flui.
4. Descentralizados
Como os microsserviços envolvem uma variedade de tecnologias, os métodos centralizados antigos não são opção. A comunidade de microsserviços favorece a descentralização para que os seus programadores possam produzir ferramentas que possam ser utilizadas por outros para resolver os mesmos problemas.
Assim, a arquitetura de microsserviços favorece a gestão de dados descentralizada. Os sistemas monolíticos utilizam uma única base de dados lógica em diferentes sistemas. Num sistema de microsserviços, cada serviço geralmente gere a sua base de dados exclusiva (database per service).
5. Resistentes a falhas
Os microsserviços são concebidos para lidar com falhas. Visto que vários serviços diferentes comunicam entre si, é muito possível que um serviço possa falhar (por exemplo, quando o fornecedor não está disponível). Nestes casos, o cliente deve permitir que os seus serviços “replicados” funcionem enquanto ele se tenta recuperar.
No entanto, a monitorização dos microsserviços pode ajudar a evitar o risco de uma falha. Por razões óbvias, este requisito aumenta a complexidade dos microsserviços em comparação com a arquitetura dos sistemas monolíticos.
6. Extensíveis
Os microsserviços permitem uma conceção extensível e, mais uma vez, são ideais para sistemas em que não é possível prever totalmente quais os futuros dispositivos que lhes irão aceder (como ilustra a imagem abaixo, é possível adicionar qualquer tipo de dispositivo).
Muitas aplicações começam com base numa arquitetura monolítica, mas, à medida que surgem vários requisitos imprevistos, podem ser lentamente reformuladas para microsserviços que interagem com uma arquitetura monolítica mais antiga através de APIs e de técnicas de transição de arquitetura como o Stranglar Fig pattern.
Exemplos de empresas que migraram para microsserviços
A Netflix tinha uma arquitetura generalizada que evoluiu de monolítica para SOA (Service-Oriented Architecture). Recebe mais de mil milhões de pedidos todos os dias, de mais de 800 tipos diferentes de dispositivos, para a sua API de streaming de vídeo. Cada pedido à API gera cerca de cinco pedidos adicionais para o backend.
A Amazon também migrou para microsserviços. Recebe inúmeros pedidos de uma variedade de aplicações – incluindo aplicações que gerem a API do serviço Web, bem como o próprio website – que teriam sido simplesmente impossíveis de gerir pela sua antiga arquitetura de dois níveis.
Leia também: