Na parte 2 desta série , aplicamos os conceitos introduzidos pela primeira vez na parte 1 e projetamos uma startup fictícia de software de namoro online chamada eTumble. Produzimos “documentos vivos” para nossa estratégia, design e arquitetura. O objetivo desta postagem é reunir tudo e planejar a infraestrutura necessária para dar vida à nossa ideia e acomodar nossas futuras necessidades de dimensionamento.

Pré-requisitos para avançar

• Você leu a parte 1 da série
• Você está familiarizado com as estruturas/metodologias que exploramos abaixo, pelo menos assistindo aos links de vídeo compartilhados na parte 1
• Você leu a parte 2 da série

Sem escrever uma única linha de código ou gastar dinheiro , nossos exercícios de “documentos vivos” produzidos na parte 2 revelaram os requisitos do sistema que informam nossas futuras necessidades de infraestrutura de hospedagem:

Não precisamos satisfazer todas as necessidades “além” imediatamente, mas estar ciente delas ao projetar e construir nosso MVP pode ajudar a minimizar o retrabalho. Vamos explorar como!

Escopo MVP inicial com base no mapa da história e OGSM

O eTumble está se preparando para se tornar a próxima grande novidade no namoro online. Nossa equipe sabiamente dedicou tempo para realizar uma análise SWOT, documentou nosso plano estratégico de 3 a 5 anos usando o OGSM Framework, visualizou e priorizou nosso MVP usando o Story Mapping e projetou e documentou nossa arquitetura usando partes da metodologia C4 Model.

Nosso plano OGSM identificou uma meta inicial de 25.000 usuários no ano 1 e táticas para atingir nossa meta, como programa de referência e demonstrações no campus da faculdade. Depois de várias iterações de mapeamento de histórias, estabelecemos nosso escopo de MVP - e o anotamos .

Se pularmos o planejamento estratégico para identificar a importância das promoções, talvez não tenhamos iterado o suficiente no mapa da história para definir o MVP, que ajuda a priorizar o que construímos primeiro. Ainda mais assustador, podemos chamá-lo de “Mike's Match Maker” (acima) em vez de nosso nome mais legal, eTumble. ;-)

Colocar nosso MVP nas mãos dos usuários pretendidos rapidamente nos dará uma melhor compreensão do domínio do problema e, consequentemente, afetará as decisões no nível estratégico e de ideação. É por isso que nossos planos são chamados de “documentos vivos” e devem ser repetidos ao longo do tempo conforme aprendemos.

Selecionando nossa plataforma de hospedagem na nuvem

A seleção de um fornecedor de hospedagem em nuvem pode se tornar um exercício político ou religioso dentro de qualquer organização ou equipe. Prefiro usar uma abordagem baseada em dados para essas decisões e descrevi como fizemos isso em uma empresa anterior nesta entrevista do BrightTALK em 2020.

Nas partes anteriores desta série, deixei escapar o fato de que usaremos o Google Cloud Platform (GCP), então explicarei brevemente minha abordagem típica.

Eu orquestrei esse processo em organizações anteriores, e uma tinha uma linha de produtos com uma estratégia móvel primeiro, então meus motivos para selecionar o GCP decorrem da experiência anterior e do suporte a milhares de empresas no DoiT. O AWS Amplify é uma solução concorrente, mas fica aquém do GCP Firebase usando muitos dos critérios acima, especialmente a facilidade de uso.

Este artigo apresenta mais detalhes comparando as duas estruturas móveis populares, GCP Firebase vs. AWS Amplify , mas está por trás do paywall do Medium. O consenso foi que o Firebase é mais abrangente, mais fácil de usar e pode ser mais econômico.

Independentemente da plataforma que você escolher, identificamos os requisitos de curto e longo prazo do nosso sistema. Vamos supor que passamos pelo processo de avaliação acima, selecionamos o GCP por vários motivos e agora temos que projetar nossa infraestrutura de hospedagem em nuvem.

Automatizando nossas implantações de código-fonte

Além de seu pessoal, no núcleo de cada startup de software está seu código-fonte - o texto estruturado que é convertido em instruções que um computador pode entender e processar. Para que nossos programas alcancem nosso público-alvo (supondo que não haja “Smokescreen MVP” neste estágio), eles precisam ser implantados em nosso(s) ambiente(s) de hospedagem escolhido(s).

Uma de nossas estratégias para o eTumble é inovar mais rápido que os outros. Embora isso possa descrever muitos aspectos de uma inicialização de software, vamos nos concentrar na velocidade do desenvolvedor e na taxa na qual a nova funcionalidade (histórias do usuário) pode ser realizada pelos usuários finais. Existem estudos que provam que isso é uma vantagem competitiva, mas não entraremos em todos os detalhes de DevOps e DevSecOps e pipelines de CI/CD neste artigo.

Como isso ocorre pode ser uma preferência pessoal da equipe de desenvolvimento. Muitos fornecedores de hospedagem de código-fonte (por exemplo, — Github.com, Gitlab.com ou Bitbucket.com) agora têm suas próprias ferramentas. Muitos também oferecem webhooks quando ocorrem eventos que acionam soluções de terceiros. Cada provedor de hospedagem em nuvem também tem seus próprios serviços, como Azure Dev Ops da Microsoft ou Cloud Build e Cloud Deploy do GCP.

Normalmente, minha recomendação para a maioria das organizações é considerar a solução de provedor de nuvem, minimamente para a fase de "implantação" de seus pipelines de construção, porque elimina a necessidade de compartilhar chaves de conta de serviço de longa duração (que podem ser comprometidas) com terceiros sistema. O GCP oferece Federação de identidade de carga de trabalho que permite atribuir funções IAM a uma solução de terceiros sem compartilhar chaves, o que também é uma opção.

Considerações para escalar na nuvem

Para monólito ou não

Vamos enfrentá-lo, as startups de software mais bem-sucedidas globalmente hoje começaram como um aplicativo monolítico de 3 camadas. Não há nada de errado com monólitos no estágio inicial. O acoplamento minimiza muitas complexidades técnicas e, como as “topologias de equipe” implicam, essas decisões geralmente envolvem a carga cognitiva de sua equipe . Com uma meta de 25.000 usuários em nosso primeiro ano e foco no campus da faculdade, esse é um design totalmente aceitável para o escopo do nosso MVP.

O problema geralmente ocorre quando você começa a dimensionar. Não tema, no entanto, porque podemos projetar nossa solução “rápida e suja” para fatorar facilmente nossa futura arquitetura de microsserviços.

Em nossos diagramas de arquitetura do Modelo C4, identificamos “Controllers” na visualização do componente, para o aplicativo “Backend API”. As linhas que indicam a publicação de mensagens no Pub/Sub, por exemplo, podem incluir inicialmente a lógica do microsserviço no aplicativo API na camada “Model” da arquitetura Model-View-Controller (MVC). As rotas da API permanecem as mesmas.

Ao incluir microsserviços, podemos mover a funcionalidade “Modelo” do aplicativo API para serviços separados e comunicar via HTTP/RPC ou mensagens assíncronas. Se planejar com antecedência, você pode projetar uma camada wrapper para as chamadas de função ou método que interagem com uma camada de dados inicialmente e fazer a transição para chamadas remotas no futuro com alterações mínimas de código.

No entanto, se você projetou sistemas distribuídos suficientes, pode optar por uma arquitetura orientada a eventos, conforme ilustrado em nosso Diagrama de contêiner.

Indo “sem servidor” ou usando contêineres

No início desta série de 3 partes, afirmei que as startups de software hoje têm uma vantagem sobre as de cinco a dez anos atrás, em parte devido aos provedores de nuvem em hiperescala. Produtos sem servidor, como AWS Lambda, Google Cloud Functions ou até Azure Functions, são um ótimo exemplo. Os desenvolvedores podem enviar seu código para esses “tempos de execução” e se beneficiar de nenhuma manutenção de infraestrutura e dimensionamento automático.

Embora esta pareça ser a abordagem óbvia para lançar seu MVP, esteja atento ao campo minado de dívida técnica que você planta ao longo do caminho. Alguns desses serviços oferecem um emulador para que você possa criar e testar localmente, ajudando a reduzir a dependência e o custo de outro ambiente.

Prefiro aproveitar soluções sem servidor para pequenos trabalhos assíncronos de propósito único que são acionados por eventos em seu sistema como “arquivo carregado ou alterado” ou “mensagem publicada”.

Para criar uma API que encaminhará solicitações para várias partes de back-end, um aplicativo em contêiner pode ser uma escolha mais sábia. Como todas as dependências são empacotadas na imagem, os contêineres simplificam o desenvolvimento e os testes locais. A maioria dos provedores de hospedagem em nuvem oferece uma solução de contêiner “sem servidor”, como ECS na AWS e Cloud Run ou App Engine Flexível no GCP.

Prefiro a portabilidade de contêineres para aplicativos mais complexos e, se você seguir os princípios da metodologia de aplicativo de 12 fatores , eles também reduzirão o risco de desvio de configuração em diferentes ambientes em seu pipeline de CI/CD.

Priyanka Vergadia no Google fornece uma coleção de “notas de esboço” e esta ilustração abaixo “ Onde devo executar minhas coisas ” é um guia útil.

Aproveitando grupos de e-mail para escalar de uma para várias equipes

Suponha que começamos com algumas pessoas, mas nosso plano eventualmente requer suporte a dezenas de milhões de usuários em muitos países. Sem dúvida, dimensionaremos nossa organização para incluir muitas equipes e especialistas (o eixo y e o eixo z do AKF Scale Cube também se aplicam à nossa organização).

A prática recomendada ao configurar o gerenciamento de identidade e acesso (IAM) com plataformas de nuvem é atribuir funções a grupos em vez de usuários individuais. Em um artigo que escrevi há alguns anos sobre como estruturar empresas na nuvem , explico os grupos iniciais recomendados e muito mais.

os grupos que estabelecemos no estágio inicial podem escalar com a organização (apenas os membros mudam com o tempo)

Mesmo que nossa startup comece com três pessoas, nada nos impede de definir grupos e adicionar pessoas a vários deles para começar . À medida que contratamos mais pessoas, podemos gradualmente deixar os grupos para os especialistas.

Em escala empresarial, você pode eventualmente dividir as equipes ainda mais conforme as necessidades e demandas de carga cognitiva. Não importa por onde você comece, a prática recomendada é conceder funções do Cloud IAM a grupos, em vez de usuários individuais, para facilitar a manutenção e minimizar o retrabalho — observe o padrão aqui.

Projetando sua hierarquia de recursos de nuvem para multilocação

Esta lista de verificação Secure GCP Reference que criei há alguns anos inclui um exemplo ilustrativo de design de práticas recomendadas. Como estamos projetando nossa arquitetura de nuvem para nosso MVP, pode haver algum trabalho “descartável” durante o estágio inicial, mas ainda assim recomendei uma estrutura semelhante ao configurar qualquer hierarquia de recursos de nuvem.

À medida que a organização escala, avançando para versões posteriores do produto ilustrado em nosso mapa da história do usuário, podemos mudar para administração de rede centralizada, gerenciamento de cluster Kubernetes e estrutura de equipe multilocatário. Isso geralmente atrapalha as startups de software quando elas atingem os pontos de inflexão descritos na parte 1 desta série.

pode haver algum trabalho “descartável” durante o estágio inicial

O GCP tem uma ótima referência que descreve como estabelecer a multilocação corporativa com mais detalhes. Abaixo está uma ilustração de como a infraestrutura de nuvem eTumble pode parecer no futuro quando atingirmos nossas metas Y2 e Y3 (ignorando a exibição de recursos para brevidade do artigo).

A principal conclusão aqui é observar que os projetos iniciais de pasta de serviços compartilhados nunca mudam, e os grupos que estabelecemos no estágio inicial podem ser dimensionados com a organização (apenas os membros mudam com o tempo). Cada locatário (equipe) mantém seus recursos específicos, como bancos de dados e segredos em seus respectivos projetos, e são referenciados pelos aplicativos em contêiner implantados em clusters em seus respectivos namespaces.

Sistemas externos (autenticação, pagamentos, e-mail, etc.)

Nosso plano e projetos ilustraram a necessidade de sistemas externos, como e-mail transacional, pagamentos online e, possivelmente, identidade e autenticação. Ao selecionar fornecedores de soluções externas, considere o seguinte:

• vários ambientes para teste e produção com autenticação separada
• manutenção e rotação de credenciais no armazenamento secreto criptografado
• incentivos comerciais disponíveis para compra no marketplace

Parabéns por chegar até aqui! Esta série de 3 partes leva você a uma jornada de metodologias e estruturas úteis, para projetar uma inicialização de software a partir do zero e, finalmente, usar “documentos ativos” para planejar a infraestrutura de nuvem para o estágio inicial e posterior.

• Parte 1: histórico e introdução à metodologia
• Parte 2: implementando metodologias com startup fictícia
• Parte 3: projetando e dimensionando a infraestrutura de nuvem

Estou ansioso para que você pegue esses princípios e termine de onde paramos para ajudar a resolver a solidão em escala planetária . ;-)

Se você acha que esta série será útil para outras pessoas, não a guarde em segredo. Dê a cada parte um pouco de “amor” e palmas e compartilhe com os outros. Obrigado por ler!