fbpx
Além das 3 camadas | Iniciando os trabalhos
Publicado em: quarta-feira, 22 de dez de 2021
Categorias: Arquitetura

Se um dia você se questionou sobre o que deveria estudar sobre projetos que vão além de uma Web App, uma API e um Banco de dados aqui vão minhas dicas.

Eu separei 3 tecnologias que são matadoras porque ajudam projetos de todos os tamanhos.

Dê uma olhada e me diga o que você achou!

Por que sair do básico?

Web App + Web Api + Banco de dados é a composição básica da maioria dos projetos.

Esse é um desenho que vai até algumas dezenas de usuários, talvez até centenas com muito sofrimento.

Daí pra frente a gente está falando de gastar rios de dinheiro com infraestrutura para sustentar essa arquitetura tão simples.

Se dinheiro não fosse escasso, ok.

Esse desenho teria seu espaço em qualquer tipo de projeto

Mas nos dias de hoje com hardware e talvez até cloud sendo paga em dólar, fazer o uso consciente da infra pode ser o diferencial entre o projeto ser sustentável ou não.

Na prática se as aplicações que consumimos (Uber, Facebook, Google, Instagram, e todos os maiores e-commerces) fossem baseados SOMENTE/APENAS nesses 3 componentes , eles simplesmente não existiriam. Alguns já não são rentáveis, outros seriam impossíveis de serem tangibilizados em produtos reais.

Onde está o erro?

Na verdade não há um erro, só um problema de expectativa. Esse desenho é simples, fácil, didático e intuitivo, no entanto não é um desenho eficiente se você tem cargas de trabalho um pouco maiores. Ele atende um certo tipo de aplicação com um perfil de carga de trabalho, por um certo tempo.

Mas se todo projeto é desenvolvido visando o sucesso, e em geral o sucesso se traduz em mais usuários e mais transações, portanto é natural pensar que todo projeto com esse esboço de arquitetura precisará ser revisitado para que alcance seu objetivo. Esse desenho é menos tolerante a escala e carga.

Não entendeu?

A história do Joãozinho, explica:

Vamos acompanhar a história hipotética de Joãozinho, que resolveu fazer um bico de entregar encomendas.

Com pouca demanda, Joãozinho usou seu carro popular para começar nesse Job e entregar alguns pedidos, com limitação de peso, tamanho etc.

Então a demanda foi crescendo, crescendo e Joãozinho percebeu que precisava voltar diversas vezes durante o dia ao seu centro de distribuição improvisado, sua própria casa.

O fato de precisar voltar em casa diversas vezes ao dia se traduz em um maior consumo de tempo e combustível, ou seja aumenta teu custo por entrega.

Nesse momento parecia óbvio que o caminho natural fosse usar outro tipo de veículo para o transporte de mercadorias, algo mais especializado desempenhar essa função. Talvez um furgão, como a figura abaixo.

Note que estamos falando de uma "arquitetura" mais especializada. Ainda não é um caminhão, mas definitivamente deixa de ser o carro de passeio.

Com nossos sistemas acontece EXATAMENTE o mesmo.

A cada salto em escala e carga, precisamos de arquiteturas diferentes.

A origem das recomendações

Há 20 anos atrás, quando comecei na Petrobras, a gente tinha uma arquitetura de referência e a maioria esmagadora dos projetos atendiam punhados de pessoas. Sim, milhões gastos na construção de softwares que atendiam no máximo dezenas de usuários. Mas ali, dinheiro era infinito. Os servidores Oracle eram cases mundiais então, trabalhar 100% online com uma utilização ruim de banco, não faria ninguém ter dor de cabeça.

Para não ser injusto, existiam sim os projetos que alcançavam toda a empresa, todos os funcionários e colaboradores (mais de 20 mil), mas esse tipo de projeto era feito de forma relativamente especial com outros cuidados. Definitivamente isso não era o mainstream ali.

Em 2005 quando venho para o Rio, começo a de fato ver a realidade. É como sair da Matrix!

Uma realidade muito mais cruel, com restrições financeiras. E na verdade o retrato era só o de sair de uma bolha com dinheiro infinito para algo cotidiano, com muito dinheiro investido, mas ainda assim de certa forma mais controlado.

De 2005 a 2008 eu percebi que em projetos de médio porte gastava muito tempo com otimização. Gastava relativamente muito tempo para algumas centenas a mais de usuários.

O que é muito pouco quando você pensa: E se eu tivesse um milhão de usuários?

Não precisa ser nenhum gênio para deduzir que para uma escala maior era necessário pensar de forma diferente. Havia algo que uma galera de alta performance e escala estava fazendo que eu não estava.

Então foi assim que comecei a me interessar ainda mais por furar a bolha e descobrir o que esses grandes projetos estavam fazendo e como eles alcançavam cargas de trabalho insanas.

Hoje isso parece commodity, qualquer projetinho de fundo de quintal tem demandas de milhares de usuários. Mas naquela época não era assim. E é por isso que faz toda a diferença popularizar o que está além do Web App + Banco de Dados.

O que há além?

Quando eu falo que Web App/Api + Banco é um desenho pobre estou dizendo que o seu cliente usa um APP ou Website e o fluxo sai da aplicação web, passa somente pela rede, chega ao seu backend que fará uma operação online. Sem um proxy reverso, sem um cache, sem um cdn, acessando banco sempre, pra tudo, a todo momento.

É sobre isso que vamos trabalhar nessa série!

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

2 Comentários

  1. Hernany Santos

    Luiz, já pensou em escrever um livro cara? Sinceramente um simples texto, mas uma leitura extremamente agradável e formativa.

    Responder
    • Luiz Carlos Faria

      Nos planos, não… mas cogito sim. A vantagem do blog é poder evoluir, mudar, crescer por demanda. Corrigir e deixar vivo, além de saber o que atrai mais vocês.

      Responder

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.