Microsserviços 

Que benefícios a arquitetura de microsserviços oferece e porque é a opção das maiores empresas?

Por que muito investimento está sendo empregado mundialmente no seu desenvolvimento?

Facilidade e rapidez no desenvolvimento, pois uma vez isolada uma unidade de domínio de negócios, essa unidade se transforma num microsserviço.

• Um código menor, 
• bem mais simples, 
• focado em si próprio, 
• desacoplado dos demais.

Além disso e melhor ainda, abre a possibilidade de crescerem equipes independentes, pois cada microsserviço é: 

• um componente separado, 
• com vida própria, 
• luz própria e 
• podendo ser agnóstico em relação aos seus pares.

O tamanho de um microsserviço é determinado pelo conceito de coesão: 

• o que mexe junto, fica junto!

Técnicas de desenvolvimento ágil de software, movendo sistemas para a nuvem, cultura DevOps, CI e CD e o uso de containers, tudo está sendo usado ao longo de microsserviços, para agilizar o desenvolvimento e a distribuição de aplicações.

Um grande código monolítico é difícil de entender e modificar. Como resultado o ritmo do desenvolvimento vai ficando lento e a qualidade do código declina com o passar do tempo. Cria-se uma espiral para baixo.

Deploy independente , apenas o microsserviço que sofreu refatoração ou mudança de domínio de negócio ou “hotfix”, avançam as etapas do “pipeline” ida e volta até o deploy; o restante permanece rodando. 

Respeitado o conceito de coesão: o que mexe junto, fica junto.

Essa característica irá facilitar que DEVS e OPS consigam , com muita agilidade, dedicar-se com mais foco as suas respectivas fases do pipeline, sem perder o aspecto cooperativo.

“Mixed stack” é o benefício que permite utilizarmos diferentes linguagens e banco de dados de acordo com a característica da funcionalidade de cada microsserviço, notadamente fazendo-se o melhor uso possível do “CAP Theorem”, no processamento distribuído, pois sabe-se que cada eixo do triângulo (CA, CP ou AP) pode ter bancos mais adequados ao seu propósito.

“Fault Isolation”, significa que as falhas irão quebrar apenas o microsserviço onde ocorrer, o restante do sistema permanece rodando; obviamente o “hot fix” ou “bug fix”, se aplicam independente, facilitando também os “roll backs” e “roll outs”.

Os testes unitários , integrados, doravante automatizados, como toda a pirâmide de Fawller e as “features flags” , “canarys” e mesmo os testes elementares, ficam mais simples e rápidos, pois tarefas repetitivas são entediantes para os humanos; máquinas fazem isso bem melhor!

• A natureza do negócio requer escalabilidade, 
• alocação e desalocação de recursos, 
• processamento e banco de dados distribuído, 
• crescimento rápido e 
• capacidade de monitoramento.
• Aderência plena a todos os “cloud services” disponíveis atualmente, 
• “Multicloud”, SAAS, etc...

Em termos de arquitetura Sicred, a nossa solução é hibrida e assim será por um tempo, pois estamos gradualmente trocando o monólito para microsserviços.

Essa é a estratégia recomendada pelos principais evangelistas dessa arquitetura, uma vez que constam várias experiências negativas de construções "from scratch".

Com isso estamos obtendo mais rapidez no desenvolvimento, tendo em vista um código menor, mais simples, desacoplado dos demais e agnóstico em relação ao seu meio, numa equipe independente e com a condição de aplicar o fluxo da "pipeline" de CI e CD, com mais facilidade, absorvendo plenamente a cultura DevOps, em escalabilidade e observabilidade.

"Mixed stack" é a possibilidade que se abre para que possamos desenvolver cada microsserviço na tecnologia - linguagem, banco, etc…- que seja mais conveniente aquela função específica.

Como efeito colateral, o processo de "deploy" fica independente, da mesma forma que o "fault isolation", pois focaliza o episódio apenas no microsserviço em questão, não provocando impactos maiores no entorno da produção.