🔓 Esse artigo é o primeiro de uma sequência de estudo em andamento.
Microsserviço
Pequena aplicação, executa uma única tarefa e o faz com eficiência.Fonte: Livro Microsserviços Prontos para Produção
O texto abaixo é referente à branch feature/initial-main-000 do repositório de estudo.
📚 Motivação:
A pandemia foi gatilho para muitas pessoas. Com incertezas enormes, alguns tiveram sérios problemas e outros aproveitaram a oportunidade entre cursos e leituras. Podendo ocorrer picos e vales de ambos os espectros na mesma pessoa. É importante não julgar ninguém por suas fases mais complicadas!
Nesse contexto, quis superar a minha “sina dos 30% de leitura". A cada 10 livros, lia 3 deles até o final (geralmente arquitetura) ou chegava até um terço de outros (ainda assim melhor que Valve com trilogias, cadê o Half Life 3?)
Não sinto "culpa" por essa "sina" pois livros com foco em ferramentas tendem a ficar obsoletos rapidamente e documentação, cursos e palestras são boas alternativas que suprem o estudo constante. Mas gosto do hábito da leitura com fichamentos, marcações e mapas mentais.
Organizando a estante entre livros novos e antigos, destacou-se o já aniversariante na prateleira Microsserviços Prontos Para Produção de Susan Fowler (sem parentesco com outro Fowler famoso, o Martin Fowler) Peguei o bendito, “curto” e focado em disponibilidade. Alguns dirão que Sam Newman seria a melhor escolha. Mas fui na da ex-SRE do Uber por alguns motivos pessoais.
Charge do linhadotrem, mas poderia muito bem ser minha estante
A leitura de um tema já conhecido dos meus últimos anos de trabalho, foi ao encontro de um vídeo sobre a escalabilidade de determinado site de ingressos que um amigo sugeriu assistir. O mapa mental que fiz do livro se encaixou com minha experiência junto a esse vídeo.
Pronto, deu vontade de fazer a minha implementação, de maneira educacional, do projeto sugerido pelo vídeo.
Em arquitetura de Software Monolith First sempre! Uma aplicação única e gigantesca que valida seu negócio.
"Para algo que não se sabe ao certo como vai escalar, iniciar na técnica de monólitos seria o mais adequado" - Renato Viço
Diz o mais precavido e ele geralmente está certo! Mas problemas específicos como alta disponibilidade, requerem soluções específicas. “Não existem balas de prata” ou o já famoso "depende!"
🏃 Falando sobre Disponibilidade:
'Microsserviços parecem uma solução mágica (e um tanto óbvia), mas sabemos que não é bem assim. Em The Mythical Man-Month (O Mítico Homem-mês), Frederick Brooks explicou por que não existem balas de prata na engenharia de software, uma ideia que ele resumiu da seguinte forma: "Não há um único desenvolvimento, em tecnologia ou técnicas de gerenciamento, que sozinho prometa até mesmo uma melhoria de uma ordem de grandeza dentro de uma década em termos de produtividade, confiabilidade e simplicidade."’
Citação do livro Microsserviços Prontos Para Produção citando outro livro relevante.
Estudar é construção de conhecimento ou uma constante "Inception".
Pelo tamanho do desafio, “um site nacional que atenda a demanda da compra de entradas para lançamentos de filmes Blockbusters simultâneos” o que seria equivalente a uma varejista escalar em uma BlackFriday, faz sentido o uso de serviços distribuídos de catálogo, autorização, reservas, pagamentos e orquestração e cada um deles possuírem seus próprios níveis de disponibilidade
Disponibilidade é uma meta, medida na "regra dos 9" ou quantas casas com o numero 9 relativo ao percentual de tempo sua solução atende? Ou disponibilidade = uptime/(uptime+downtime), onde uptime é o tempo que sua aplicação respondeu adequadamente aos requests o inverso de downtime, quando existe falha.
Downtime permitido:
-
Disponibilidade 99% (dois noves):
- 3,65 dias/ano
- 7,20 horas/mês
- 1,68 horas/semana
- 14,4 minutos/dia
-
Disponibilidade 99,9% (três noves):
- 8,76 horas/ano
- 43,8 minutos/mês
- 10,1 minutos/semana
- 1,44 minuto/dia
-
Disponibilidade 99,99% (quatro noves):
- 52,56 minutos/ano
- 4,38 minutos/mês
- 1,01 minuto/semana
- 8,66 segundos/dia
-
Disponibilidade 99,999% (cinco noves):
- 5,26 minutos/ano
- 25,9 segundos/mês
- 6,05 segundos/semana
- 864,3 milissegundos/dia
Partindo de um modelo mais "simples", síncrono e bloqueante; devo ir implementando soluções mais elaborados de System Design aos poucos. O objetivo é estudar e compartilhar, tendo disponibilidade como foco, podendo passar por assíncrona e não bloqueante até chegar em uma solução Orientada a Eventos.
Princípios de disponibilidade:
Para alcançar essa meta temos alguns princípios, os que irei adotar por hora são esses: Estabilidade, Confiabilidade, Escalabilidade, Desempenho e Documentação
Então rascunhei o projeto tendo esses princípios em mente e devo ir avançando com ‘baby steps’ indicando nos futuros artigos o que implementei para cada princípio.
Todos demandam um investimento de estudo nesse momento e pretendo ir a favor do desenvolvimento iterativo e incremental. Iniciando por um monorepo e ir escalando. Os princípios que dependem única exclusivamente do desenvolvedor sendo implantados de forma “simples” e ir adicionando complexidade aos poucos.
Diagrama:
Já o Princípio de "Monitoramento", no momento foi excluido por depender de trabalho conjunto a DevOps e embora pretenda implantar um minimo, não é meu objetivo me aprofundar nisso por hora. Em cenário real seria imprescindível, mas pretendo ter um MVP (Produto Viável Mínimo) sem as soluções de infra para Monitoramento por enquanto.
🤓 Conclusão (por hora)
Vimos o que gerou a criação deste estudo. Pandemia como um catalisador, incentivando leitura técnica e como ela me levou a observar outras abordagens a problemas que já vivenciei e estudei em outras mídias como: cursos, videos e palestras.
A sugestão de um vídeo de influenciador que deu origem a esse estudo de implementação sob a luz dos meus conhecimentos prévios e recém adquiridos em áreas de constante evolução
Vimos também, disponibilidade como métrica para o sucesso de soluções de internet e quais dos seus princípios pretendo aplicar no meu repositório de estudos
Essa é minha Motivação!
👣 Próximos passos
Próximos artigos "mais técnicos" virão. Compartilhar esse experimento no espírito de aprender em público, fixando conteúdo e documentando informalmente o processo. Quando ensinamos também aprendemos.
Fujam de suas "sinas de 30%" ou seja lá qual for a crença limitante que possa estar te impedindo de evoluir.
Até breve.
| 👈 Anterior | Próximo 👉 |
|---|---|
| Alguns Desafios |
Top comments (0)