O futuro de aplicações web com baixo custo
Tags: programming, architecture, devops, cloud
Published: 2021-10-25 23:10:47

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!

![alt text](https://i.ytimg.com/vi/-2Z0Y3Kk8nU/maxresdefault.jpg "image Title")

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

![alt text](https://files.nsctotal.com.br/s3fs-public/2019-08/MTX01_0.jpg?nk1pZS3h9LJZOqvkHvlwINcM1Jqe8TzQ "image Title")

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

![alt text](https://adrenaline.com.br/uploads/chamadas/amd-ryzen-5000-xt-revisao1.jpg "image Title")

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?

<img width="100%" style="width:100%" src="https://cdn.dicionariopopular.com/imagens/giphy-1.gif">

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.

![alt text](https://pbs.twimg.com/media/ECHIzpxW4AMrgo3.jpg "image Title")

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**.