🔓 Esse artigo é o segundo de uma sequência de estudo em andamento.
Falácias
A palavra tem origem no termo em latim “fallacia”, aquilo que engana ou ilude. Desta forma, falácia será algo enganoso. As falácias são construídas por raciocínios aparentemente corretos que levam à falsas conclusões.Fonte: Site Significados.com.br
O texto abaixo é referente à branch feature/initial-main-000 do repositório de estudo.
🐘 na sala (Falácias, Trade-offs e CAP)
Antes de começarmos, é importante observar o elefante na sala e aprender a conviver com ele. Tive a experiência de trabalhar com monólito, aplicação única e gigantesca, e ajudei "lapida-los" em serviços menores, mas isso não se deu por "mágica". Algumas coisas pareciam corretas mas nos levaram à falsas conclusões e erros foram cometidos. Desejamos ser um pouco mais eficientes do que "tentativa e erro" pura e simples, precisamos "falhar rápido" e acertar nossos equívocos. Fail fast deve ser permitido e incentivado. Mas ele, o elefante, continuava lá, se recusando a sair da sala.
Estrangular do Strangler Pattern, é como nos referimos ao processo de trocar responsabilidades de um monólito em serviços menores. Eu preferia que o termo fosse lapidar por ser mais respeitoso ao que viabilizou o negócio, mas o mercado usa tecnicamente o termo "estrangular". Um Programador Pragmático segundo Andy Hunt, entende que:
'Um bom software hoje geralmente é preferível a um software perfeito amanhã. Se você der a seus usuários algo com que brincar desde o início, o feedback deles geralmente o levará a uma solução final melhor.'
Não é objetivo desse estudo definir por onde começar esse estrangulamento ou seus microsserviços, mas é importante que o leitor saiba ou relembre o conceito de descoberta dos domínios. No mundo ideal, ele foi feito antes. O artigo do link explica bem e continua na metáfora do elefante :D
🗣️ Falácias
Aplicações passam por evoluções, monólitos para escalar com disponibilidade, após comprovado modelo de negócio, podem ser "tunados" (um pente fino com otimizações na própria codebase, banco e infra), porém não raro são "estranguladas" a partir de feedbacks como: site lento, quedas, área "x" inacessível, etc...
Aprendi na dor as Falácias de Microsserviços, dentre as quais "a largura de banda não é infinita, rastreabilidade é difícil e existem custos!" podem causar mais danos. A medida que a solução distribuída for sendo construída apontarei quais foram as dores que já tive no processo.
Temos que ter cuidado com as soluções dos pontos de feedback, distribuir responsabilidades também é distribuir desafios e você pode estar substituindo um problema por vários outros. É necessária análise de opções para não se transformar no que pejorativamente é chamado de "monólito distribuído", ou seja um parque de microsserviços mal implementados e/ou com domínios mal planejados. Aqueles que não levaram em conta as Falácias e com Trade-offs inadequados. Causam mais dor ao negócio do que o monólito que visavam substituir.
🔄 Trade-offs
Nem mesmo projetos de software novos, chamados de "greenfield", estão livres de decisões que tragam benefícios por um lado, mas dificultam a implantação futura de certos recursos por outro. Chamamos isso de Trade-offs ou compensações. Se nem novos projetos escapam de tradeOffs, imaginem os que já estão rodando, os estrangulados.
Caches garantem que sua aplicação não caia mas por outro lado aumentam o tempo que atualizações cheguem aos seus clientes. Um banco NoSql é ótimo para documentos mas podem não garantir a consistência apresentada por um relacional. Isso são compensações
Mesmo a Amazon propagadora de microsserviços, "sofreu" com seus Trade-offs, e nobres, leiam o artigo deles antes de dizerem: "A Amazon voltou aos monólitos, RUN THE HILLS", por favor!
Principal Engineer da Amazon, Bruce Wayne, lidando com Trade-offs (estavam no carnaval, por isso a fantasia de Batman 🦇, não, pera...)
🔀 Teorema de CAP
Entendidos os Trade-offs e cientes que não temos como escapar deles, chegamos ao Teorema de CAP um tripé onde devemos escolher dois de seus pilares para privilegiar, ou como gosto de chamar "não se pode ter tudo".
Imagem retirada do artigo wiki citado acima
Um resumo desse tripé seria:
-
Consistency (Consistência)
- Privilegia que os dados entre os microsserviços sejam sempre os mais atualizados, pense no nosso estudo de caso que o filme "X" foi cadastrado adequadamente. Quanto tempo para ser exibido no website? Quanto tempo para ser exibido no aplicativo mobile, ele existindo? Comprei o ingresso de um assento, quanto tempo para aquela cadeira não estar mais disponível para outro usuário?
-
Availability (Disponibilidade)
- Caso tenha lido o primeiro artigo, já sabe que a seguinte pergunta deve ser respondida na "regra dos nove". Por quantas horas percentuais durante um ano meu site e/ou aplicativo mobile estiveram de pé?
-
Partition Tolerance (Tolerância a Partição de Rede)
- Seus microsserviços toleram que um nó, instância, deles caia? O sistema como um todo vai continuar respondendo a queda de um ou mais nós?
Em minha experiência centrada em negócios que ofertam produtos ou serviços, dentre o tripé do "CAP" sempre tendíamos por uma alta "regra dos nove" ou seja Availability e caso um nó de serviço caia, que isso não afete a aplicação e prontamente outro o substitua para que não exista impacto nas vendas ou seja Partition Tolerance.
Como cada escolha é uma renúncia, percebam que esse foco em vendas deixa descoberta a característica de ter sempre o dado mais atualizado em todos os pontos de nosso sistema ou seja a Consistency. Agimos na intersecção "AP" do diagrama. Essa abordagem encontra como maior trade-Off a Consistência eventual OU Consistência posterior como também pode ser chamada.
No nosso caso pode ocorrer de em um delta de tempo, vendermos o mesmo ingresso duas vezes e a ultima compra deve ser cancelada Ou vender um ingresso para um filme que tiramos de exibição. Isso pode acontecer e devemos trabalhar para mitigar.
🤓 Conclusão (por hora)
Vimos que há um elefante na sala, e ele sempre existirá. Coisas que podemos tomar por certas, podem nos enganar no contexto de serviços distribuídos. Também vimos "Compensações ou Trade-offs" que valem para toda a extensão de desenvolvimento de software e não apenas aos microsserviços e o "teorema de CAP".
Não somos capazes de atender "Consistência, Disponibilidade e Tolerância a Partição de Rede" ao mesmo tempo e em minha experiência as duas ultimas são as atendidas a favor de venda/prestação de serviço constantes (alta disponibilidade, regra dos nove e Tolerância), causando a chamada "Consistência eventual OU Consistência posterior" que pode ser mitigada mas não suprimida
Esses são nossos Desafios!
👣 Próximos passos
Em próximos artigos vamos dar inicio ao projeto técnico.
Temos a teoria, sabemos que existem desafios mas a disponibilidade deve ser garantida.
Vamos trabalhar em favor de uma "dev experience" ou "DevEx", começando a criar e padronizar nossos processos que levam a estabilidade, primeiro princípio da disponibilidade
Até breve.
| 👈 Anterior | Próximo 👉 |
|---|---|
| A Motivação | Monorepo com Docker |
Top comments (0)