O futuro de aplicações web com baixo custo

Na maioria das vezes quando estamos construindo aplicações web, sempre pensamos primeiramente em linguagens de programação, frameworks, banco de dados, arquiteturas (Hexagonal, Onion, CQRS, …), se irá ser monolítico, microsserviços e etc.

E depois de todas essas decisões começamos a codificar e realizar os testes na máquina de desenvolvimento, até chegar o grande momento de fazer o deploy no cloud (AWS, Oracle Cloud, Google Cloud, Azure, …).

E aí já vem aquela pergunta: quanto de hardware nós iremos precisar para rodar essa aplicação?

Uma boa parte das pessoas não executam um teste de estresse, para tentar simular um volume de usuários utilizando o sistema para obter uma métrica e tentar dimensionar o tamanho do hardware necessário.

Então começamos a fazer chutes, como por exemplo: definir o hardware da máquina de desenvolvimento como uma configuração mínima para rodar o ambiente de produção.

E após as definições de hardware baseada em métricas ou chutes começamos a pensar sobre qual cloud utilizar. E aí já pensando logo de cara no case Netflix, pois minha aplicação é muito similar, precisamos da mesma escala e agilidade que eles utilizam e eles utilizam a AWS, uma das maiores plataformas de computação na nuvem do mundo.

Então, bora lá criar as máquinas e começar a fazer o deploy!

E agora chegamos em uma parte bem interessante da aplicação que foi construída: as faturas HAHAHAH. Mas a aplicação é “incrivelmente incrível”, todos os clientes felizes, kubernetes escalando a aplicação monstruosamente (hahahahah), monitoramento 100% (haahahahaha), sem dor de cabeça com o cloud.

E os custos do projeto estão começando a ficar fora do orçamento, sem margem para negociação, preço da aplicação fora de mercado ou até mesmo o caso em que a aplicação fica insustentável.

E começamos a pensar sobre o que foi feito, se realmente o código da aplicação foi bem implementado, se foi um erro a escolha das linguagens de programação, frameworks, banco de dados, etc.

Então começamos a revisar: verificar se não tem como reduzir o números de máquinas ou até mesmo refazer alguma parte do código para melhorar o desempenho para tentar diminuir os custos.

E em alguns casos até paramos de monitorar a aplicação por ACHAR que isso realmente vai reduzir os custos. Por que a aplicação que foi escrita está “incrivelmente incrível”, zero bug e uptime 100%.

E mesmo com essa decisão os problemas de custo ainda não foram resolvidos. E aí a pergunta volta para a mesa novamente: como podemos reduzir os custos dentro do cloud escolhido e sem alterar o código já existente da aplicação?

Para exemplificar o que foi relatado até agora, iremos usar as seguintes decisões:

Início de tudo

Stack escolhido foi (Java 17, Spring Boot, JPA e PostgreSQL) e a aplicação é um CRUD SIMPLES de cadastro de tutoriais (https://github.com/fourpixelit/simplecrud-java).

AWS (❤️❤️❤️), máquinas rodando no brasil para que os clientes tenham uma latência menor e não tenham problemas com as rotas de DNS estrangeiras.

A máquina escolhida é do tipo C5 de 2vCpu e 4GB de memória ram, que tem um custo mensal em torno de 101,33 dólares.
Os testes serão executados no Linux(Ubuntu 20.04), Docker versão 20.10.10, docker-compose versão 2.0.1 e para fazer um teste de estresse em nosso exemplo vamos utilizar o K6.

Vamos simular um ambiente onde iniciamos com 150 usuários e depois simulamos um pico de 300 e no final diminuímos para 50 usuários.

Nesse cenário os usuários irão cadastrar, editar, publicar e depois remover o tutorial.

Os resultados desse primeiro benchmark está aqui:

Processadores	Tempo de inicialização	Total de requisições	Requisições por segundos
Intel	5.725	401484	742.042908

Troca de INTEL por AMD

Migrando para uma máquina do tipo C5a com as mesma configuração só que com processadores AMD, que tem o custo mensal em torno de 91,84 dólares.

O custo tem uma diferença de aproximadamente 10%, mas como fica o desempenho ?

Processadores	Tempo de inicialização	Total de requisições	requisições por segundos
Intel	5.725	401484	742.042908
AMD	6.609	400260	739.773979

Após essa troca de INTEL para AMD, melhoramos o nosso custo mas, e agora? O que eu posso fazer para continuar reduzindo o custo? Reescrever toda a aplicação?

E as outras arquiteturas de processadores?

Existe algo no mundo diferente da arquitetura x86 (INTEL e AMD)?

Sim, existe a arquitetura ARM (https://en.wikipedia.org/wiki/ARM_architecture) e a AWS oferece os processadores desenvolvidos por ela mesmo.

Migrando para uma máquina do tipo C6g com as mesma configurações só que com processadores Graviton, com um custo mensal em torno de 82,20 dólares.

10% a menos do que AMD e 20% a menos que INTEL?

Como será o desempenho da aplicação utilizando isso?

Processadores	Tempo de inicialização	Total de requisições	requisições por segundos
Intel	5.725	401484	742.042908
AMD	6.609	400260	739.773979
AWS Graviton	5.292	402412	743.767445

Só existe na AWS?

Qual outro cloud que oferece processadores ARM?

Decidimos testar a Oracle Cloud, a máquina do tipo A1 com as mesmas configurações das que foram utilizadas na AWS Cloud, tem o custo mensal em torno de 20 dólares.

Então temos uma diferença de 80% para o Intel, 78% da AMD e 75% da AWS Graviton em custos? Como será o desempenho disso?

Processadores	Tempo de inicialização	Total de requisições	requisições por segundos
Intel	5.725	401484	742.042908
AMD	6.609	400260	739.773979
AWS Graviton	5.292	402412	743.767445
Oracle A1	5.747	386708	714.695072

Nos testes o uso de CPU ficou em alguns momentos em 100%, mas ainda conseguiu fazer 714 requisições por segundo. E se a gente adicionar mais 2 vCpu? Pode ser que se comparando hardware ficaria até injusto com os outros testes, mas olhando o custo mensal de cada hardware volta a ficar justo.

A máquina do tipo A1 com 4 vCpu e 4GB de memória o custo mensal seria em torno de 33 dólares. A diferença mudaria para 67% para o Intel, 64% da AMD e 59% da AWS Graviton em custo.

Processadores	Tempo de inicialização	Total de requisições	requisições por segundos
Intel	5.725	401484	742.042908
AMD	6.609	400260	739.773979
AWS Graviton	5.292	402412	743.767445
Oracle A1	5.747	386708	714.695072
Oracle A1 - 4 vCpu	4.91	403800	746.391315

O cenário pode até ser fictício para alguns, mas foi muito real na minha realidade dentro do mundo de empresas de tecnologia: que as decisões não são somente sobre a tecnologia utilizada no stack da aplicação, escala, monitoramento e etc. Não é só disso que uma aplicação vive! Além de resolver o problema que foi lhe dado, ela ainda precisa ser competitiva no mercado.

E nem tudo está relacionado ao stack escolhido ou em reescrever as aplicações do zero, hoje estamos rodando com stack (Java, Golang e NodeJS) a mais de 6 meses em processadores ARM e em aproximadamente 50 máquinas. E com tudo que foi apresentado aqui conseguimos nos tornar dentro da própria AWS 25% mais competitivo, mas quando olhamos para outro cloud, conseguimos subir esse número para 65% sem reescrever nenhuma linha de código da aplicação, apenas trocando a arquitetura de processadores das máquinas utilizadas.