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 melhorar a velocidade, o custo e a opcionalidade. Opcionalidade é a rapidez para alterar as direções 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 é adequado para uma startup que ainda não encontrou Product Market Fit ou tração nos negócios.
Para a pilha principal de uma startup, um design monolítico simples é a melhor opção. Esse design limita o tempo gasto com o gerenciamento da infraestrutura e oferece uma ampla capacidade de dimensionamento à medida que a startup ganha mais clientes.
Possíveis casos de uso
Este artigo apresenta um exemplo de uma pilha principal simples de uma startup e analisa seus componentes.
Arquitetura
A Contoso, uma startup, 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 está executando demonstrações nos laptops. Agora ela quer implantar o aplicativo nas primeiras reuniões de vendas ao cliente.
Embora o aplicativo seja arrojado, ele não precisa de uma arquitetura complexa controlada por microsserviço. A Contoso optou por um design monolítico simples que inclui os componentes de pilha de startup recomendados.
Baixe um Arquivo Visio dessa arquitetura.
Fluxo de dados
Nesta arquitetura de pilha principal de uma startup:
- O Serviço de Aplicativo do Azure fornece um servidor de aplicativo simples para implantar aplicativos escaloná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 RDBMS (sistema de gerenciamento de banco de dados relacionais) de código aberto líder. Você pode se concentrar no desenvolvimento do aplicativo em vez de gerenciar servidores de banco de dados.
- ARede Virtual do Azure segmenta o tráfego de rede e mantém os serviços internos protegidos contra ameaças da Internet. Os servidores de aplicativos usam a integração de rede virtual para se comunicar com o banco de dados sem exposição à Internet.
- O GitHub Actions gera integração contínua e implantação contínua (CI/CD) em seu gerenciamento de código-fonte. GitHub Actions tem amplo suporte para diferentes linguagens e ótima integração com os serviços do Azure.
- O Armazenamento de Blobs do Azure armazena ativos estáticos e move a carga para fora dos servidores de aplicativos.
- A CDN (Rede de Distribuição de Conteúdo do Microsoft Azure) acelera a entrega de conteúdo aos usuários por meio de uma rede global.
- O Azure Monitor monitora e analisa o que está acontecendo na infraestrutura do aplicativo.
Componentes da pilha principal de uma startup
Uma pilha complexa pode gerar bugs que exigem atenção constante. Uma arquitetura sofisticada pode prejudicar a criação de seu produto. Os bugs não são causados pela complexidade, mas pilhas complexas facilitam o surgimento de bugs. Nem todas as arquiteturas sofisticadas são um desperdício de energia, mas elas desperdiçam seus recursos se você ainda não encontrou Product Market Fit. Sua primeira pilha de startup deve ser simples e não exigir esforço, para que você se concentre no desenvolvimento de produtos.
O diagrama simples a seguir mostra a pilha principal de uma startup recomendada. Esses componentes são suficientes para tirar seu produto da produção e levá-lo até as mãos de seus clientes. Para 80% das startups, essa pilha é tudo o que é necessário para testar as hipóteses básicas criadas no produto. As startups que trabalham no aprendizado de máquina, na IoT (Internet das Coisas) ou em ambientes altamente regulamentados podem precisar de mais componentes.
CDN
Com poucos clientes no início, uma CDN pode parecer prematura. Porém, adicionar uma CDN a um produto já em produção pode ter efeitos colaterais inesperados. É melhor implementar uma CDN antecipadamente. A CDN armazenar em cache o conteúdo estático perto dos clientes e fornece uma fachada atrás que você pode iterar nas APIs e na arquitetura.
Servidor de aplicativos
Seu código precisa ser executado em algum lugar. O ideal é que essa plataforma facilite as implantações e exija o menor trabalho operacional possível. O servidor de aplicativos deve ser dimensionado horizontalmente, mas não há problema em intervir na escala manualmente durante a fase de exploração.
Assim como a maioria dessa pilha, o servidor de aplicativos deve ser autoexecutável. Antes, 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 buscar opções de PaaS (plataforma como serviço) e contêineres para remover a sobrecarga operacional.
Conteúdo estático
O serviço de conteúdo estático do servidor de aplicativos perde recursos. Depois de configurar um pipeline de CI/CD, o trabalho para criar e implantar ativos estáticos com cada versão é simples. A maioria das estruturas da Web de produção implanta ativos estáticos com CI/CD. Portanto, vale a pena adaptar-se a essa melhor prática.
Backup de banco de dados
Depois que o aplicativo é executado, você precisa armazenar seus dados em um banco de dados. Na maioria dos casos, um banco de dados relacional é a melhor solução. Bancos de dados relacionais têm vários métodos de acesso e a velocidade de uma solução testada no tempo. Os bancos de dados relacionais incluem o Banco de Dados SQL do Azure, o Banco de Dados do Azure para PostgreSQL e 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 o MongoDB e o Azure Cosmos DB.
Agregação de log
Quando algo dá errado com o seu aplicativo, você quer gastar o menor 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. Você não precisa acessar um arquivo no servidor de aplicativos e analisar os logs para obter dados de monitoramento.
CI/CD
A falta de implantações repetidas e rápidas é o que mais atrasa a iteração de um produto. Um pipeline de CI/CD bem configurado simplifica o processo de implantação de código no servidor de aplicativos. Com implantações rápidas e fáceis, os resultados do trabalho aparecem rapidamente. A integração frequente evita bases de código divergentes que levam a conflitos de mesclagem.
Implantar este cenário
Os conceitos e as técnicas são iguais na maioria dos projetos criados com um Dockerfile.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Andrew Harvey | CTO e Startup Advocate