Muitas lições que você aprende em empresas maiores não são diretamente aplicáveis à primeira pilha de uma startup. No estágio inicial de exploração de um produto, você precisa otimizar a implantação para velocidade, custo e opcionalidade. Opcionalidade refere-se à rapidez com que você pode mudar de direção dentro de uma determinada arquitetura.
Uma empresa nas fases de expansão ou extração do desenvolvimento de produtos pode usar uma arquitetura orientada a serviços ou microsserviços. Esse tipo de arquitetura de implantação raramente é ideal para uma startup que ainda não encontrou adequação ao produto/mercado ou tração comercial.
Para uma pilha de inicialização central, um design monolítico simples é melhor. Esse projeto limita o tempo gasto no gerenciamento da infraestrutura, ao mesmo tempo em que fornece ampla capacidade de escalar à medida que a startup conquista mais clientes.
Potenciais casos de utilização
Este artigo apresenta um exemplo de uma pilha de inicialização de núcleo simples e discute seus componentes.
Arquitetura
Uma startup, a Contoso, criou um protótipo de aplicativo com um back-end Ruby on Rails e um front-end React escrito em TypeScript. A equipe da Contoso tem executado demonstrações em seus laptops. Agora, eles querem implantar seu aplicativo para suas primeiras reuniões de vendas com clientes.
Embora o aplicativo seja ambicioso, ele ainda não precisa de uma arquitetura complexa e orientada a microsserviços. A Contoso optou por um design monolítico simples que inclui os componentes recomendados da pilha de inicialização.
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados
Nesta arquitetura de pilha de inicialização principal:
- O Serviço de Aplicativo do Azure fornece um servidor de aplicativos simples para implantar aplicativos escaláveis sem configurar servidores, balanceadores de carga ou outra infraestrutura.
- O Banco de Dados do Azure para PostgreSQL é um serviço de banco de dados do Azure para um sistema líder de gerenciamento de banco de dados relacional de código aberto (RDBMS). Você pode se concentrar no desenvolvimento de seu aplicativo em vez de gerenciar servidores de banco de dados.
- A Rede Virtual do Azure segmenta o tráfego de rede e mantém os serviços internos protegidos contra ameaças da Internet. Os servidores do aplicativo usam a integração de rede virtual para se comunicar com o banco de dados sem exposição à Internet.
- O GitHub Actions cria integração contínua e implantação contínua (CI/CD) em seu gerenciamento de código-fonte. O GitHub Actions tem suporte extensivo para diferentes idiomas e forte integração com os serviços do Azure.
- O Armazenamento de Blobs do Azure armazena ativos estáticos e move a carga para longe dos servidores de aplicativos.
- A CDN (Rede de Entrega de Conteúdo) do Azure acelera a entrega de conteúdo aos utilizadores através de uma rede global.
- O Azure Monitor monitoriza e analisa o que está a acontecer na infraestrutura da sua aplicação.
Principais componentes da pilha de inicialização
Uma pilha complexa pode gerar bugs que exigem atenção constante. Uma arquitetura sofisticada pode prejudicar a construção do seu produto. Os bugs não são causados pela complexidade, mas uma pilha complexa facilita o envio de bugs. Nem todas as arquiteturas sofisticadas são um desperdício de energia, mas desperdiçam seus recursos se você ainda não encontrou o produto/mercado adequado. Sua primeira pilha de inicialização deve ser simples e sair do seu caminho, para que você possa se concentrar no desenvolvimento de produtos.
O diagrama simples a seguir mostra a pilha de inicialização principal recomendada. Estes componentes são suficientes para tirar o seu produto do papel e colocá-lo nas mãos dos seus clientes. Para 80% das startups, essa pilha é tudo o que você precisa para testar as hipóteses básicas incorporadas ao seu produto. Startups que trabalham em aprendizado de máquina, internet das coisas (IoT) ou ambientes altamente regulamentados podem exigir mais componentes.
CDN
Com poucos clientes no início, uma CDN pode parecer prematura. No entanto, adicionar uma CDN a um produto já em produção pode ter efeitos colaterais inesperados. É melhor implementar uma CDN antecipadamente. Uma CDN armazena em cache o conteúdo estático mais perto de seus clientes e fornece uma fachada atrás da qual você pode iterar em suas APIs e sua arquitetura.
Servidor de aplicações
Seu código precisa ser executado em algum lugar. Idealmente, essa plataforma deve facilitar as implantações, exigindo o mínimo de entrada operacional possível. O servidor de aplicativos deve ser dimensionado horizontalmente, mas alguma intervenção de dimensionamento manual é boa enquanto você ainda está no estágio de exploração.
Como a maioria dessa pilha, o servidor de aplicativos deve essencialmente ser executado por si mesmo. Tradicionalmente, o servidor de aplicativos era uma máquina virtual ou uma instância de servidor Web em execução em um servidor bare-metal. Agora, você pode procurar opções e contêineres de plataforma como serviço (PaaS) para remover a sobrecarga operacional.
Conteúdo estático
A veiculação de conteúdo estático do servidor de aplicativos desperdiça recursos. Depois de configurar um pipeline de CI/CD, o trabalho para criar e implantar ativos estáticos com cada versão é trivial. A maioria das estruturas da Web de produção implanta ativos estáticos com CI/CD, por isso vale a pena começar alinhando com essa prática recomendada.
Base de dados
Depois que seu aplicativo estiver em execução, você precisará armazenar seus dados em um banco de dados. Para a maioria dos casos, um banco de dados relacional é a melhor solução. Um banco de dados relacional tem vários métodos de acesso e a velocidade de uma solução testada pelo tempo. Os bancos de dados relacionais incluem o Banco de Dados SQL do Azure, o Banco de Dados do Azure para PostgreSQL e o Banco de Dados do Azure para MariaDB. Alguns casos de uso precisam de um banco de dados de documentos ou banco de dados NoSQL, como MongoDB ou Azure Cosmos DB.
Agregação de logs
Se algo der errado com seu aplicativo, você deseja gastar o mínimo de tempo possível diagnosticando o problema. Ao agregar logs e usar o rastreamento de aplicativos desde o início, você ajuda sua equipe a se concentrar nos problemas em si. Você não precisa acessar um arquivo no servidor do aplicativo e se debruçar sobre os logs para obter dados de monitoramento.
CI/CD
A falta de implantações rápidas e repetíveis é um dos piores impedimentos para acelerar quando você está iterando em um produto. Um pipeline de CI/CD bem configurado simplifica o processo de implantação de código no servidor de aplicativos. Implantações rápidas e fáceis significam que você vê os resultados do seu trabalho rapidamente. A integração frequente evita bases de código divergentes que levam a conflitos de fusão.
Implementar este cenário
Os conceitos e técnicas são os mesmos para a maioria dos projetos que você cria usando um Dockerfile.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Andrew Harvey - Brasil | CTO e Startup Advocate