9 características sobre microserviços por Martin Folwer · pedromendes

Nessa postagem vou descrever sobre as principais 9 características sobre os microsserviços segundo Martin Folwer esses 9 pontos são os que eu acredito serem os mais importantes e a minha interpretação sobre eles!, apliquei a técnica de feynman para facilitar a compreensão.

Componentização

Em arquitetura de microsserviços o que é componentização?

Componentização é a capacidade de isolar funcionalidades de um software a ponta que elas possam ser removíveis, melhoradas ou substituídas sem precisar alterar outras partes do software.

Our definition is that a component is a unit of software that is independently replaceable and upgradeable.

e isso não quer dizer que cada componente tenha que ser uma "api" separada ou um microsserviço completamente separado afinal isso seria muito custoso

Remote calls are more expensive than in-process calls, and thus remote APIs need to be coarser-grained, which is often more awkward to use. If you need to change the allocation of responsibilities between components, such movements of behavior are harder to do when you're crossing process boundaries.

feynman: em suma isso quer dizer que ao trabalhar com microsserviços é de suma importância que tudo seja plugável e desplugável, ou seja, você pode ter uma funcionalidade que assim que um usuário faça registro seja lhe enviado um e-mail boas-vindas, mas, ao mesmo tempo, essa funcionalidade possa ser removida, melhorada ou alterada sem que você tenha que alterar outros lugares do seu código

componentização

Capacidade de negócio

O que é capacidade de negócio?

Capacidade de negócio é a capacidade de uma empresa de criar soluções, e isso lembra muito a lei de conway:

Quando a organização projeta uma solução, ela inevitavelmente vai reproduzir as estruturas de comunicação vigentes dentro dela — para o bem e para o mal.
-- Melvin Conway, 1968

feynman: isso quer dizer que quando uma empresa for fabricar uma solução inevitavelmente ela vai seguir as suas estruturas internas, ou seja, se na empresa temos designers, desenvolvedores backend ou frontend, a empresa vai ser divida nas áreas de design, backend e frontend, ou seja, as soluções mais "antigas" tendem a ser desenvolvidas dessa maneira, nessa um, ou seja, existem diversos pequenos times que vão desenvolver um software focada em certa área do negócio

Produtos e não projetos

Como assim?

Um projeto é composto por três fases: início, meio e fim. Durante o projeto, uma equipe é formada para desenvolvê-lo, mas ao final do projeto, essa equipe é desmantelada. Isso pode levar a problemas futuros para a empresa, pois a equipe que desenvolveu o projeto não está mais disponível para cuidar dele. Uma solução para esse problema é trabalhar com microsserviços, que permitem que a equipe que construiu o serviço também o execute. Isso abre caminho para o desenvolvimento de desenvolvedores full cycle, que cuidam de todo o processo da aplicação, desde a concepção até o deploy. Ao tratar o software como um produto, a equipe que desenvolveu o produto pode cuidar dele e garantir que ele atenda às necessidades dos usuários.

Smart endpoints e Dumb Pipes

O que são smart endpoints e dumb pipes?

Em suma smart endpoints são os locais dentro da sua aplicação onde as regras de negócio serão executadas nos microsserviços independente de onde, como ou quando, podendo ser executadas numa função lambda, quando uma mensagem chegar, em um serviço ou até mesmo num nano-serviço, já dumb pipes são como a comunicação entre os endpoints será feita como os dados chegaram a esses endpoints, nesses dumb pipes não deve haver regra de negócio, dumb pipes podem ser uma fila do rabbitMQ, um tópico do Kafka, ou até mesmo uma requisição

smart endpoints and dumb pipes

Governança descentralizada

O que é governança descentralizada em arquitetura de microsserviços?

É a capacidade de num ambiente de microsserviços poder usar a tecnologia certa para cada problema, exemplo, um determinado problema deve ser resolvido usando golang por sua vasta performance, já outro problema requer C# por ser mais completo

not every problem is a nail and not every solution a hammer.

Descentralização do gerenciamento de dados

O que é isso?

Quando trabalhamos com um sistema monolítico, por exemplo, normalmente temos um único banco de dados, com nossas tabelas, dados, etc. quando quebramos esse monolítico em microsserviços para deixar essa solução autônoma, precisamos que os dados sejam segregados, sendo que temos um banco de dados em uso por vários desses microsserviços, e cada microsserviço tem sua própria equipe, quando uma equipe alterar uma tabela, todos esses microsserviços vão ter que se adaptar as essas alterações, e caso não se adaptem podemos ter vários erros.

Para solucionar esse problema basta que cada microsserviço tenha seu próprio gerenciamento de dados, mas nisso uma coisa que temos que dar foco é na duplicação de informação, não é porque você tem os dados duplicados, que você vai ter todos os dados duplicados, é claro que com isso teremos inconsistência eventual dos dados, às vezes não conseguimos garantir que todas as bases de dados estejam com os dados sincronizados às vezes teremos um delay de alguns segundos

Automação da infraestrutura

Para uma empresa estar realmente madura para sair dos famosos monólitos e passar a trabalhar com microsserviços, coisas que às vezes nem é necessário, afinal você sabia que a shopify é um grande monólito?, esse é um ponto que vou abordar em outro post, você precisa já ter pelo menos uma estrutura automatizada, você pode usar terraform, ansible, docker, argocd e muitas outras tecnologias, como esteira(s) de ci/cd, observabilidade, recuperação de desastres...

Desenhado para falhar

Querendo ou não sua aplicação em um momento, ou outro vai falhar, e ela tem que estar preparada para isso, ou seja, você tem que estar preparado para as coisas darem errado, vou te dar alguns exemplos, e se seu sistema de mensageria cair, e se você começar a receber muitas requisições, e se seu gateway de pagamentos cair, e se seu banco de dados estiver sobrecarregado?

Você tem que pensar nisso tudo e desenvolver sua solução pensando nisso, claro você pode usar alguns patterns para isso, ou até mesmo alguns métodos que eu vou citar em outros posts, como circuit breaker

Design evolutivo

Toda vez que você altera um sistema sem afetar outro sistema, significa que você tem um excelente controle sobre sua aplicação, você pode melhorar sua aplicação conforme você deseja assim evoluindo ela, muitas vezem também você pode querer usar um sistema ou serviço e depois jogar fora e isso não deve impactar o restante da sua aplicação

We've seen similar approaches at a financial institution where new services are added for a market opportunity and discarded after a few months or even weeks.

fontes