Nos últimos anos o “hype” dos Microservices ganhou muita força, e não é para menos. Com garotos propaganda como Amazon e Netflix fica difícil argumentar contra. Mas o que os CIOs precisam saber sobre Microserviços?

Essas gigantes destruidoras de modelos de negócios “tradicionais” são os maiores cases de Arquiteturas Microservices, e convenhamos, elas deram MUITO certo, mas no fim das contas, o que significa tudo isso?

A Arquitetura de Microserviços (ou Microservices Architecture) é mais um design pattern para arquitetura de software. Ela consiste em diversos serviços independentes que executam funções de negócios específicas, e o acoplamento desses serviços deve ser feito através de um protocolo simples e leve, por isso RESTful APIs são normalmente o “go to” na hora de fazer essas integrações.

A vantagem de uma arquitetura assim é a possibilidade de separar cada “bloco” por valor entregue ao usuário. Isso leva a serviços bastante específicos e menores, facilitando a manutenção do software e adicionando flexibilidade, especialmente se comparado a sistemas monolíticos mais engessados.

Mas então, o que você precisa saber sobre Arquitetura Microservices antes de pular de cabeça?

Off the Shelf

Como todas as práticas e modelos arquiteturais, Microservices também não é algo “comprável”, você não decide comprar numa loja uma solução pronta para o seu negócio e pronto, sua empresa já está rodando neste modelo

É necessário entender o cenário e todos os detalhes do modelo para implementar algo assim, pois cada monolítico apresenta desafios diferentes e específicos, e isso ocorre até mesmo em cenários em que uma aplicação será criada do zero.

On-Premise ou Cloud? Eis a questão!

Uma das principais variáveis consideradas é a forma de deploy, a opção por Cloud ou On-Premise é crucial, já que um dos benefícios esperados nesse modelo é exatamente a velocidade de Deploy, para aplicações Cloud fica muito claro esse ganho, já situações On-Premise podem demandar uma infraestrutura diferente da atual e alguns esforços de coordenação desses Deploys.

O que me leva ao próximo ponto:

DevOps is the way to go!

Se você está falando em velocidade de Deploy, você está falando de DevOps e ponto.

Um dos principais drivers de Microservices é a possibilidade de você ter as funcionalidades daquele “Microserviço” orientadas pelas demandas de negócio, e possibilitar que esse Microserviço seja experimentado, alterado e inovado na velocidade necessária para atender a essas demandas. E a melhor forma de garantir isso é através de DevOps e releases contínuos

Mas essa não era a ideia por trás de SOA?

Já faz algum tempo (décadas, pra ser mais preciso) que falamos de SOA, e de certa forma ambos compartilham várias práticas: Baixo acoplamento, serviços independentes e etc. Você com certeza vai ouvir bastante gente defendendo que não existe diferença entre eles e vice-versa.

Essa é uma discussão que demandaria uma mesa de bar e alguns chopes, alguns dizem que a adoção de um ESB é mandatório para SOA, ou usam os protocolos de comunicação como forma de diferenciar um do outro, ou que até mesmo a diferença entre eles está na granularidade dos serviços.

De qualquer forma, existe uma grande semelhança entre os conceitos fundamentais de SOA e Microservices, mas eles podem, e devem coexistir.

Os Microserviços são uma forma de aplicar os conceitos de SOA, muito das implementações convencionais de SOA criavam uma camada de serviço sobre as aplicações, o que replicavam dados e processos, enquanto Microserviços tornam o “Serviço” dono das informações e processos, enquanto as Aplicações passam a ser canais consumidores desses serviços expostos como REST.

Nova Organização: Nova organização

O título aí em cima não está errado não! 🙂
Adotar uma arquitetura de Microserviços impacta a arquitetura da Organização, mas também pode ter um impacto na organização das Equipes de TI, não aumentando nem reduzindo, mas especializando.

Algumas empresas, ao adotarem uma arquitetura assim, re-organizaram suas equipes para atender à demandas de negócio específicas, equipes altamente especializadas em alguns serviços. E os resultados surgem na forma de melhorias significativas de “time-to-market”, uma dedicação exclusiva ao valor entregue por aquele serviço específico e o aumento da autonomia e responsabilidades dessas equipes dentro de ambientes confinados.

Um bom exemplo de uma “reorganização” é a metodologia de “Squads” implementadas no Spotify, em que cada “Squad” possui pessoas de diferentes skills técnicos focadas em uma “Missão”, e essa missão normalmente é um serviço específico e eles são os especialistas que irão desenvolver esse serviço e resolver qualquer problema. A Cultura da Engenharia do Spotify tem ganho adeptos em diversos departamentos de P&D e TI, nesse link, eles contam um pouco sobre como eles implementaram. 

Em 2015 nós tivemos o Jamie Kirkpatrick do Spotify palestrando no APIX, um conteúdo espetacular sobre a equipe de desenvolvimento deles que você pode ver aqui.

Os microserviços precisam ser gerenciados

Uma das maneiras mais eficiente de suportar uma Arquitetura de Microserviços é utilizar uma plataforma de Gerenciamento de APIs, como o Sensedia API Management Suite, já que como falei, todo microserviço deve ser RESTful.

Uma plataforma como essas vai oferecer as funcionalidades necessárias para que as integrações entre seus microserviços e até seu Backend sejam gerenciadas e monitoradas. Além de oferecer segurança não só contra ataques direcionados a sua API mas também contra integrações que possam gerar uma sobrecarga na sua API. Outra feature importante para se considerar em uma plataforma como essas é a possibilidade de gerar métricas e indicadores das suas APIs, não só de “saúde” como de Negócios também.

Nesse link, nós falamos especificamente sobre como API Management habilita uma Arquitetura Microserviços.
E se você quiser se aprofundar nesse assunto, assista nosso Webinar sobre as Vantagens e Desvantagens de uma arquitetura Microserviço.