Há tempos estamos destacando os desafios de arquiteturas baseadas em microsserviços. Inclusive, já fomos muito “vocais” alertando que sua empresa provavelmente não precisa dessa complexidade. Entretanto, há exceções.

Nessa série falaremos sobre cenários onde microsserviços fazem sentido. Além disso, vamos tentar indicar práticas e padrões que ajudem na jornada de adoção.

NOTA: É interessante que você veja nosso posicionamento sobre arquitetura de software antes de continuar a leitura.

O mito da aplicação monolítica

Embora se confronte muito a ideia de arquiteturas baseadas em microsserviços com aplicações monolíticas, este não é o debate que encontramos na maioria de nossos clientes de maior porte.

Boa parte de nossos clientes tem histórico de implantação de alguma variante de arquitetura baseada em serviços (SOA) que podem ser explicadas pela figura que segue:

A ideia básica é a seguinte:

• Um conjunto de sistemas, geralmente em tecnologia legada, junto com sistemas mais novos, alguns até rodando na nuvem, suportam o negócio da organização.
• Sobre o conjunto de aplicações legadas, um conjunto de serviços apresentam interfaces de negócio para suportar processos, inicialmente de integração, que “expõe” os sistemas de base com algum nível de governança
• A comunicação entre os diversos sistemas legados é viabilizado por um ESB (geralmente corporativo, bem “caro”, e de um fornecedor de grande nome). Esse “ESB” entrega um conjunto de features incluindo, além de mensageria, políticas de governança, transformação de dados, segurança (autenticação e autorização), etc.
•  Um conjunto de aplicações clientes se comunica com os serviços, geralmente através da ESB.

Cada um dos sistemas da empresa e, muitas vezes, muitos dos serviços são mantidos como monolíticos locais, cada um com seu banco de dados.

Não é raro que os sistemas sejam desenvolvidos em tecnologicas legadas (MUMPS, COBOL, etc.) Os serviços geralmente estão implantados usando protocolos pegados, como SOAP.

O “problema” da Transformação digital (API-economy)

As pressões da Transformação Digital tem levado as empresas a adicionarem uma camada extra a arquitetura indicada acima.

Na tentativa de se tornarem mais “abertas”, conectadas e digitais, as empresas estão fornecendo APIs para facilitar a conexão com seus clientes.

Problemas a superar

Considerando que a lei de Conway seja válida (e acreditamos que ela seja), é bem difícil suportar uma organização para manter a arquitetura descrita acima.

[tweet]Invariavelmente, os sistemas legados, cedo ou tarde, se convertem em gargalos[/tweet] e acabam sendo mantidos por “silos”, as vezes bem intencionados, com gente que se esforça para suportar o ritmo de modificação de dados demandado pelas “novas APIs”. Entretanto, não é raro que recursos de “contingenciamento” precisem ser implantados de forma que os modificações fiquem represadas por mais tempo que o ideal para o negócio.

Também não é incomum que o ESB acabe assumindo muito mais tarefas do que deveria (sobretudo aplicação de regra de negócio).

Por que microsserviços são recomendados nesse cenário?

Acreditamos que, para cenários descritos acima, microsserviços fazem sentido, primeiro pelo aspecto organizacional (autorizando a ideia de eliminar silos de TI).

Outro ponto importante e que não pode ser ignorado é que a arquitetura descrita acima é cara para manter e, sobretudo, para atualizar. Não é incomum encontrarmos empresas onde o “negócio” deseja acelerar o ritmo das mudanças (o que é um imperativo) mas não conseguem em função do “peso” da tecnologia.

Concluindo

Depois da moda da “recomendação sem sentido por microsserviços”, iniciou-se uma nova moda tentando dizer que eles não são necessários para quase nenhum caso. Nós, da EximiaCo, entendemos que estratégias baseadas microsserviços podem, sim, ajudar a área de tecnologia a ser enabler de inovações, principalmente em cenários corporativos de grande porte.

Nos próximos posts, vamos começar a discutir como migrar complexos de tecnologia com arquiteturas que descrevemos aqui para microsserviços.