O último grande keynote do AWS re:Invent é o do Werner Vogels, CTO da Amazon. Por ser o líder de tecnologia do maior cliente da AWS, Vogels sempre traz uma visão de tecnologias e boas práticas mais focada no consumo dos produtos.
Enquanto nos seus primeiros keynotes eram feitos diversos anúncios mais focados em desenvolvedores, nos últimos anos ele tem focado mais em conceitos e boas práticas para construção de soluções na nuvem. Em 2024, focou tanto em conceitos e boas práticas que não trouxe lançamentos de serviços durante a sua apresentação. Isso pode frustrar algumas pessoas que esperam novos produtos, mas vejo de uma maneira diferente. Ainda é necessário ter esse foco nos conceitos fundamentais, pois muitas empresas ainda não constróem soluções eficientes na nuvem por não respeitar as boas práticas e acabam culpando a tecnologia.
O foco da apresentação deste ano foi o que Werner chamou de Simplexity, ou fazendo uma tradução direta, Simplexidade (Simplicidade + Complexidade):
“Sistemas complexos construídos sobre princípios simples”
Enquanto explorava esse conceito, ele trouxe reflexões que vemos muito no dia a dia dos nossos clientes, como o questionamento de quão grande deve ser um serviço antes dele ser divididoem partes, se deve ser feita a extensão de um serviço atual ou construção de um novo, e diferenciou a complexidade intencional da não intencional. Ele também deixou claro que complexidade não é diretamente relacionada ao número de componentes, fazendo uma excelente analogia com bicicletas: um monocíclo só tem uma roda, mas é complexo de andar, enquanto um tricíclo é bem mais estável, mas não faz curvas bem, e a bicicleta acaba sendo um meio termo ideal, com um certo nível de complexidade para equilíbrio, mas com melhor desempenho.
Durante sua apresentação, também entrou em detalhes sobre a complexidade por trás do Aurora DSQL, que não vamos cobrir neste artigo, e compartilhou 6 grandes lições sobre o desenvolvimento de soluções complexas sobre princípios simples que exploramos na sequência. Mas, antes de olhar cada lição, é importante lembrar: simplicidade exige disciplina.
Como também grande acadêmico, as apresentações do Werner sempre voltam para conceitos fundamentas da computação e nesse ano ele se baseou nas Leis de Lehman’s da Evolução de Software antes de trazer seus aprendizados.
Leis de Lehman's da Evolução de Software
Lei 1: Mudança Contínua: Sistemas devem ser adaptados de maneira contínua senão irão se tornar progressivamente menos satisfatórios
Lei 2: Crescimento Contínuo: O conteúdo funcional de um sistema deve ser aumentado de maneira contínua para manter a satisfação dos usuários durante o ciclo de vida do sistema
Lei 3: Aumento da Complexidade: Na medida que um sistema evolui, a complexidade aumenta, a não ser que seja feito um trabalho para manter ou reduzí-la
Lei 4: Queda de Qualidade: Um sistema será percebido como perdendo qualidade a não ser que seja rigorosamente mantido e adaptado para o seu ambiente operacional em constante mudança
Lições em Simplexidade
1. Tornar a capacidade de evoluir (evolvability) um requisito
Infelizmente, ainda vemos muitas empresas que acreditam que basta desenvolver uma solução que ela continuará eficiente para sempre. Ainda mais quando tratamos de nuvem, com diversos novos produtos sendo lançados todas as semanas, evoluir as aplicações é essencial. Werner Vogels deixou clara a diferença entre manter um sistema, que são pequenas mudanças de curto prazo, e evoluir, que é olhar para melhorias que trarão benefícios de longo prazo.
Nessa parte, ele traz o exemplo da própria AWS, que quando criou serviços criados, como o S3, tinha certeza que teriam mudanças de arquitetura pouco tempo depois do lançamento. E, um ótimo momento para revisitar as decisões de arquitetura é quando qualquer padrão de uso muito, como, por exemplo, o volume de utilização e quantidade de clientes atendidos. E, segundo Werner, para um sistema ser considerado Evolvable, ele precisa:
- Ser modelado a partir de conceitos de negócios
- Detalhes internos ocultos
- Interfaces bem segregadas
- Possuir endpoints inteligentes
- Descentralizado
- Deploy pode ser feito de forma indepentente
- Automatizado
- Princípios de design nativos da nuvem
- Falhas isoladas
- Alta observabilidade
- Múltiplos paradigmas
2. Quebrar a complexidade em partes
Quando falamos de complexidade de sistemas, é muito fácil ignorar os sinais de alerta e continuar desenvolvendo sem perceber o aumento da complexidade. Muitas vezes, é mais fácil aumentar um serviço em vez de construir um novo microsserviço. Nessa lição, é essencial sempre atuar quando perceber quando um microsserviço está ficando grande demais. E, na apresentação, a mensagem foi que um microsserviço está grande demais quando um engenheiro não consegue ter facilmente o modelo mental do microsserviço.
3. Alinhar a organização à arquitetura
Um momento interessante do keynote foi o Andy Warfield, que é VP e Distiguinshed Engineer na AWS, trazendo um pouco da sua experiência dentro da Amazon e também trazendo uma das lições. Em conversas durante o evento, começa-se a perguntar se já é um trabalho de sucessão sendo estruturado. Andy falou sobre alinhar a organização à arquitetura dos sistemas, através de squads (na Amazon, os two-pizza teams), que permitem que times menores tenham mais autonomia e responsabilidade nas decisões para os problemas específicos pelos quais são responsáveis por resolver.
4. Organização em Células
Muito se fala de microsserviços. Recentemente, Cell-Based Architecture, ou arquitetura baseado em células, tem sido uma expressão que vem ganhando força. Em um sistema que possui front-end, backend e banco de dados, por exemplo, uma célula é entendida como um agrupamento dessas partes para entregar uma parte da solução. O objetivo disso é reduzir o escopo de impacto em caso de falha em um dos componentes ou unidades. Com esse conceito, os clientes devem ser roteados para células diferentes. Então, se uma parte da sua infra tiver um problema, apenas um grupo menor de clientes será impactado.
5. Construir sistemas previsíveis
Nessa lição, Werner trouxe como podem ser feitas mudanças no design de sistemas e arquitetura para reduzir a incerteza em relação ao sucesso do funcionamento. Um exemplo que parece simples, mas extremamente eficiente é a de uma mudança de arquitetura de uma demanda que era orientada a evento mas não necessariamente precisava ser. Em vez de utilizar vários componentes, como um orquestrador de eventos, filas e funções, entenderam que era mais simples e mais eficiente de salvar um arquivo no S3 e a camada de dados fazer o pull dos dados. Como o S3 é altamente disponível e escalável, essa abordagem reduz a incerteza. Não necessariamente esse é o caminho que precisa ser seguido, mas o principal é repensar os sistemas com a mentalidade de redução das incertezas.
6. Automatizar a complexidade
Para fechar as lições, o CTO da Amazon começou com a pergunta de “O que automatizamos?” e sugeriu uma mudança de perspectiva para “O que não automatizamos?”. Em sua visão, a não ser que algo realmente precisa de uma atuação humana, a mentalidade deve ser de automatizar. Com essa mudança de pensamento, devemos pensar na automação como padrão, e ação humana como a exceção.
A e-Core é um parceiro AWS preparado para ajudar o seu negócio com soluções de migração e modernização do ambiente cloud, assim como na criação de soluções personalizadas com nossa expertise em computação em nuvem, big data, IA e Machine Learning.
Entre em contato conosco e veja como podemos apoiar o seu negócio!
