Série Evolutionary architectures, parte 3

“Para a lua 🚀”

“Evolutionary Architectures” é uma série do blog em quatro partes que mostra como os projetos e as decisões das soluções evoluem à medida que as empresas passam pelos diferentes estágios do ciclo de vida das startups. Nessa série, seguimos a apropriadamente denominada “Example Startup”, cuja ideia é criar uma aplicação para o “mercado de ações fantasia”, semelhante às ligas de esportes fantasia. Eles preveem realizar quatro “torneios” durante um ano.

O segundo blog descreveu como a startup começou a desenvolver suas soluções técnicas enquanto os fundadores se preparavam para a arrecadação de fundos. Na parte 3, veremos como a Example Startup progride ainda mais no amadurecimento de sua tecnologia e no bom posicionamento de sua escala.

Dimensionamento eficiente por meio da transição para uma arquitetura de microsserviços

A equipe de negociação de ações de fantasia está crescendo e novos componentes e soluções estão sendo construídos. À medida que o portfólio técnico se expande, certas rachaduras começam a aparecer e exigiram a atenção da equipe.

“Os velhos hábitos são difíceis de morrer”, e a equipe começa a ver como isso pode causar problemas para o crescimento de sua startup: os prazos agressivos e o entusiasmo de fazer mais com menos estão levando ao aumento do déficit técnico. Um aspecto desse déficit técnico é a proliferação gradual de monólitos, em oposição à arquitetura de microsserviços que a equipe havia escolhido inicialmente. As preocupações com o monólito, como escalabilidade e gargalos de performance, começam a aparecer durante os testes e a introdução de novos recursos. Felizmente, a equipe reconhece rapidamente os desafios que essa abordagem monolítica representa para a escalabilidade ideal das workloads. Ela decide dar um passo atrás e reavaliar suas práticas de desenvolvimento. Um dos desenvolvedores lembra que o arquiteto de soluções (SA) da AWS previu alguns desses problemas em uma conversa anterior. A equipe da Example Startup agenda uma ligação com a AWS para obter ajuda.

A decomposição de monólitos e a transição para um paradigma baseado em microsserviços é um tópico amplo, então a AWS SA recomenda um Dia de Imersão na Modernização de Aplicações para a equipe da Example Startup. O dia de imersão usa um workshop relacionado como pano de fundo, com foco em workloads relevantes para startups. O evento conta com a participação de quase todos os desenvolvedores da empresa e acaba sendo um divisor de águas. Ao longo de um único dia, a equipe pode aprender a definir, projetar e implementar microsserviços adequadamente. Ela também aprende a traçar um caminho de migração gradual de uma aplicação monolítica para um conjunto de microsserviços sem precisar refazer tudo de uma vez. A equipe fica feliz em detectar seus erros logo no início e aprender algumas das práticas recomendadas que a ajudará a seguir em frente. O arquiteto de soluções também compartilha um whitepaper da AWS focado em estratégias de modernização que podem preencher qualquer lacuna de conhecimento na equipe da Example Startup.

A experiência com a modernização de aplicações agrega tanto valor à Example Startup que a equipe decide aplicar a mesma abordagem de aproveitar as práticas recomendadas existentes para diferentes áreas funcionais no futuro. Os engenheiros e o gerente de produto agendam uma ligação para compartilhar seu roteiro para o restante do ano com a AWS, em um esforço para evitar trabalhos duplicados. A Example Startup já assinou um acordo de confidencialidade mútua (MNDA) com a AWS e houve um fluxo livre e produtivo de ideias de ambos os lados durante essa conversa, além de uma ótima notícia: acontece que um recurso que a Example Startup estava pensando em criar sozinha já está no roteiro da AWS para o próximo trimestre, e isso libera uma parte do tempo de engenharia para a equipe.

O próximo tópico da lista de áreas a serem aprimoradas da Example Startup está relacionado à infraestrutura como código (IaC), integração e entrega contínuas (CI/CD) e testes automatizados. Dois funcionários recém-contratados de operações de desenvolvedores (DevOps) não estão satisfeitos com muitos dos mecanismos operacionais atuais da startup, especialmente coisas como criar e testar ambientes, bem como gerenciar artefatos de código. Uma equipe em crescimento na Example Startup significa que mais pessoas têm acesso a esses processos confidenciais, introduzindo riscos desnecessários. Os dois novos membros da equipe já têm alguma experiência com o Terraform como abordagem à IaC. Eles estão felizes em saber que a AWS é bem recebida pelo Terraform e em descobrir outras ferramentas, como o AWS CloudFormation e o AWS CDK, caso seja necessária uma alternativa. No entanto, eles ainda precisam de ajuda com a configuração de CI/CD. Até agora, suas tentativas carecem de coesão e é difícil fazer com que sua ferramenta de construção funcione bem a de implantação. Além disso, eles ainda estão procurando uma abordagem adequada para gerenciar imagens de contêiner. A equipe da AWS recomenda avaliar o AWS CodePipeline porque ele atende às necessidades de integrar perfeitamente uma ferramenta de criação e de implantação e também inclui testes automatizados, todos combinados com suporte para vários ambientes. O uso do CodePipeline permite a integração com soluções que não foram necessariamente criadas de forma nativa na AWS, bem como suporte robusto para outras ferramentas, como AWS CodeBuild, AWS CodeDeploy e ferramentas de terceiros. A implementação do CodePipeline permite que a Example Startup risque outro grande item de sua lista.

Com a equipe no caminho certo para uma implementação adequada de microsserviços, eles se sentem capacitados para trabalhar em alguns dos outros desafios complexos que permanecem pendentes. Por um lado, a presença de vários serviços operando de forma independente naturalmente levanta a questão da comunicação entre esses serviços. Há uma grande dúvida sobre se cada chamada entre serviços deve ser síncrona ou assíncrona na comunicação, além de como a equipe pode começar a adotar padrões de práticas recomendadas, como mensagens de publicação/assinatura (PubSub). A equipe entende amplamente que a adoção de uma arquitetura orientada por eventos seria benéfica, especialmente com a eliminação dos monólitos, mas está um pouco sobrecarregada com a infinita variedade de serviços da AWS relacionados a essa arquitetura, incluindo, entre outros, Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (Amazon SNS) e Amazon Managed Streaming for Apache Kafka (Amazon MSK). Desta vez, a equipe é capaz de encontrar alguns recursos como um ótimo ponto de partida, como alguns workshops e blogs muito úteis sobre o assunto. O paradigma “orientado por eventos” está lentamente se tornando outra ferramenta na caixa de ferramentas da equipe.

Desenvolvendo uma estratégia de segurança mais forte

A segurança continua sendo a prioridade de nossa startup e ferramentas como o AWS Startup Security Baseline (AWS SSB) os ajudam a começar. Infelizmente, você nunca pode ter muita segurança. A implementação inicial do AWS WAF foi um bom começo, mas a equipe precisa começar a pensar de forma mais proativa sobre prevenção, detecção e remediação. Eles começam a se aprimorar nos diversos serviços da AWS focados em segurança que podem ajudá-los a implementar uma estratégia de segurança sólida.

A equipe em crescimento e o envolvimento dos parceiros fazem do controle de acesso, as permissões e a governança outros tópicos que exigem um foco cada vez maior. A equipe está tentando implementar as práticas recomendadas, como o princípio do privilégio mínimo ao aplicar permissões. No mínimo, ela quer transferir as workloads de produção para suas próprias contas separadas. À medida que a equipe adota essas práticas recomendadas, ela vê o aumento da complexidade operacional devido às camadas adicionais de gerenciamento e permissões com as quais precisa lidar agora. Torna-se rapidamente óbvio que ela precisa de uma abordagem mecanizada para a estrutura da conta. Alguém menciona o AWS Organizations, o que parece ser um passo na direção certa, então ela entra em contato com seu SA confiável da AWS para um bate-papo. O SA compartilha alguns conselhos relevantes, como considerar o AWS Control Tower como uma abordagem mais fácil para gerenciar várias contas e o AWS Organizations. Como essa é a primeira de muitas etapas para alcançar uma estratégia robusta de várias contas, o SA da AWS também compartilhou com a equipe a orientação prescritiva “Fazer a transição para várias contas da AWS”. Este guia inclui as práticas recomendadas sobre migração de contas, gerenciamento de usuários, rede, segurança e arquitetura ao migrar para uma configuração de várias contas.

Otimização de workloads para performance

A equipe está abordando algumas peças fundamentais para que a startup esteja bem posicionada para crescer no ritmo certo. Alguns itens principais são riscados da lista e outros têm planos de ação em vigor. Os desenvolvedores estão fazendo o máximo que podem para otimizar suas workloads em termos de performance, mas identificaram algumas oportunidades de melhorias adicionais que vão além do código, como armazenamento em cache de borda com o Amazon CloudFront, armazenamento em cache em nível de aplicação com o Amazon ElastiCache e armazenamento em cache de banco de dados. A equipe está cada vez mais confiante nos serviços gerenciados pela AWS para oferecer a funcionalidade de que precisam e, ao mesmo tempo, manter a complexidade operacional associada no mínimo. Outro serviço gerenciado que alguns desenvolvedores descobrem e acham surpreendentemente fácil de usar é o AWS Batch. A abordagem inicial de processamento de feeds com o AWS Lambda está começando a atingir seus limites devido ao aumento exponencial no volume de dados que precisam ser processados. Após algumas experiências, os desenvolvedores conseguem traçar um caminho para usar o AWS Batch que permite continuar crescendo com relativamente pouco aumento na carga operacional e ainda manter os custos baixos.

Provar a proposta de valor de sua startup

Todo esse bom trabalho na Example Startup não passa despercebido. Construir de forma ágil e sustentável, sem depender de soluções alternativas de curto prazo, mostra que a empresa está pensando no longo prazo, demonstra maturidade e tem a capacidade de entregar. Essas características, juntamente com uma solução inovadora e uma boa adequação ao mercado de produtos, estão no centro da proposta de valor da empresa. Os fundadores transmitem com sucesso o valor de sua empresa a duas empresas de capital de risco diferentes e fecham sua primeira rodada de financiamento da Série A. A Example Startup está a caminho da lua.

Confira o primeiro blog e o segundo blog da série Evolutionary Architectures.