02 - Estudo de Microsserviços ingresso.x - Desafios
Tags: braziliandevs, monorepo, systemdesign, microservices
Published: 2023-08-14 15:53:22

### :unlock: Esse artigo é o segundo de uma sequência de estudo em andamento.

[![github](https://img.shields.io/badge/Repositório%20do%20estudo-github-181717?style=for-the-badge&logo=github&logoColor=white)](https://github.com/jtonynet/cine-ticket-study-microsservices) [![linkedin](https://img.shields.io/badge/Acesse%20o%20meu-linkedin-0A66C2?style=for-the-badge&logo=linkedin&logoColor=white)](https://www.linkedin.com/in/jos%C3%A9-r-99896a39/) [![twitter](https://img.shields.io/badge/Acesse%20o%20meu-twitter-1D9BF0?style=for-the-badge&logo=twitter&logoColor=white)](https://twitter.com/aromademirtilo) [![Instagram](https://img.shields.io/badge/Acesse%20o%20meu-Instagram-E4405F?style=for-the-badge&logo=instagram&logoColor=white)](https://www.instagram.com/learningenuity/) ![Badge Status](https://img.shields.io/badge/STATUS-EM_DESENVOLVIMENTO-green?style=for-the-badge)

---

> **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](https://www.significados.com.br/falacia/#:~:text=Fal%C3%A1cia%20significa%20erro%2C%20engano%20ou,de%20proposi%C3%A7%C3%B5es%20que%20s%C3%A3o%20falsas.)_

O texto abaixo é referente à branch [feature/initial-main-000](https://github.com/jtonynet/cine-ticket-study-microsservices/tree/feature/initial-main-000) do repositório de estudo.

---

## :elephant: 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](https://en.wikipedia.org/wiki/Fail-fast) deve ser permitido e incentivado. Mas ele, o elefante, continuava lá, se recusando a sair da sala.

**Estrangular** do **[Strangler Pattern](https://www.redhat.com/architect/pros-and-cons-strangler-architecture-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](https://www.amazon.com.br/Programador-Pragm%C3%A1tico-Aprendiz-Mestre-ebook/dp/B019HM0H90) segundo [Andy Hunt](https://en.wikipedia.org/wiki/Andy_Hunt_(author)), 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](https://medium.com/rd-shipit/descoberta-dos-dom%C3%ADnios-ddd-do-rd-station-marketing-atrav%C3%A9s-do-eventstorming-5c4743d5b7ea). No mundo ideal, ele foi feito antes. O artigo do link explica bem e continua na metáfora do elefante :D

---

## :speaking_head: 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](https://nighthacks.com/jag/res/Fallacies.html), 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.

---

## :arrows_counterclockwise: Trade-offs

Nem mesmo projetos de software novos, chamados de "[greenfield](https://en.wikipedia.org/wiki/Greenfield_project)", 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](https://en.wikipedia.org/wiki/Trade-off)** 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_](https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90), e nobres, leiam o artigo deles antes de dizerem: _"A Amazon voltou aos monólitos, RUN THE HILLS"_, por favor!

![Principal Engineer, lidando com Trade-offs](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w8oxckmke9v7apgzdw48.gif)
_Principal Engineer da Amazon, Bruce Wayne, lidando com Trade-offs (estavam no carnaval, por isso a fantasia de Batman :bat:, não, pera...)_

---

## :twisted_rightwards_arrows: Teorema de CAP

Entendidos os Trade-offs e cientes que não temos como escapar deles, chegamos ao **[Teorema de CAP](https://en.wikipedia.org/wiki/CAP_theorem)** um tripé onde devemos escolher dois de seus pilares para privilegiar, ou como gosto de chamar _"não se pode ter tudo"_.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n56rsaf6nttsxie87qz3.png)
_Imagem retirada do artigo wiki citado acima_

Um resumo desse tripé seria:

1. **C**onsistency (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?
2. **A**vailability (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é?
3. **P**artition 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_.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6c4olj762agdi09f3mn3.gif)

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](https://pt.wikipedia.org/wiki/Consist%C3%AAncia_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.

---

## :nerd\_face: 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!**

---

## :footprints: 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"](https://github.blog/2023-06-08-developer-experience-what-is-it-and-why-should-you-care/), começando a criar e padronizar nossos processos que levam a **estabilidade**, primeiro princípio da disponibilidade

Até breve.

---

| :point_left: Anterior | Próximo :point_right: |
|-----------------|----------------|
| [A Motivação](https://dev.to/learningenuity/01-estudo-de-microsservicos-ingressosx-motivacao-355j)|[Monorepo com Docker](https://dev.to/learningenuity/03-estudo-de-microsservicos-ingressox-monorepo-e-docker-1l7g) |