Fundamentos da Plataforma Azure para Startups

Este artigo fornece uma orientação rápida com uma lente de inicialização em cinco pilares de plataforma fundamental: computação, rede, armazenamento, contêineres e dados. Para cada pilar, você recebe uma breve tabela de decisão que relaciona sua situação a um serviço padrão, além de uma nota sobre quando reavaliar essa escolha à medida que sua startup cresce.

Neste artigo, você aprenderá a

Escolha os recursos básicos de computação, rede e armazenamento do Azure adequados para a sua etapa.
Decida se o Serviço de Kubernetes do Azure é a plataforma de contêineres certa para o seu momento e o que usar no lugar dele se não for.
Escolha uma primeira plataforma de dados entre cargas de trabalho relacionais, de documento, de vetor e de análise.
Aplique um pequeno conjunto de configurações padrão de custo, confiabilidade e segurança que continuem funcionando bem conforme você cresce.
Reconhecer os sinais que dizem que uma opção padrão superou sua utilidade.

Prerequisites

Uma assinatura de Azure ativa.
CLI do Azure está instalado e conectado. Para entrar, execute az login.
Acesso de proprietário ou colaborador em pelo menos um grupo de recursos.
A familiaridade com a página inicial do portal do Azure é útil, mas não é necessária.
Familiaridade básica com os fundamentos do Azure (regiões, assinaturas e grupos de recursos).

Por que isso é importante para startups

Em uma startup nos estágios iniciais, o custo de fazer a escolha errada de infraestrutura não está na fatura. É a semana que você perde ao migrar para fora do serviço errado depois de já ter construído sua solução em torno dele. Os cinco pilares deste artigo são aqueles em que uma escolha padrão mal feita tende a gerar efeitos cumulativos: a plataforma de computação inadequada molda seu pipeline de implantação; o banco de dados inadequado restringe seu modelo de dados; a topologia de rede inadequada bloqueia seu primeiro cliente empresarial. Você não precisa de uma equipe de plataforma, um engenheiro de confiabilidade do site ou um especialista em operações financeiras para fazer essas escolhas bem. Você precisa de uma opção padrão que seja boa o suficiente para ser lançada, e de um sinal claro que indique quando reavaliá-la. Se a sua startup estiver no programa Microsoft for Startups, as mesmas configurações padrão fazem seus créditos renderem mais e mantêm sua startup elegível para benefícios avançados no futuro.

Computação: em que o código é executado

Azure tem mais de uma dúzia de serviços de computação. A boa notícia: para a maioria das cargas de trabalho em estágio inicial, três delas abrangem o que você precisa.

Sua situação	Serviço de Azure padrão	Por que	Revisitar quando
Aplicativo Web ou API HTTP, um ou dois serviços, você deseja um runtime gerenciado	Serviço de Aplicativo do Azure (Linux)	Não é necessário nenhum build de contêiner. TLS interno, domínios personalizados, slots de implantação e dimensionamento automático. Os planos gratuitos e básicos são baratos o suficiente para executar um ambiente de homologação, embora slots e o escalonamento automático exijam o Standard ou superior.	Você deseja executar mais de alguns serviços, precisa de escalabilidade por serviço ou precisa de sidecars.
Função controlada por eventos, trabalho agendado ou manipulador de webhook	Azure Functions (plano de consumo)	Pagamento por execução. Redimensiona até zero. As associações removem a maioria dos códigos de cola para filas, blobs e gatilhos HTTP.	O frio começa a prejudicar a latência voltada para o usuário ou você excede os limites do plano de consumo.
Microsserviços em contêineres, você quer um ambiente de execução opinativo sem precisar gerenciar o Kubernetes	Aplicativos de Contêiner do Azure	Criado no Kubernetes com dimensionamento automático baseado em KEDA, mas você não gerencia o cluster. O Dapr está disponível como uma integração opcional. Escala para zero, revisões e entrada HTTPS incluídas.	Você precisa de controle no nível do cluster, um agendador personalizado ou rede avançada.
Processamento em lote de longa duração, treinamento com GPU ou o lift-and-shift de uma carga de trabalho de máquina virtual existente	Máquinas Virtuais do Azure	Controle total do sistema operacional. Use um conjunto de dimensionamento de máquinas virtuais quando precisar de escala horizontal.	A sobrecarga operacional da aplicação de patches e do gerenciamento de imagens começa a atrasar as entregas.
Você tem certeza de que precisa do Kubernetes (consulte a seção 4 antes de assumir isso)	Serviço de Kubernetes do Azure	Plano de controle gerenciado. Atende às equipes que já têm experiência do Kubernetes ou requisitos específicos de plataforma.	Consulte a seção Contêineres para obter critérios de decisão do AKS.

Dica

Comece com o Serviço de Aplicativo para seu primeiro aplicativo Web voltado para o usuário e Azure Functions para tudo controlado por eventos. Você pode migrar para o Aplicativos de Contêiner do Azure ou o Serviço de Kubernetes do Azure mais tarde sem alterar o código do aplicativo, se mantiver o aplicativo sem estado e gravar a configuração em variáveis de ambiente.

Escolhendo entre Container Apps e App Service

Os Aplicativos de Contêineres e o App Service se sobrepõem. O critério de desempate mais honesto: se o seu aplicativo já roda como uma imagem de contêiner e você quer escala por serviço (réplicas diferentes para a camada web em comparação com o worker), o Container Apps leva vantagem. Se o aplicativo for um único processo Web e você não quiser manter um Dockerfile, o Serviço de Aplicativo vencerá.

Caution

Considere Serviço de Kubernetes do Azure quando você tiver requisitos claros que não são atendidos por opções mais simples. Embora ofereça forte flexibilidade e controle, ele também apresenta considerações operacionais adicionais (como atualizações, dimensionamento do pool de nós, configuração de entrada e gerenciamento de certificados). Se adotado muito cedo, as equipes geralmente encontram mais tempo entrando no gerenciamento de plataformas do que na criação de recursos de produtos.

Rede: o que configurar no primeiro dia

A maioria das cargas de trabalho de Azure em estágio inicial não precisa de uma rede virtual no primeiro dia. App Service, Functions, Container Apps e a maioria dos bancos de dados gerenciados oferecem endpoints públicos com TLS que são seguros para expor, desde que você configure a autenticação corretamente. Adicionar complexidade de rede antes de ter um motivo é a otimização prematura mais comum em Azure.

Sua situação	Abordagem padrão	Por que	Revisitar quando
Aplicativo novo, tráfego da Web público, nenhum requisito de conformidade ainda	Use o ponto de extremidade público com TLS. Nenhuma rede virtual.	Menor sobrecarga operacional. O Serviço de Aplicativo, os Aplicativos de Contêiner e os bancos de dados gerenciados manipulam o TLS para você. Use Microsoft Entra ID para autenticação.	Seu primeiro cliente corporativo solicita conectividade privada.
Você precisa de uma conexão privada entre seu aplicativo e um banco de dados gerenciado	Integração de rede virtual no lado da computação, ponto de extremidade privado no lado do banco de dados	O tráfego permanece no backbone do Microsoft. Nenhuma exposição pública para o banco de dados. Mesmo serviço gerenciado, sem alteração de aplicativo.	Primeiro dia se você manipular dados protegidos; caso contrário, quando uma auditoria ou cliente perguntar.
Você precisa de um único ponto de entrada público que faça frente a vários back-ends com roteamento, terminação TLS e um firewall de aplicativo Web	Azure Front Door (global) ou Gateway de Aplicativo do Azure (regional)	O Front Door adiciona uma rede de distribuição de conteúdo global e um cache de borda. O Application Gateway é a opção regional nativa de rede virtual.	Você superou o TLS interno do Serviço de Aplicativo e o roteamento.
Você precisa de endereços IP estáticos de saída (uma lista de permissões do processador de pagamento, por exemplo)	Gateway NAT conectado à sua rede virtual	IP de saída previsível. Exigido por muitas APIs de terceiros.	Um fornecedor requer isso. Não adicione isso por especulação.
Topologia de várias regiões ou várias contas	Emparelhamento de rede virtual ou WAN Virtual do Azure	A arquitetura de rede real começa aqui. Está fora do escopo da maioria das equipes na fase de exploração.	Várias regiões são um requisito real, não uma aspiração.

Importante

Bloqueie Microsoft Entra ID e suas atribuições de função de assinatura antes de se preocupar com o isolamento de rede. A maioria dos incidentes de segurança no Azure em pequenas empresas decorre de uma identidade com permissões excessivas, não de uma exposição de rede. Use grupos do Microsoft Entra ID para o acesso de engenharia e não conceda a função Proprietário no escopo da assinatura.

Armazenamento: blobs, arquivos e discos

Armazenamento do Azure é um único tipo de recurso (a conta de armazenamento) que expõe quatro serviços de dados: blobs, arquivos, filas e tabelas. Para decisões de armazenamento de aplicativos, você quase sempre está escolhendo entre blobs (armazenamento de objetos), arquivos (compartilhamentos de arquivos gerenciados) e discos gerenciados (armazenamento de blocos anexado a uma máquina virtual).

O que você está armazenando	Serviço de Azure padrão	Por que	Revisitar quando
Arquivos carregados pelo usuário, relatórios gerados, logs, artefatos de modelo, backups	Armazenamento de Blobs do Azure (camada quente)	Armazenamento de objetos. Barato, durável, escalável até petabytes. Use camadas de acesso esporádico ou de arquivamento mais tarde para dados que você não lê com frequência.	Você precisa de semântica de arquivo POSIX ou de leitura e gravação aleatórias em um único arquivo a partir de várias máquinas.
Um sistema de arquivos compartilhado montado por várias máquinas virtuais ou contêineres	Arquivos do Azure (Standard) ou Azure NetApp Files (alta taxa de transferência)	Volumes compartilhados do SMB (Bloco de Mensagens do Servidor) ou NFS (Sistema de Arquivos de Rede). Evite usá-los para conteúdo que se ajuste ao modelo de blob.	Você começa a usar um compartilhamento de arquivos como uma fila ou um banco de dados. Mover-se para a primitiva direita.
Discos para uma máquina virtual	Discos gerenciados SSD Premium v2	Desempenho ajustável, bom custo-benefício para discos para aplicativos. O SSD Premium v2 não pode ser usado como o disco do sistema operacional; emparelhe-o com SSD Premium (v1) ou SSD Standard para o sistema operacional. O SSD Standard é aceitável para cargas de trabalho de baixa taxa de transferência.	Você precisa de armazenamento em bloco compartilhado em máquinas virtuais (use Azure Elastic SAN ou Azure NetApp Files).
Ativos de site estáticos (pacote de aplicativo de página única, site de marketing, documentação)	Armazenamento do Azure hospedagem de site estático + Azure Front Door	Aplicativos Web Estáticos é o padrão moderno: domínios personalizados internos, TLS gerenciado gratuito, distribuição global GitHub Actions CI/CD e autenticação interna. O site estático de armazenamento + Front Door ainda funciona para configurações muito de baixo custo, mas não dá suporte nativo a cabeçalhos personalizados ou autenticação.	Você adiciona páginas renderizadas pelo servidor. Migrar para o App Service ou Container Apps.

Note

As contas de armazenamento têm um limite flexível de 250 por região por assinatura (passa para 500 por solicitação). Isso é suficiente para equipes em estágio inicial. O erro a ser evitado é criar uma conta de armazenamento por microsserviço; agrupar por ambiente (produção, preparo, desenvolvimento) e por padrão de acesso (quente, frio, arquivo morto) em vez disso.

Uma observação sobre backups

Backup do Azure e opções de redundância de conta de armazenamento (Armazenamento Com Redundância Local, Armazenamento Com Redundância de Zona, Armazenamento Com Redundância Geográfica) são ajustáveis por conta e por disco. O LRS (Armazenamento Com Redundância Local) é adequado para desenvolvimento e preparo. Use o ZRS (Armazenamento Com Redundância de Zona) para dados de produção. O Armazenamento com Redundância Geográfica adiciona custo e não substitui a recuperação de desastre no nível do aplicativo.

Contêineres e Serviço de Kubernetes do Azure

Azure tem três maneiras de executar contêineres em produção: Aplicativos de Contêiner do Azure, Instâncias de Contêiner do Azure e Serviço de Kubernetes do Azure. Eles correspondem a diferentes tamanhos de equipe e níveis de apetite operacional.

Sua situação	Serviço de Azure padrão	Por que	Quando começa a doer
Você tem imagens de contêiner e deseja um ambiente de execução gerenciado com ingresso HTTPS, escala para zero e revisões	Aplicativos de Contêiner do Azure	Plataforma sem servidor no Kubernetes com dimensionamento automático KEDA, mas você não vê ou gerencia o cluster. Pague apenas pelo que executar. Funciona bem até surgirem requisitos em nível de cluster. O Dapr está disponível como uma integração opcional.	Você precisa de agendadores personalizados, rede avançada (vários cartões de interface de rede, plug-ins personalizados da Interface de Rede de Contêiner) ou operadores específicos do Kubernetes.
Você deseja executar um único contêiner como um trabalho único ou um lote curto	Instâncias de Contêiner do Azure	Caminho mais rápido da imagem para o contêiner em execução. Nenhuma orquestração. Cobrado por segundo de tempo de execução.	Você precisa de qualquer coisa que se pareça com uma malha de serviço ou escalonamento automático para além de um único contêiner.
Você já opera o Kubernetes em outro lugar ou sua arquitetura de aplicativo realmente exige isso	Serviço de Kubernetes do Azure	Plano de controle gerenciado. Traga seus próprios pools de nós, plug-in de rede, controlador de entrada e pilha de observabilidade.	Dia 1º. Planeje atualizações contínuas (versão secundária lançada a cada 4 meses), ajuste do pool de nós e gerenciamento de certificados.
Você não tem certeza se precisa do Kubernetes	Apps de Contêiner por enquanto	Você pode recompilar em Serviço de Kubernetes do Azure mais tarde, se necessário. Levantar um aplicativo em contêiner sem estado é dias de trabalho, não semanas.	Você tem uma necessidade concreta (ecossistema do operador, política em nível de cluster) que consegue identificar claramente. “Preparar para o futuro” não é uma necessidade concreta.

Quando se formar no AKS

Mova para AKS (Serviço de Kubernetes do Azure) quando pelo menos dois deles forem verdadeiros:

Você executa mais de dez serviços com aspectos compartilhados de ciclo de vida e de rede.
Você precisa de controladores personalizados, sidecars ou CRDs (Definições de Recursos Personalizados) que o Container Apps não disponibiliza.
Você precisa de uma integração avançada com a rede virtual, com aplicação rigorosa de políticas.
Você está padronizando um ecossistema de código aberto baseado em Kubernetes (Argo, Istio, KEDA e assim por diante).

Se você adotar o AKS, siga a arquitetura da Linha de Base do AKS. A Microsoft Azure Well-Architected Framework e a referência de linha de base do AKS abrangem os padrões de segurança, dimensionamento e atualização desejados.

Configurações padrão do AKS para uma equipe pequena

Configuração	Default	Por que
Tamanho do nó	pool do sistema Standard_D4s_v5, pool de usuário Standard_D8s_v5	Preço a desempenho previsível para cargas de trabalho gerais
Dimensionador automático do cluster	Habilitado	Evite pagar por nós ociosos
Identidade da Carga de Trabalho	Habilitado	Substitui a identidade do pod, integra com o Microsoft Entra ID
Azure Policy complemento	Habilitado	Guardrails livres (sem contêineres privilegiados, rótulos necessários)
Insights do contêiner	Habilitado	Métricas e logs de primeira classe no Azure Monitor
Cluster privado	Ativado para produção	Plano de controle acessível somente da VNet

Registro de Contêiner do Azure

Independentemente de qual plataforma de computação você escolher, armazene suas imagens em Registro de Contêiner do Azure. A camada Básica é suficiente para equipes em estágio inicial. Use um registro separado por ambiente (produção, preparo) se desejar isolamento rígido ou um único registro com repositórios separados e controle de acesso baseado em função, se desejar simplificar.

Plataforma de dados: relacional, documento, vetor, análise

As decisões da plataforma de dados são as mais propensas a serem permanentes. O esquema de dados que você lança no primeiro mês molda cada funcionalidade pelos dois anos seguintes. Escolha um padrão flexível o suficiente para crescer com o produto e resista à tentação de pré-escolher um banco de dados especializado para um recurso que você ainda não criou.

Sua carga de trabalho	Serviço de Azure padrão	Por que	Revisitar quando
Dados do aplicativo transacional (usuários, pedidos, conteúdo) com um esquema relacional conhecido	Banco de Dados do Azure para PostgreSQL (Servidor Flexível)	Ecossistema de extensão maduro, amplamente compreendido e forte (incluindo pgvector para inserções). A camada intermitível é barata o suficiente para desenvolvimento e preparo.	Padrões de escrita multirregional ou leitura em hiperescala. Considere Azure Cosmos DB para PostgreSQL.
Dados operacionais com esquema flexível, distribuição global, leituras previsíveis em milissegundos de um dígito	Azure Cosmos DB (API NoSQL)	Várias regiões por padrão. A camada sem servidor é barata o suficiente para começar. O design da partição é importante; leia as diretrizes da chave de partição antes de enviar.	Você está forçando junções relacionais por meio da camada de aplicativo. PostgreSQL provavelmente é a resposta certa.
Pesquise em conteúdo estruturado e não estruturado, incluindo geração aumentada por recuperação	Pesquisa de IA do Azure	Palavra-chave híbrida e pesquisa de vetor. Integra-se ao Serviço OpenAI do Azure e ao Cosmos DB. Existe uma camada gratuita para criação de protótipos.	Você excede os limites de índice por camada (Standard 1 é um ponto de atualização comum).
Inserções de vetor para um recurso de geração aumentada de recuperação	Comece com pgvector no PostgreSQL ou Pesquisa de IA do Azure	Evite um banco de dados vetor separado para a primeira versão de um recurso de recuperação. Você aprenderá aquilo de que realmente precisa (filtragem, pesquisa híbrida, escalabilidade) com o uso real.	Você caracterizou seus padrões de leitura e as restrições justificam um mecanismo especializado.
Análise, relatórios e consultas ad hoc sobre dados de produção	Banco de Dados do Azure para PostgreSQL réplica de leitura (Explorar), Microsoft Fabric (Expandir e Extrair)	Uma réplica de leitura é suficiente para a maioria das análises na fase de exploração. Microsoft Fabric é a plataforma moderna de análise quando isso já não atende mais às suas necessidades.	Suas réplicas de leitura não conseguem acompanhar, ou as partes interessadas do negócio precisam de uma plataforma de análises de autoatendimento.
Camada de cache na frente de um banco de dados	Cache do Azure para Redis (camada básica)	Primitivo de cache padrão. Barato para adicionar mais tarde; não adicione especulativamente.	Você vê um claro padrão de leituras intensas que está sobrecarregando o banco de dados. Meça antes de adicionar.

Importante

Escolha um banco de dados padrão e permaneça nele o máximo que puder. Uma equipe de quinze engenheiros que opera PostgreSQL, Cosmos DB, Redis, AI Search, um sistema de filas e um banco de dados em grafo acabou assumindo, sem querer, uma carga de trabalho equivalente à de uma equipe de plataforma.

Onde Serviço OpenAI do Azure se encaixa

Serviço OpenAI do Azure não é uma plataforma de dados, mas compartilha o mesmo ritmo de decisão. A maioria das startups que criam uma funcionalidade de IA generativa começa com a implantação de um modelo (um modelo recente de conclusão de chat) em uma única região, além de Busca de IA ou pgvector para recuperação de informações. Você não precisa de um pipeline de ajuste fino dedicado, de um gateway de modelos nem de múltiplas implantações até que o uso indique a necessidade de adicioná-los.

O que este artigo aborda (e o que ele não aborda)

Tópico	Neste artigo	Quando adicionar
Gerenciamento de identidade e acesso além das noções básicas	No	Primeiro dia de configuração do Microsoft Entra ID. Acesso condicional e gerenciamento de identidades privilegiadas quando há uma revisão de segurança da informação.
Infraestrutura como código (Bicep, Terraform)	No	Quando as alterações manuais no portal começam a divergir de um ambiente para outro. Normalmente, na hora em que você adiciona o preparo.
Pipelines de integração contínua e de implantação contínua	No	Dia 1º. GitHub Actions ou Azure DevOps Pipelines estão bem.
Observabilidade (logs, métricas, rastreamentos)	No	Application Insights desde o primeiro dia. Azure Monitor pastas de trabalho quando você tem fadiga de alerta.
Gerenciamento de custos	No	Defina um orçamento em nível de assinatura no primeiro dia. Adicione tags aos recursos com o ambiente e o proprietário desde o início.
Conformidade (SOC 2, ISO 27001, HIPAA)	No	Quando um cliente pergunta. Microsoft Defender para Nuvem tem um painel de conformidade que mapeia controles para Azure recursos.
Recuperação de desastre e várias regiões	No	Quando o custo de uma hora de indisponibilidade excede o custo de engenharia da segunda região.

Quando os padrões da plataforma não são mais suficientes

Esses indicadores de crescimento indicam que uma configuração padrão específica precisa de uma substituição mais intencional:

Você implantou mais de cinco serviços distintos no App Service ou no Container Apps, e o dimensionamento de cada serviço está se tornando uma preocupação diária. Veja o Serviço de Kubernetes do Azure.
Sua fatura de Azure mensal está crescendo mais rápido do que sua receita mensal por dois meses seguidos. Hora de uma análise do Gerenciamento de Custos e da Instância Reservada ou da Análise do Plano de Poupança.
Sua rede virtual agora abrange várias assinaturas ou regiões. Veja o WAN Virtual do Azure e a topologia hub-and-spoke.
Uma única instância do PostgreSQL não consegue manter seu conjunto de dados de trabalho na memória, e as réplicas de leitura não resolvem o problema. Examine o Cosmos DB para PostgreSQL ou uma arquitetura fragmentada.
As consultas de análise no banco de dados de produção estão afetando visivelmente a latência do aplicativo. Mover a análise para Microsoft Fabric.
Você está executando mais de duas contas de armazenamento por ambiente para o mesmo padrão de acesso. Consolidar.
Você adicionou um terceiro país com clientes pagantes. É hora de avaliar uma segunda região, armazenamento com redundância geográfica e uma estratégia de roteamento do Front Door.