Em 2006, a Amazon começou a oferecer a infraestrutura que executa suas próprias aplicações como um serviço. Naquela época a Amazon já tinha doze anos de experiência e já era o maior e-commerce do mundo. Somando-se aos webservices lançados quatro anos antes, essa oferta da Amazon revolucionou todo o ecossistema de desenvolvimento e hospedagem de aplicações e ajudou a moldar os conceitos e práticas de Cloud Computing.

Com alguns poucos cliques, qualquer um, de qualquer lugar do mundo, pode ter acesso a uma ampla gama de serviços de rede, infraestrutura, computação, armazenamento e tratamento de dados com o mesmo nível de serviço usado pela própria Amazon e outros gigantes da internet.

Nem tudo são flores

Mas, é claro, o objetivo da AWS é vender serviços. E o principal problema enfrentado por quem se depara com a oferta de serviços da AWS é um só: complexidade. Hoje, a AWS oferece 227 diferentes produtos. Muitos deles são redundantes. Por exemplo, existem agora 11 serviços diferentes de banco de dados, 17 serviços de computação e 14 serviços de rede e entrega de conteúdo.

E cada um desses 227 serviços tem dezenas de subprodutos e centenas de páginas de documentação.

Fizemos um script de busca nos sitemaps do site de documentação da AWS (docs.aws.amazon.com). O resultado: apenas em inglês há mais de 540.000 páginas de documentação. É claro que documentação é uma coisa boa, todos queremos usar serviços bem documentados. Mas essa quantidade de documentação não parece mostrar que talvez os serviços sejam complicados demais?

Por exemplo, o EC2, o serviço fundamental de computação em nuvem da Amazon, possui um painel de configuração com 18 diferentes seções, cada uma delas com suas próprias telas, formulários, parâmetros e configurações. Veja um exemplo. Essa é uma das centenas de telas do EC2, que por sua vez é um dos 227 produtos da AWS:

Talvez seja complicado de propósito

Pare para pensar: o maior fornecedor de infraestrutura do mundo tem recursos para investir em uma boa UX para seus produtos, não? Talvez a combinação de uma oferta massiva de produtos, cuja documentação é humanamente impossível de se conhecer por completo, com uma usabilidade no mínimo duvidosa seja algo vantajoso para a AWS.

Veja, não estou dizendo que você deveria abandonar os serviços da Amazon. Mas é preciso reconhecer que há um problema aqui para que você e sua equipe possam fazer uso inteligente de AWS ou de qualquer outro fornecedor de cloud. Então vamos olhar com mais cuidado para os problemas:

Vendor lock-in

A AWS não é sua amiga. É claro que eles vão oferecer soluções que são vantajosas para eles mesmos. Se sua equipe segue à risca as orientações e recomendações da AWS, inclusive o que eles chamam de boas práticas de desenvolvimento, você ficará preso. Por exemplo, se o código de sua aplicação é uma Lambda Edge que consome uma SQS e um DynamoDB e envia notificações via SNS, você está preso. Mover sua aplicação ou parte dela para outro fornecedor significa que sua equipe terá que reconstruí-la. Mesmo que os serviços da AWS sejam a opção perfeita para sua aplicação hoje, é sempre bom preservar suas opções, não?

Arquitetura cara e complexa

A AWS oferece treinamentos nesse tema e consultoria para clientes importantes. Estive algumas vezes como consultor de meus clientes em reuniões sobre esse assunto e posso afirmar: os consultores da Amazon vão te ajudar a desligar serviços que você não está usando e ajustar a escala e configurações dos que está usando. Mas não vão realmente ajudar sua empresa a desenhar a melhor arquitetura para você.

Quer um exemplo? Vou falar de uma das aplicações em que nós aqui na Visie temos bastante experiência: WordPress. O WordPress é uma aplicação web convencional, um monolito com um único banco de dados e três interfaces: um site, um painel de administração e um conjunto de APIs REST. A documentação do próprio WordPress cita como requisitos apenas:

• PHP 7.4 or greater;
• MySQL 5.7 or greater OR MariaDB 10.3 or greater;
• Nginx or Apache with mod_rewrite module;
• HTTPS support;

É claro que, quando estamos falando de hospedar WordPress para um site com volume massivo de acessos e alta disponibilidade, você vai precisar acrescentar alguma complexidade. Cache do front-end, redundância de aplicação e banco de dados, WAF e um storage externo para arquivos.

Bem, veja a arquitetura sugerida pela própria AWS para hospedar WordPress:

Camada sobre camada de redes e serviços, numa arquitetura super complexa. E que vantagens essa complexidade toda está trazendo?

Segurança? Analisamos ponto a ponto o OWASP Top Ten. A OWASP é a principal referência mundial em segurança de aplicações web. Seu top ten mostra as dez categorias de vulnerabilidade mais comuns e mais usadas em ataques. Se você quer ter uma aplicação web segura, o OWASP Top Ten é por onde você deveria começar. Pois bem, apenas uma das dez recomendações é endereçada pela arquitetura recomendada pela AWS.

Disponibilidade? Nós temos hospedado algumas instalações WordPress para grandes empresas, com dezenas de administradores de conteúdo e milhões de usuários há anos, com zero indisponibilidade de infraestrutura e usando uma arquitetura muito mais simples. Quanto mais complexa a arquitetura, mais componentes há para monitorar, gerenciar e manter. Mais coisa para quebrar.

Controle de custos super complexo

David Chamberlain, fundador da Viddyoze, acordou uma manhã com uma ligação da Amazon. Seu cartão de crédito havia sido recusado. A AWS estava tentando cobrar os custos do mês: US$ 65.345! Sua conta normalmente não passava de US$ 10.000. Ele havia cometido um erro de configuração em um dos serviços auto escaláveis de sua empresa e esse foi o resultado.

Como a história dele, há dezenas de outras publicadas. Veja este outro exemplo: Ruslan Gainutdinov, CTO da Valosan, havia seguido todas as recomendações da AWS para evitar cobranças indevidas, incluindo configurar um billing alert. Mesmo assim, um engano no código de suas funções Lambda fez com que a conta de sua startup, que normalmente era de US$ 200 por mês, fosse para US$ 4.600 em 24h.

Cada produto da AWS tem uma definição de preço diferente, com custos diferentes para cada um dos seus serviços.

Apagou uma instância EC2 e esqueceu de liberar o Elastic IP associado? Isso vai gerar custos.

Seu site sofreu um ataque DoS? Vai gerar custos. Potencialmente enormes.

Um dos produtos da AWS é o Billing Dashboard, onde você pode tentar entender os custos que estão sendo cobrados. É um painel de controle com 17 seções, cada uma delas com suas telas, formulários e relatórios. Você realmente acha que essa complexidade não é intencional?

Os custos ocultos da complexidade:

Jonathan Becher, CDO da SAP, afirmou em um artigo para a Forbes que a complexidade mata cerca de 10% do lucro das companhias, num estudo feito com as 200 maiores empresas do mundo. Em tecnologia o impacto da complexidade é especialmente significativo.

Ao escolher uma arquitetura complexa, você está prendendo seu time de desenvolvedores a suas escolhas iniciais. Escolher uma arquitetura que exige produtos proprietários vai obrigar seus desenvolvedores a depender de ferramentas e documentações complexas. Também vai exigir que seu código seja executado online, tornando muito mais complexo o trabalho de escrever testes automatizados ou fazer debugging do código. Não é raro que a complexidade da arquitetura aumente o esforço e custo de desenvolvimento de um software em mais de 50%.

Depois disso, vem o processo de publicação. Como consultor e fornecedor de desenvolvimento, perdi a conta de quantos processos acompanhei em que a configuração de ambiente e primeiro deploy da aplicação consumiram mais tempo e recursos que o próprio desenvolvimento.

Ainda por cima, geralmente são custos ocultos. Como nosso negócio é desenvolver software, nós mantemos um controle bastante detalhado do esforço e custo necessário para o desenvolvimento de cada projeto. Mas estou cansado de ver em meus clientes processos de publicação que levaram semanas sem nenhum tipo de tracking de quanto isso custou.

E publicar é apenas o primeiro passo na espiral descendente dos custos ocultos. É comum que as empresas olhem para um custo extra de desenvolvimento de 50% do total do projeto e achem bem razoável. “É o custo a se pagar para seguir as melhores práticas,” eles pensam. Apenas uma pequena fração do TCO está no desenvolvimento, os custos geralmente estão em manter e evoluir o software, e esses custos não devem ser ignorados ao tomar uma decisão de arquitetura. Uma arquitetura complexa vai impactar em custos em toda a vida útil de um software.

A complexidade torna seu ambiente menos confiável e menos seguro

Há um mínimo de complexidade que cada aplicação precisa para que uma arquitetura ofereça segurança e disponibilidade. Por exemplo, a maior parte das aplicações web vai precisar de um load balancer com firewall, database redundante, deploy via CI e monitoramento automático. Em cima disso, há um mínimo que sua aplicação pode especificamente precisar: SMTP, file storage, cache em memória, por exemplo, podem ser necessários dependendo das regras de negócio de cada projeto.

Dizem que Einstein disse: “Tudo deve ser feito tão simples quanto possível, mas não mais simples.” Tudo o que passa do mínimo necessário para que sua arquitetura ofereça a segurança e disponibilidade desejada não vai ajudar, antes, vai tornar a aplicação menos confiável e segura.

Se seu time está imerso num mar de networks, security groups e IAM roles só para que os componentes da sua aplicação possam falar um com o outro, você só está aumentando os riscos de alguém cometer algum erro.

As coisas vão dar errado.

Um dia alguém vai subir código para produção que rodou em todos os ambientes, passou pelos checks do CI e mesmo assim quebrou em produção. Por que? Porque essas coisas acontecem. Quanto mais complexa a infraestrutura, maior a quantidade de abstrações que os programadores precisam entender e ter na memória quando estão programando, maiores as chances de um problema acontecer.

E quando acontecer, quanto mais complexa a infraestrutura, mais tempo vai levar para identificar e resolver o problema, e mais gente vai estar envolvida. Quem nunca viu uma “war room” para resolver um problema em produção com diversos profissionais reunidos, sendo que cada um tem conhecimento e acesso a apenas uma parte do ecossistema?

O que fazer, então?

Mais uma vez: não estou sugerindo que sua empresa deveria abandonar a AWS. Seria melhor se vocês pudessem fazer uso mais racional e consciente dos recursos da AWS. Para isso, sugiro duas coisas:

Primeiramente, ter consciência do problema. Se seu time não sabe que as coisas podiam ser melhores, está condenado a cometer para sempre os mesmos erros. A consciência das dores da complexidade é o primeiro passo para desenvolver no seu time a capacidade de pensar a arquitetura ao invés de apenas repetir receitas de bolo.

Em segundo lugar, conhecimento. Especialmente, conhecimento dos fundamentos. Sua equipe técnica precisa conhecer Linux e redes. Não podemos mais ter técnicos configurando Route53, Cloudfront e Load Balancers sem um bom conhecimento de HTTP, SSL e DNS. Não faz sentido ter alguém decidindo as URLs de uma aplicação que não entende a estrutura de domínios e subdomínios.

Com consciência do problema e conhecimento dos fundamentos, seu time poderá construir as soluções adequadas para os cenários das suas aplicações. Com isso:

• Vocês vão fazer o uso mais eficiente dos recursos da AWS;
• Vocês não estarão presos à AWS;
• Sua infraestrutura será muito mais fácil de entender e manter;
• Essa simplicidade tornará muito mais fácil manter as coisas robustas e seguras;
• Seus times de desenvolvimento e infraestrutura serão levados a um outro nível.

Para isso, quero te fazer um convite. Passei os últimos vinte anos ensinando e trabalhando ao lado de técnicos. Nesse período, como consultor e fornecedor de software, sempre tive um excelente contato com gestores de tecnologia, desenvolvimento e infraestrutura. Mas recentemente percebi que para cumprir meu propósito de ensinar as pessoas a usar tecnologia para simplificar suas vidas, eu deveria começar a dialogar mais frequentemente com gestores.

Por isso, decidi passar os próximos meses produzindo conteúdo para gestores de TI. Serão textos, vídeos, webinários, tudo absolutamente sem custo. E meu convite para você é simplesmente que você assine nossa lista de e-mails, que é o canal por onde vamos entregar esse conteúdo.

Não custa nada e você pode cancelar sua inscrição no momento em que desejar. Claro, se você quiser se engajar no diálogo e responder os e-mails, compartilhando suas ideias e experiências, vou ficar muito, muito feliz. Mas não é um compromisso: estou pedindo apenas que você assine nossa lista para receber o conteúdo que estou produzindo.

Do que vamos falar?

Não se preocupe, não vamos encher sua caixa de entrada. Você vai receber no máximo um e-mail por semana com vídeos ou artigos como esse que você acabou de ler. Entre os próximos temas teremos:

• Panorama do mercado e dificuldades na contratação de profissionais de TI;
• Agilidade e cultura DevOps em grandes corporações;
• Promoção do conhecimento de fundamentos em grandes times de tecnologia;
• Riscos e oportunidades do uso de Open Source no mercado corporativo.

Quem sou eu?

Meu nome é Elcio Ferreira. Desenvolvo software web há 23 anos. Construo e mantenho infraestrutura baseada em Linux e Open Source há 18 anos. Em 2006, fundei a Visie, empresa que desenvolve software web e mantém infraestrutura para clientes como Banco Itaú, Brastemp, Consul, Endeavor, Aramis, Vero Internet, Premier Pet e dezenas de outros.

Já construí arquitetura de software on premise em bare metal, baseada em VPS, com diversas soluções de virtualização e em clouds da AWS, Google, Azure e Akamai. Já fiz software para bancos, governos, multinacionais, empresas de mídia, para milhares de transações por segundo e milhões de usuários.

Tudo isso lado a lado com os times de desenvolvimento, fazendo com que os times de dev e ops sejam um. Minha missão pessoal é ensinar as pessoas a usar a tecnologia para simplificar a vida.

---

16 de março de 2023