Fundamentos da Plataforma Azure para Startups

Este artigo apresenta uma rápida orientação com uma perspetiva de startup em cinco pilares fundamentais da plataforma: computação, redes, armazenamento, contentores e dados. Para cada pilar, encontra uma pequena tabela de decisão que mapeia a sua situação para um serviço predefinido, além de uma nota sobre quando deve rever essa escolha à medida que a sua startup cresce.

Neste artigo, aprende como

Escolha as primitivas de computação, redes e armazenamento Azure certas para o seu nível.
Decida se o Azure Kubernetes Service é a plataforma de contentores certa para a sua fase e, caso não seja, o que utilizar em alternativa.
Escolha uma primeira plataforma de dados para cargas de trabalho relacionais, documentais, vetoriais e analíticas.
Aplique um pequeno conjunto de padrões de custo, fiabilidade e segurança que se mantenham à medida que cresce.
Reconheça os sinais que indicam que uma escolha padrão já não é útil.

Pré-requisitos

Uma assinatura ativa do Azure.
A CLI do Azure está instalada e tem sessão iniciada. Para iniciar sessão, execute az login.
Acesso do Proprietário ou Contribuinte a pelo menos um grupo de recursos.
Familiaridade com a página de destino do portal do Azure é útil, mas não obrigatória.
Familiaridade básica com os fundamentos do Azure (regiões, subscrições e grupos de recursos).

Por que isto é importante para startups

Numa startup em fase inicial, o custo de uma má escolha de infraestrutura não é a fatura. É a semana que perdes a migrar para longe do serviço errado, depois de teres desenvolvido tudo em torno dele. Os cinco pilares deste artigo são aqueles em que um padrão mal escolhido tende a acumular-se: a plataforma de computação errada molda o seu pipeline de implementação; a base de dados errada limita o seu modelo de dados; A topologia de rede errada bloqueia o seu primeiro cliente empresarial. Não precisa de uma equipa de plataforma, de um engenheiro de fiabilidade do local ou de um especialista em operações financeiras para tomar estas decisões de forma eficaz. É necessária uma opção predefinida suficientemente boa para lançar, e um sinal claro que indique quando é preciso revê-la. Se a sua startup estiver no programa Microsoft for Startups, as mesmas predefinições fazem com que os seus créditos durem mais e mantêm a sua elegibilidade para benefícios avançados posteriormente.

Computar: onde o seu código corre

O 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 fase inicial, três delas cobrem o que precisas.

A sua situação	Serviço padrão do Azure	Porquê	Revisitar quando
Aplicação web ou API HTTP, um ou dois serviços, queres um tempo de execução gerido	Serviço de Aplicações do Azure (Linux)	Não é necessário construir um contentor. TLS incorporado, domínios personalizados, espaços de implementação e autoescalabilidade. Os níveis gratuitos e básicos são suficientemente baratos para gerir um ambiente de staging, embora os slots e a autoscala exijam Standard ou superior.	Pretende executar mais do que alguns serviços, precisa de escalabilidade por serviço ou precisa de sidecars.
Função orientada a eventos, trabalho agendado ou manipulador de webhook	Funções do Azure (Plano de consumo)	Pagamento por execução. Escala até zero. Os bindings removem a maior parte do código de colagem para filas, blobs e triggers HTTP.	Os arranques a frio prejudicam a latência percebida pelo utilizador ou excedem os limites do plano de Consumo.
Microserviços containerizados, queres um runtime opinativo sem gerir Kubernetes	Aplicativos de contêiner do Azure	Baseado em Kubernetes, com escalabilidade automática baseada em KEDA, mas não tens de gerir o cluster. O Dapr está disponível como integração opcional. Escalonamento para zero, revisões e ingresso HTTPS incluídos.	Precisas de controlo ao nível do cluster, um agendador personalizado ou redes avançadas.
Processamento em lote de longa duração, treino em GPU ou lift-and-shift de uma carga de trabalho existente de máquina virtual	Máquinas Virtuais do Azure	Controlo total do sistema operativo. Usa um conjunto de escala de máquina virtual quando precisares de escala horizontal.	A sobrecarga operacional da aplicação de patches e da gestão de imagens começa a atrasar o lançamento.
Tens a certeza de que precisas do Kubernetes (vê a secção 4 antes de assumires isto)	Serviço Kubernetes do Azure	Avião de controlo gerido. Adequa-se a equipas que já tenham experiência em Kubernetes ou requisitos específicos de plataforma.	Consulte a secção de Contentores para os critérios de decisão do AKS.

Sugestão

Comece com o App Service para a sua primeira aplicação web voltada para o utilizador e com o Funções do Azure para tudo o que envolve eventos. Podes mudar para Azure Container Apps ou Azure Kubernetes Service mais tarde sem alterar o código da tua aplicação, se mantiveres a aplicação sem estado e escreveres a configuração para variáveis de ambiente.

Escolher entre Container Apps e App Service

Aplicações Container e App Service sobrepõem-se. O critério de desempate honesto: se a tua aplicação já corre como uma imagem de contentor e quiseres escala por serviço (réplicas diferentes para a camada web em comparação com o trabalhador), as Aplicações Container ganham. Se a sua aplicação for um único processo web e não quiser manter um Dockerfile, a App Service vence.

Atenção

Considere o Azure Kubernetes Service quando tem requisitos claros que não são cumpridos por opções mais simples. Embora ofereça grande flexibilidade e controlo, também introduz considerações operacionais adicionais (como atualizações, dimensionamento de pools de nós, configuração de entrada e gestão de certificados). Se adotado demasiado cedo, as equipas muitas vezes dedicam mais tempo à gestão da plataforma do que à construção de funcionalidades do produto.

Networking: o que configurar no primeiro dia

A maioria das cargas de trabalho do Azure em fase inicial não precisa de uma rede virtual no primeiro dia. App Service, Functions, Container Apps e a maioria das bases de dados geridas dão-te endpoints públicos com TLS que são seguros para expor, desde que definas a autenticação corretamente. Adicionar complexidade de rede antes de ter uma razão é a otimização prematura mais comum no Azure.

A sua situação	Abordagem padrão	Porquê	Revisitar quando
Aplicação nova, tráfego web público, ainda sem requisitos de conformidade	Utilize o endpoint público utilizando TLS. Sem rede virtual.	Menor sobrecarga operacional. O App Service, o Container Apps e as bases de dados geridas gerem o TLS por si. Use Microsoft Entra ID para autenticação.	O seu primeiro cliente empresarial pede conectividade privada.
Precisa de uma ligação privada entre a sua aplicação e uma base de dados gerida	Integração com rede virtual no lado de computação, endpoint privado no lado da base de dados	O tráfego permanece na rede principal da Microsoft. Sem exposição pública para a base de dados. Mesmo serviço gerido, sem alterações na aplicação.	No primeiro dia, se lidares com dados protegidos; caso contrário, quando uma auditoria ou cliente pergunta.
Precisas de um único ponto de entrada público que antecipe múltiplos back-ends com roteamento, terminação TLS e um firewall para aplicações web	Azure Front Door (global) ou Gateway de Aplicação do Azure (regional)	O Front Door adiciona uma rede global de distribuição de conteúdos e cache na borda. O Application Gateway é a opção regional, nativa da rede virtual.	Já superaste o TLS e o encaminhamento incorporados do App Service.
Precisas de endereços IP estáticos de saída (uma lista de permissão de processadores de pagamentos, por exemplo)	Gateway NAT ligado à sua rede virtual	IP de saída previsível. Exigido por muitas APIs de terceiros.	Um fornecedor exige isso. Não o adicione por especulação.
Topologia multi-região ou multi-conta	Emparelhamento de rede virtual ou WAN Virtual do Azure	A verdadeira arquitetura de rede começa aqui. Fora do alcance da maioria das equipas na fase de exploração.	Multirregião é um requisito real, não uma aspiração.

Importante

Bloqueie Microsoft Entra ID e as atribuições de funções por subscrição antes de se preocupar com o isolamento da rede. A maioria dos incidentes de segurança no Azure em pequenas empresas resulta de uma identidade com excesso de permissões, não de uma exposição de rede. Utilize os grupos do Microsoft Entra ID para acesso de engenharia, e não atribua a função Owner ao nível da subscrição.

Armazenamento: blobs, ficheiros e discos

Armazenamento do Azure é um único tipo de recurso (a conta de armazenamento) que expõe quatro serviços de dados: blobs, ficheiros, filas e tabelas. Para decisões de armazenamento de aplicações, está quase sempre a escolher entre blobs (armazenamento de objetos), ficheiros (partilhas de ficheiros geridas) e discos geridos (armazenamento em blocos ligados a uma máquina virtual).

O que estás a guardar	Serviço padrão do Azure	Porquê	Revisitar quando
Ficheiros carregados pelos utilizadores, relatórios gerados, registos, artefactos de modelos, backups	Armazenamento de Blobs do Azure (tier quente)	Armazenamento de objetos. Económico, durável, expansível até petabytes. Utiliza as camadas cool ou archive posteriormente para dados a que não acedes com frequência.	Precisas de semântica de ficheiro POSIX ou leitura-escrita aleatória num único ficheiro a partir de várias máquinas.
Um sistema de ficheiros partilhado montado por múltiplas máquinas virtuais ou contentores	Ficheiros do Azure (Padrão) ou Azure NetApp Files (alto rendimento)	Volumes partilhados de Server Message Block (SMB) ou Network File System (NFS). Evite usar estes para conteúdos que se enquadrem no modelo de blob.	Começas a usar uma partilha de ficheiros como fila ou base de dados. Desloca-te para o primitivo correto.
Discos para uma máquina virtual	Discos geridos SSD Premium v2	Desempenho ajustável, bom custo-benefício para discos de aplicação. O SSD premium v2 não pode ser usado como disco do sistema operativo; emparelhá-lo com o SSD Premium (v1) ou o SSD Standard para o sistema operativo. SSD padrão é aceitável para cargas de trabalho de baixo rendimento.	Precisas de armazenamento partilhado em blocos entre máquinas virtuais (usa Azure Elastic SAN ou Azure NetApp Files).
Ativos estáticos de websites (pacote de aplicação de página única, site de marketing, documentação)	Armazenamento do Azure alojamento de sites estáticos + Azure Front Door	Aplicações Web Estáticas é o padrão moderno: domínios personalizados incorporados, TLS gerido gratuito, distribuição global, GitHub Actions CI/CD e autenticação incorporada. Storage static website + Front Door ainda funciona para configurações de baixo custo, mas não suporta nativamente cabeçalhos personalizados ou autenticação.	Adiciona-se páginas renderizadas pelo servidor. Mude para App Service ou Container Apps.

Note

As contas de armazenamento têm um limite suave de 250 por região por subscrição (aumentando para 500 mediante pedido). Isso é mais do que suficiente para equipas em fase inicial. O erro a evitar é criar uma conta de armazenamento por microserviço; agrupar por ambiente (produção, staging, desenvolvimento) e por padrão de acesso (quente, frio, arquivo) em vez disso.

Uma nota sobre cópias de segurança

Azure Backup e as opções de redundância de conta de armazenamento (Armazenamento Redundante Localmente, Armazenamento Redundante de Zona, Armazenamento Geo Redundante) são ajustáveis por conta e por disco. O Armazenamento com Redundância Local (LRS) é adequado para o desenvolvimento e teste. Use o Armazenamento Redundante por Zona (ZRS) para dados de produção. Geo Redundant Storage acrescenta custos e não substitui a recuperação de desastres a nível de aplicação.

Contentores e Azure Kubernetes Service

O Azure tem três formas de executar containers em produção: Azure Container Apps, Azure Container Instances e Azure Kubernetes Service. Correspondem a diferentes tamanhos de equipas e apetites operacionais.

A sua situação	Serviço padrão do Azure	Porquê	Quando começa a doer
Tem imagens de contentores e pretende um ambiente de execução gerido com ingresso HTTPS, escala até zero e revisões	Aplicativos de contêiner do Azure	Plataforma serverless no Kubernetes com escalabilidade automática KEDA, mas não vês nem geres o cluster. Paga pelo que corre. É bom encaixe até atingires os requisitos de cluster. O Dapr está disponível como uma integração opcional.	Precisas de agendadores personalizados, redes avançadas (múltiplas placas de interface de rede, plugins personalizados de Interface de Rede de Containers) ou operadores Kubernetes específicos.
Pretende executar um único contentor como uma tarefa pontual ou um processamento em lote de curta duração	Instâncias de contêiner do Azure	O caminho mais rápido da imagem para o contentor em execução. Sem orquestração. Cobrado por segundo de execução.	Precisas de algo que se assemelhe a uma malha de serviço ou autoscaling para além de um único contentor.
Já operas Kubernetes noutro lado, ou a arquitetura da tua aplicação realmente o exige	Serviço Kubernetes do Azure	Avião de controlo gerido. Traz os teus próprios pools de nós, plugin de rede, controlador de entrada e pilha de observabilidade.	Primeiro dia. Planeie atualizações contínuas (versão menor lançada a cada 4 meses), afinação do pool de nós e gestão de certificados.
Não tens a certeza se precisas do Kubernetes	Container Apps por enquanto	Podes reconstruir no Azure Kubernetes Service mais tarde, se necessário. Levantar uma aplicação conteinerizada sem estado dá dias de trabalho, não semanas.	Tem uma necessidade concreta (ecossistema de operadores, política ao nível do cluster) que consegue identificar. "Preparar o futuro" não é uma necessidade concreta.

Quando passar para a AKS

Passe para Azure Kubernetes Service (AKS) quando pelo menos duas destas situações são verdadeiras:

Geres mais de dez serviços com um ciclo de vida partilhado e necessidades de rede comuns.
Precisa de controladores personalizados, sidecars ou Definições de Recursos Personalizadas (CRDs) que o Container Apps não expõe.
É necessário uma integração profunda de redes virtuais com aplicação rigorosa das políticas.
Estás a padronizar num ecossistema open source baseado em Kubernetes (Argo, Istio, KEDA, e assim por diante).

Se adotares o AKS, segue a arquitetura AKS Baseline. O Microsoft Azure Well-Architected Framework e a referência AKS Baseline cobrem juntos os padrões de segurança, escalabilidade e atualização que pretendes.

O AKS é predefinido para uma equipa pequena

Setting	Predefinido	Porquê
Tamanho do nó	conjunto do sistema Standard_D4s_v5, conjunto de utilizadores Standard_D8s_v5	Preço-desempenho previsível para cargas de trabalho gerais
Escalador automático de cluster	Ativado	Evite pagar por nós ociosos
Identidade da carga de trabalho	Ativado	Substitui a identidade do pod, integra-se com o Microsoft Entra ID
Suplemento do Azure Policy	Ativado	Barreiras de proteção gratuitas (sem contentores privilegiados, etiquetas obrigatórias)
Informações sobre contêineres	Ativado	Métricas e logs de primeira classe no Azure Monitor
Cluster privado	Em produção	Plano de controlo acessível apenas a partir do VNet

Azure Container Registry

Independentemente da plataforma de computação que escolheres, guarda as tuas imagens em Azure Container Registry. O nível Básico é suficiente para equipas em fase inicial. Use um registo separado por ambiente (produção, staging) se quiser isolamento total, ou um registo único com repositórios separados e controlo de acesso baseado em funções se quiser simplicidade.

Plataforma de dados: relacional, documento, vetorial, analítica

As decisões da plataforma de dados são as que mais provavelmente serão permanentes. O esquema que envias no primeiro mês molda todas as funcionalidades para os próximos dois anos. Escolha um padrão suficientemente flexível para crescer com o produto e resista à tentação de pré-selecionar uma base de dados especializada para uma funcionalidade que ainda não desenvolveu.

A tua carga de trabalho	Serviço padrão do Azure	Porquê	Revisitar quando
Dados transacionais de aplicação (utilizadores, encomendas, conteúdo) com um esquema relacional conhecido	Base de Dados do Azure para PostgreSQL (Servidor Flexível)	Ecossistema de extensões maduro, amplamente conhecido e robusto (incluindo o pgvector para embeddings). O nível Burstable é suficientemente barato para desenvolvimento e preparação.	Padrões de escrita multirregional ou de leitura à hiperescala. Considere Azure Cosmos DB para PostgreSQL.
Dados operacionais com flexibilidade em esquema, distribuição global, leituras previsíveis de um dígito em milissegundos	Azure Cosmos DB (API NoSQL)	Multirregional por defeito. O nível serverless é barato o suficiente para começar. O design da partição é importante; Leia as orientações sobre chaves de partição antes de enviar.	Estás a forçar junções relacionais na camada da aplicação. PostgreSQL é provavelmente a resposta certa.
Pesquise em conteúdos estruturados e não estruturados, incluindo geração aumentada por recuperação	Pesquisa de IA do Azure	Pesquisa híbrida por palavras-chave e vetorial. Integra com Azure OpenAI Service e Cosmos DB. Existe um plano gratuito para prototipagem.	Ultrapassa os limites de índice por nível (o Standard 1 é um ponto comum de upgrade).
Representações vetoriais para um recurso de geração aumentada com recuperação	Comece com pgvector no PostgreSQL ou Pesquisa de IA do Azure	Evite uma base de dados vetorial separada para a primeira versão de uma funcionalidade de recuperação. Vais aprender o que realmente precisas (filtragem, pesquisa híbrida, escala) através do uso real.	Caracterizaste os teus padrões de leitura e as limitações justificam um motor especializado.
Análises, relatórios e consultas ad hoc sobre dados de produção	Base de Dados do Azure para PostgreSQL ler réplica (Explorar), Microsoft Fabric (Expandir e Extrair)	Uma réplica de leitura é suficiente para a maioria das análises da fase Explore. A Microsoft Fabric é a plataforma moderna de análise quando ultrapassares isso.	As suas réplicas de leitura não conseguem acompanhar, ou os intervenientes do negócio precisam de uma superfície analítica de autoatendimento.
Camada de cache em frente a uma base de dados	Cache do Azure para Redis (Nível básico)	Primitivo de cache padrão. Barato de acrescentar mais tarde; Não acrescentes de forma especulativa.	Vê-se um padrão claro de leitura quente que está a saturar a base de dados. Medir antes de acrescentar.

Importante

Escolha uma base de dados predefinida e mantenha-se com ela durante o máximo de tempo possível. Uma equipa de quinze engenheiros que opera PostgreSQL, Cosmos DB, Redis, AI Search, uma fila de mensagens e uma base de dados de grafos acabou, sem querer, por criar trabalho suficiente para uma equipa de plataforma.

Onde se encaixa o Azure OpenAI Service

O Azure OpenAI Service não é uma plataforma de dados, mas partilha o mesmo ritmo de decisão. A maioria das startups que criam uma funcionalidade de IA generativa começa com a implementação de um único modelo (um modelo recente de completamento de chat) numa única região, bem como o AI Search ou o pgvector para recuperação de informação. Não precisas de um pipeline dedicado de ajuste fino, um gateway modelo, ou múltiplas implementações até que o uso te diga para as adicionar.

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

Topic	Neste artigo	Quando o adicionar
Gestão de identidade e acessos para além do básico	No	Dia um para a configuração do Microsoft Entra ID. Acesso condicional e Privileged Identity Management quando existe uma revisão da segurança da informação.
Infraestrutura como Código (Bicep, Terraform)	No	Quando as mudanças manuais do portal começam a flutuar entre ambientes. Normalmente é por volta da altura em que se adiciona a encenação.
Pipelines de integração contínua e implementação contínua	No	Primeiro dia. O GitHub Actions ou o Azure DevOps Pipelines são ambos aceitáveis.
Observabilidade (logs, métricas, rastreios)	No	Application Insights desde o primeiro dia. Azure Monitor workbooks quando tens fadiga de alerta.
Gestão de custos	No	Defina um orçamento de subscrição no primeiro dia. Identifica os recursos com o ambiente e o proprietário desde o início.
Conformidade (SOC 2, ISO 27001, HIPAA)	No	Quando um cliente pergunta. O Microsoft Defender para a Cloud tem um painel de conformidade que mapeia os controlos para recursos do Azure.
Recuperação de desastres e multi-região	No	Quando o custo de uma hora de inatividade excede os custos de engenharia da segunda região.

Quando as predefinições da plataforma deixam de ser suficientes

Estes sinais de crescimento indicam que um padrão específico precisa de uma substituição mais deliberada:

Já implementou mais de cinco serviços distintos no App Service ou no Container Apps e o dimensionamento por serviço está a tornar-se uma preocupação diária. Veja o Azure Kubernetes Service.
A sua fatura mensal do Azure está a crescer mais rápido do que a sua receita mensal durante dois meses consecutivos. Tempo para uma revisão da Gestão de Custos e uma análise de Instância Reservada ou Plano de Poupança.
A sua rede virtual agora abrange múltiplas subscrições ou regiões. Observe o WAN Virtual do Azure e a topologia hub-and-spoke.
Uma única instância do PostgreSQL não consegue manter o seu conjunto de trabalho em memória, e as réplicas de leitura não colmatam essa lacuna. Considere o Cosmos DB para PostgreSQL ou uma arquitetura fragmentada.
As consultas analíticas na base de dados de produção estão a afetar visivelmente a latência da aplicação. Transferir a análise para o Microsoft Fabric.
Estás a usar mais de duas contas de armazenamento por ambiente para o mesmo padrão de acesso. Consolidar.
Adicionaram um terceiro país com clientes pagantes. Hora de avaliar uma segunda região, armazenamento geo-redundante e uma estratégia de roteamento Front Door.