Série Evolutionary architectures, parte 4

“Você gostaria de café com isso?”

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

A terceira postagem do blog descreveu como a startup começou a transformar sua arquitetura em uma que incluía ferramentas como pipelines de CI/CD e infraestrutura como código, além de implementar as práticas recomendadas, especialmente em relação à segurança e autorização. Na parte 4, veremos a Example Startup formalizando sua postura de segurança e backup para atender a vários padrões de conformidade. Eles também definem uma estratégia de dados para a organização e exploram outras linhas de negócios para diversificar seu portfólio de produtos.

Usar o financiamento da Série B para contratar, expandir e escalar

As coisas estão indo tão bem quanto possível para a Example Startup. Recentemente, ela fechou uma rodada de financiamento da Série B e espera impulsionar as tão necessárias contratações, expansões e escalabilidade. Com o financiamento e a adoção de clientes, também aumentou a concorrência. Participantes bem estabelecidos no mercado estão começando a vê-los como concorrentes sérios e aumentando seus esforços de marketing.

A Example Startup começa a contratar para expandir áreas funcionais e criar equipes dedicadas para engenharia de confiabilidade de sites (SRE), plataforma, análise e ciência de dados. Com o mercado de trabalho competitivo e a falta de um departamento de recursos humanos dedicado na startup, eles mais uma vez entram em contato com a equipe de contas da AWS para perguntar sobre como encontrar talentos técnicos que sejam proficientes na AWS. Acontece que a equipe de contas já ajudou outros clientes iniciantes em situações semelhantes, sugerindo parceiros da AWS que podem ajudar com suas necessidades de contratação. Em breve, a startup receberá e-mails de vários candidatos aprovados com experiência em AWS em sua caixa de entrada. Felizmente, muitas das entrevistas se transformam em ofertas de emprego e a Startup consegue marcar as contratações de sua lista de tarefas.

A onda de contratações leva a um problema técnico: as equipes estão reclamando que a equipe da plataforma da Example Startup está demorando muito para criar novas contas para fins de teste e isso está sufocando a inovação. A equipe da plataforma explica que eles não têm largura de banda para criar contas individuais sempre que alguém tem uma nova ideia para um recurso. Neste momento de sua jornada na AWS, a equipe da plataforma tem uma reunião quinzenal com a equipe de contas da AWS e eles abordam o dilema. O solutions architect (SA – arquiteto de soluções) da AWS recomenda a criação de uma Unidade Organizacional (UO) dedicada ao Sandbox em sua organização da AWS para provisionar rapidamente recursos e ambientes temporários para outras equipes que desejam testar novos serviços e recursos da AWS. Além disso, para manter os custos sob controle, o SA recomenda o uso da automação para interromper automaticamente recursos como instâncias do Amazon EC2 fora do horário comercial normal. A equipe da plataforma da Example Startup segue os conselhos da SA. Eles são capazes de criar contas rapidamente para as diferentes equipes da startup e fazer isso de forma controlada.

Depois disso, a equipe recém-contratada de SRE percebe que a startup pode estar melhor posicionada do ponto de vista de disponibilidade e recuperação de desastres (DR). Eles reconhecem que a startup está crescendo rapidamente e, à medida que começa a atingir clientes maiores, ela enfrentará requisitos de segurança mais rigorosos, como auditorias e análises de conformidade. Isso significou a necessidade de alguma mudança na infraestrutura. Felizmente, grande parte do trabalho pesado de recuperação de desastres foi realizado quando a Example Startup modelizou sua infraestrutura no Terraform e fez a transição para uma arquitetura de várias contas na parte 3 da série.

Como primeira etapa, a equipe da Example Startup se familiariza com o Hub de Resiliência da AWS para saber mais sobre a criação de aplicações resilientes na AWS. A equipe ainda tem algumas perguntas pendentes, então ela se conecta com a equipe de contas da AWS, que a apresenta a um SA com experiência em resiliência. O SA trabalha com a Example Startup para especificar seus requisitos de objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO) e fazer uma análise de custo/benefício de diferentes cenários de recuperação de desastres. Depois de algumas ligações com o SA e muita deliberação interna, a equipe de SRE decide que seus requisitos de RTO/RPO ainda não exigem uma configuração multirregional. Ela toma a decisão de mover os dados transacionais do Amazon RDS para PostgreSQL para o Amazon Aurora para PostgreSQL, principalmente pela maior disponibilidade que ele oferece, bem como pela funcionalidade do Amazon Aurora Global Database, que é importante para seu banco de dados de produção. A startup também usa o AWS Audit Manager para avaliar sua adesão aos padrões de conformidade relevantes para a próxima auditoria. Sua funcionalidade de coleta automatizada de evidências economiza muito esforço manual.

Desenvolvimento de uma experiência do cliente otimizada

Depois de analisar o feedback do produto de vários clientes, o diretor de tecnologia (CTO) percebe que faltam os recursos de painel oferecidos aos negociadores na aplicação de negociação da Example Startup. Os concorrentes permitem que os usuários vejam facilmente uma representação visual do histórico e da performance da negociação (em comparação com outros negociadores) em um nível por negociação. O CTO sinaliza isso como uma lacuna crítica de recursos e o trabalho foi atribuído à nova equipe de análise. Além disso, o CTO deseja que a equipe permita que os negociadores gerem relatórios de negociação à vontade.

A equipe de análise tem experiência anterior com o Amazon Quicksight, portanto, o componente do painel será fácil de aprimorar, incluindo um recurso de detecção de anomalias para ajudar os negociadores a encontrar negociações específicas que são discrepantes. A solicitação de relatórios é mais complexa, pois eles não querem incomodar as equipes de desenvolvedores executando esses relatórios no banco de dados de produção (nem isso seria considerado uma boa prática). Depois de consultar o whitepaper Modern Data Architecture on AWS, a equipe de análise percebe que a melhor maneira de fazer isso é carregar os dados do Amazon RDS para PostgreSQL no Amazon Redshift, um data warehouse. Ao usar o enorme paralelismo do Amazon Redshift, eles poderão executar agregações complexas contra esses dados transacionais com muito menos latência e com a vantagem adicional de não prejudicar o banco de dados de produção. A equipe de análise tem o prazer de descobrir que, como o Amazon Redshift foi criado com base no mecanismo PostgreSQL, eles podem reutilizar a maioria de suas consultas.

Adicionar uma nova linha de negócios à startup

À medida que todas essas mudanças ocorrem, a diretora executiva (CEO) participa de uma reunião com uma de suas ex-colegas em uma grande empresa comercial. Ela descobre que há uma escassez de negociadores eficazes no mercado e isso está afetando negativamente o fluxo de contratações da empresa comercial e os projetos futuros. A CEO liga para algumas de suas amigas em empresas comerciais que confirmam que isso é uma escassez em todo o setor. O CEO começa a formar uma ideia: a Example Startup tem muitos traders com boa performance. E se a Example Startup fornecesse a seus negociadores algum tipo de treinamento baseado em coorte que, então, alimentaria um fluxo de talentos para essas empresas comerciais? Isso daria aos comerciantes a chance de entrar no mercado de trabalho e as empresas comerciais teriam novos talentos.

Como uma parte fundamental do treinamento seria recomendar as negociações corretas para novos trainees, o CEO configura uma ligação com a equipe de ciência de dados para saber com que rapidez eles podem criar um modelo de machine learning (ML). Felizmente, alguns membros da equipe de ciência de dados têm experiência anterior em criar, treinar e implantar modelos com o Amazon Sagemaker. Como o Amazon Redshift é uma das fontes de dados disponíveis para o SageMaker, a equipe de ciência de dados não precisará configurar um pipeline complexo de extração, transformação e carregamento (ETL). Membros da equipe de ciência de dados com menos experiência com o SageMaker foram convidados pela equipe de contas da AWS para um dia de imersão focado no SageMaker para aprimorar suas habilidades rapidamente. Logo, eles também começaram a criar trabalhos de treinamento, criar modelos precisos e implantá-los em endpoints. Antecipando a ligação da equipe financeira da Example Startup sobre o aumento dos custos de computação, a equipe de ciência de dados fez algumas pesquisas e descobriu que eles poderiam realmente realizar seus trabalhos de treinamento (que representam aproximadamente 80% de seus custos totais) em instâncias spot. Ao fazer isso, eles conseguiram reduzir significativamente seus custos.

À medida que a notícia dessa iniciativa de desenvolvimento de talentos, como uma nova linha de negócios e fluxo de receita, se espalha pelo setor, mais empresas de capital de risco começaram a expressar interesse na Example Startup, mesmo antes de a startup expressar a intenção de iniciar outra rodada de arrecadação de fundos!

Alguns trimestres depois, guiada por esforços de marketing, esforços de co-marketing com a AWS e pelo boca a boca de clientes existentes, a iniciativa de desenvolvimento de talentos da Example Startup cresceu rapidamente. Por mais empolgante que seja o crescimento da base de clientes, mais empolgante é o fato de a startup estar, pela primeira vez desde o início, no verde! O recrutamento acaba sendo um negócio lucrativo para a startup e cresce a cada dia. A equipe executiva percebe que esse fluxo constante de lucratividade pode impulsionar o resto de seus negócios. Eles trabalham diligentemente em novos planos de expansão e inovação, entusiasmados com o incrível futuro que está por vir.

Resumo

Ao longo desta série de quatro partes, Example Startup percorre os principais estágios de uma startup, desde o nascimento até uma empresa madura. A maioria das startups começa com pouco mais do que uma ideia ousada e uma equipe fundadora dedicada. Eles criam um produto mínimo viável (MVP) com infraestrutura sem servidor que lhes permite testar suas ideias de uma forma que a equipe fundadora possa gerenciar por conta própria.

À medida que a startup adquire clientes pagantes e garante financiamento pós-inicial, ela passa para a fase de “estar no caminho certo”, na qual sua arquitetura evolui e começa a pensar seriamente em escalabilidade, segurança e agilidade de desenvolvimento. Isso significa melhorias, como o uso de ferramentas de construção e a configuração de bancos de dados de monitoramento e com propósito específico.

Uma das lições mais importantes durante esses estágios é interagir com a equipe da AWS com antecedência e frequência, mesmo antes de iniciar os projetos, para ajudar a avaliar as opções e economizar tempo. O acesso a recursos comerciais e técnicos pode acelerar os cronogramas e ajudar as equipes de startups em estágio inicial a atingirem suas metas.

Após a fase de adequação do mercado de produtos, as startups podem começar a contratar mais e se concentrar principalmente na escalabilidade, a fase “até a lua”. Nesse ponto, elas começam a analisar uma estratégia de várias contas, usando arquitetura orientada a serviços, armazenamento em cache e outros ajustes arquitetônicos para otimizar suas aplicações e melhorar a experiência do cliente do ponto de vista técnico.

Por fim, elas entram no estágio de hiperescala, em que podem iniciar contratações extensivas e desenvolver linhas adicionais de negócios. Do ponto de vista técnico, a startup investiu muito tempo e esforços de engenharia para melhorar coisas como segurança, controles e permissões para seu ambiente. Ela provavelmente tem uma versão codificada de seu ambiente que pode aproveitar para uma rápida expansão internacional e recuperação de desastres, entre outros casos de uso. Ela também criou uma estratégia de dados e está usando análises e machine learning para entender melhor seus clientes e negócios. Essa fase final pode variar. Algumas startups estarão no caminho de uma aquisição, enquanto outras podem buscar lucratividade e domínio do mercado.

Que tal dar início à jornada de sua startup? Participe do AWS Activate para criar e escalar sua startup com os recursos certos no momento certo.

Confira toda a série Evolutionary Architectures:

• Evolutionary Architectures, parte 1: “Eu tenho essa ótima ideia!”
• Evolutionary Architectures, parte 2: “Acho que podemos estar no caminho certo”.
• Evolutionary Architectures, parte 3 — “Para a lua”.