O Sertão será Cloud

Hello, Sertão!

Fri, 24 Apr 2026 00:00:00 GMT

Do Sertão para a nuvem. Este é o primeiro post do blog — um marcador de que a plataforma está funcionando.

O que vem por aí

Tutoriais, análises e opinião sobre cloud computing, tudo em PT-BR. Pipeline de sync dev.to → tradução automática → PR editorial → publicação chega na Fase 2.

Feito com ☁ — sertaoseracloud

Event-Driven Architecture on Azure vs AWS: Service Bus vs SNS/SQS

Tue, 21 Apr 2026 00:00:00 GMT

Seu OrderService faz seis coisas quando o cliente clica em Place Order. Ele escreve na tabela de pedidos, reserva estoque, cobra o cartão, enfileira a etiqueta de envio, envia o recibo por e‑mail e registra o evento de análise. Tudo isso ocorre dentro de um único handler HTTP, em uma transação, em um único servidor. Quando o gateway de pagamento hesita, o pedido falha. Quando o provedor de e‑mail limita a taxa, o pedido falha. Quando o estoque está lento, o pedido falha. O monólito amarrou seis domínios de falha independentes a um destino compartilhado.

Este artigo reconstrói esse pipeline como um sistema orientado a eventos tanto no Azure quanto na AWS, e detalha onde eles diferem genuinamente — não onde se parecem superficialmente. O cenário de referência é o processamento de pedidos de e‑commerce com fan‑out para Inventário, Pagamento e Notificação. Público‑alvo: engenheiros intermediários a sêniores que já leram as páginas de vendas dos fornecedores e querem as partes que essas páginas omitem.

O padrão antes dos produtos

Antes de nomear qualquer serviço de nuvem, defina o formato. O que você quer é publicar/assinar com fan‑out durável, com filas por consumidor e filas de dead‑letter por consumidor. O produtor emite um evento lógico — OrderPlaced — para um tópico. O tópico entrega uma cópia para uma fila durável por consumidor. Cada consumidor esvazia sua própria fila no seu ritmo, tenta novamente em sua própria agenda e, quando desiste, a mensagem cai em sua própria DLQ — não em uma compartilhada.

Essa última parte importa. Uma DLQ compartilhada significa que uma mensagem envenenada de inventário bloqueia a equipe de pagamento de ver seu próprio veneno. Uma fila por consumidor, uma DLQ por consumidor, um orçamento de retry por consumidor. O raio de impacto de qualquer mensagem ruim é exatamente um contexto limitado.

Com o formato definido, podemos mapeá‑lo para duas nuvens — uma preocupação de cada vez.

Lado a lado, uma preocupação de cada vez

Modelo de tópico e assinatura

Na AWS o tópico e as filas são primitivas separadas. SNS publica; SQS armazena. Você os conecta com uma assinatura de tópico e uma política de fila. A fila mantém suas mensagens; o tópico apenas as espalha. Dois tipos de recurso por consumidor.

No Azure o Service Bus colapsa isso em um único grafo de recursos. Um namespace contém um tópico, e cada consumidor é uma assinatura nesse tópico. A assinatura tem uma fila virtual atrás dela; você não gerencia um recurso de fila separado. Menos partes móveis na camada de IaC, mas menor separação de preocupações — o tópico e seus assinantes compartilham um ciclo de vida e uma unidade de faturamento.

Semântica de fila e DLQ

Ambos os brokers são at‑least‑once. Consumidores verão duplicatas. Nenhum slide de marketing muda isso.

A AWS emparelha cada fila SQS com uma DLQ explícita via política de redrive. maxReceiveCount é o limiar; a fila principal mantém a mensagem em voo até que o consumidor a exclua explicitamente, controlada por visibility_timeout_seconds. Esse timeout de visibilidade deve exceder a latência P99 do handler, com margem. Defina‑o muito baixo e o broker redistribui enquanto o primeiro handler ainda está trabalhando — você obtém dois handlers concorrentes correndo, e a idempotência torna‑se essencial de uma forma que você provavelmente não testou.

O Azure Service Bus incorpora a DLQ em cada assinatura como $DeadLetterQueue. maxDeliveryCount desempenha o mesmo papel que maxReceiveCount. O Service Bus também envia para dead‑letter em duas classes de falha que o SQS não conhece: expiração de TTL da mensagem e exceções de avaliação de filtro. Esses dois gatilhos extra de DLQ são vitórias operacionais reais — mensagens expiradas ou malformadas não desaparecem nas métricas.

Uma afirmação comum que vale a pena reconsiderar: Service Bus oferece entrega exactly‑once. Não oferece. O que ele oferece é detecção de duplicatas dentro de uma janela limitada (até sete dias) com base em MessageId por mensagem. Isso é uma ajuda do lado do broker, não uma garantia semântica. Consumidores ainda devem ser idempotentes. Mesma história no SQS FIFO e sua janela de dedup baseada em conteúdo de cinco minutos.

Identidade e auth do plano de dados

Na AWS, consumidores assumem uma função IAM do Lambda, ECS ou EKS. Sem chaves de acesso, sem credenciais de usuário na configuração. A política de fila restringe remetentes a um ARN de tópico específico via uma condição aws:SourceArn — sem isso, qualquer tópico SNS na sua conta pode escrever na sua fila. Essa é a clássica armadilha de confused‑deputy, e deixar a condição desligada é um dos gatilhos de rejeição mais comuns em uma revisão real.

No Azure, o equivalente a "sem chaves de longa duração" é disableLocalAuth: true no namespace, o que elimina totalmente a autenticação SAS. Toda a autenticação passa pelo AAD e Identidade Gerenciada. A função correta é Service Bus Data Receiver com escopo por assinatura, não em todo o namespace. Escritores obtêm Service Bus Data Sender no tópico. Escopar no nível de assinatura significa que um consumidor de notificação comprometido não pode ler eventos de pagamento — o movimento lateral é limitado pelo escopo RBAC.

Ordenação

Ambas as plataformas podem fazer ordenação. Nenhuma deve fazer ordenação por padrão.

Na AWS, ordenação significa filas FIFO chaveadas por MessageGroupId. O limite é 300 mensagens/seg (3.000 com batching) por fila. Esse é um teto rígido, não um limitador suave.

No Azure, ordenação significa SessionId nas mensagens e requiresSession: true na assinatura. A ordem é preservada por sessão. O throughput é bom no Standard; o particionamento no Premium empurra‑o mais alto. O custo é que o pinamento de sessão serializa uma assinatura — um consumidor lento em uma sessão paralisa mensagens nessa sessão até que o bloqueio seja liberado.

Se o domínio não exige ordem estrita, não a habilite. FIFO é uma decisão de negócios, não um padrão arquitetural.

A matriz de trade‑offs

Este é o centro do artigo, não o fechamento. Se você lembrar de uma coisa, lembre‑se desta tabela.

Dimensão	AWS SNS + SQS	Azure Service Bus (Standard / Premium)
Modelo primitivo	Tópico (SNS) espalha para filas SQS separadas — dois tipos de recurso por consumidor	Único namespace → tópico → assinatura — um único grafo de recursos
Modelo de custo	Pagamento por requisição tanto em publicações SNS quanto em requisições SQS; sem custo ocioso	Standard: pagamento por milhão de operações + hora de namespace. Premium: unidades de mensagens fixas (piso previsível ≈ $670/MU/mês no momento da escrita; verifique o preço atual de SKU, ele deriva)
Ordenação de mensagens	Standard: nenhuma. FIFO: ordenação estrita por `MessageGroupId`, limitada a 300 msgs/s (3.000 com batching)	Standard: ordenação dentro de uma sessão (`SessionId`). Premium: mesmo, maior throughput, suporte a particionamento
Semântica de entrega	At‑least‑once. FIFO adiciona dedup baseada em conteúdo em uma janela de 5 minutos	At‑least‑once. PeekLock + detecção de duplicatas até 7 dias. Ajuda do lado do broker; ainda exige consumidores idempotentes
Tamanho máximo de mensagem	256 KB tanto no SNS quanto no SQS. Solução alternativa: claim‑check via S3 + SQS Extended Client	Standard: 256 KB. Premium: 100 MB nativo
Tratamento de DLQ	Fila SQS explícita + política de redrive. Limiar `maxReceiveCount`. DLQ apenas para falhas de entrega	`$DeadLetterQueue` implícita por assinatura. Limiar `maxDeliveryCount`. Também DLQs em expiração de TTL e erros de avaliação de filtro
Filtragem	Políticas de filtro SNS: correspondência de atributos JSON no momento da assinatura	Filtro SQL e filtro de correlação por assinatura — modelo de expressão mais rico
Superfície de ops	CloudWatch: `ApproximateNumberOfMessages`, `ApproximateAgeOfOldestMessage`. Alarme em profundidade de DLQ > 0	Azure Monitor: `ActiveMessages`, `DeadletteredMessages`. Alarme em `DeadletteredMessages > 0`
Identidade	Funções IAM assumidas por Lambda/ECS/EKS; SSE‑KMS	AAD + Identidade Gerenciada; `disableLocalAuth=true` elimina SAS
Isolamento de rede	VPC Endpoints (Interface para SNS, Interface/Gateway para SQS)	Private Endpoint (SKU Premium para integração VNet completa)
Throughput	SNS: milhões de msgs/s. SQS standard: efetivamente ilimitado. SQS FIFO: 300–3.000 msgs/s por fila	Standard: ~2.000 msgs/s por namespace como diretriz de trabalho. Premium: escala com unidades de mensagens (~1.000 msgs/s por MU)

Heurística de uma linha: Se a carga de trabalho exige mensagens > 256 KB, ordenação forte com alto throughput, ou isolamento VNet com ordenação, o Service Bus Premium justifica seu custo. Caso contrário — fan‑out massivo, consumidores idempotentes, faturamento por requisição — SNS + SQS vence. O Service Bus Standard é a linha de base; o Premium é um upgrade que você justifica, não um padrão.

O IaC — AWS

Terraform de nível de produção. Tags de FinOps, SSE, políticas de redrive e uma condição aws:SourceArn na política de fila. Mantenha tudo isso — cada linha carrega uma propriedade de segurança ou confiabilidade da qual o cluster depende.

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40"
    }
  }
}

variable "project"        { type = string }
variable "environment"    { type = string }               # dev | stg | prd
variable "aws_region"     { type = string  default = "us-east-1" }
variable "consumers" {
  description = "Logical consumers that subscribe to the OrderPlaced topic."
  type        = set(string)
  default     = ["inventory", "payment", "notification"]
}
variable "max_receive_count" { type = number default = 5 } # redrive threshold

locals {
  name_prefix = "${var.project}-${var.environment}"
  tags = {
    Project     = var.project
    Environment = var.environment
    Workload    = "eda-orders"
    CostCenter  = "platform-events"
    ManagedBy   = "terraform"
  }
}

# --- Topic ----------------------------------------------------------------
resource "aws_sns_topic" "orders_placed" {
  name              = "${local.name_prefix}-orders-placed"
  kms_master_key_id = "alias/aws/sns"          # SSE at rest with AWS-managed CMK; swap to customer CMK for stricter tenants
  tags              = local.tags
}

# --- Queues + DLQs per consumer ------------------------------------------
resource "aws_sqs_queue" "dlq" {
  for_each                  = var.consumers
  name                      = "${local.name_prefix}-${each.key}-dlq"
  message_retention_seconds = 1209600            # 14 days - max allowed, buys ops time
  kms_master_key_id         = "alias/aws/sqs"
  tags = merge(local.tags, { Role = "dlq", Consumer = each.key })
}

resource "aws_sqs_queue" "main" {
  for_each                  = var.consumers
  name                      = "${local.name_prefix}-${each.key}"
  visibility_timeout_seconds = 60                 # must exceed consumer max processing time
  message_retention_seconds = 345600             # 4 days
  receive_wait_time_seconds = 20                 # long polling - reduces empty-receive cost
  kms_master_key_id         = "alias/aws/sqs"
  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.dlq[each.key].arn
    maxReceiveCount     = var.max_receive_count
  })
  tags = merge(local.tags, { Role = "main", Consumer = each.key })
}

# --- Allow SNS to write to SQS -------------------------------------------
data "aws_iam_policy_document" "sns_to_sqs" {
  for_each = var.consumers
  statement {
    sid     = "AllowSNSDeliver"
    effect  = "Allow"
    actions = ["sqs:SendMessage"]
    principals {
      type        = "Service"
      identifiers = ["sns.amazonaws.com"]
    }
    resources = [aws_sqs_queue.main[each.key].arn]
    condition {
      test     = "ArnEquals"
      variable = "aws:SourceArn"
      values   = [aws_sns_topic.orders_placed.arn]
    }
  }
}

resource "aws_sqs_queue_policy" "main" {
  for_each  = var.consumers
  queue_url = aws_sqs_queue.main[each.key].id
  policy    = data.aws_iam_policy_document.sns_to_sqs[each.key].json
}

resource "aws_sns_topic_subscription" "consumer" {
  for_each             = var.consumers
  topic_arn            = aws_sns_topic.orders_placed.arn
  protocol             = "sqs"
  endpoint             = aws_sqs_queue.main[each.key].arn
  raw_message_delivery = true                     # consumers parse the raw event, not the SNS envelope
}

# --- Consumer IAM role template (least-privilege) ------------------------
data "aws_iam_policy_document" "consumer_assume" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com", "ecs-tasks.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "consumer" {
  for_each           = var.consumers
  name               = "${local.name_prefix}-${each.key}-consumer"
  assume_role_policy = data.aws_iam_policy_document.consumer_assume.json
  tags               = merge(local.tags, { Consumer = each.key })
}

data "aws_iam_policy_document" "consumer_sqs" {
  for_each = var.consumers
  statement {
    actions = [
      "sqs:ReceiveMessage",
      "sqs:DeleteMessage",
      "sqs:GetQueueAttributes",
      "sqs:ChangeMessageVisibility",
    ]
    resources = [aws_sqs_queue.main[each.key].arn]
  }
}

resource "aws_iam_role_policy" "consumer_sqs" {
  for_each = var.consumers
  role     = aws_iam_role.consumer[each.key].id
  policy   = data.aws_iam_policy_document.consumer_sqs[each.key].json
}

output "topic_arn" { value = aws_sns_topic.orders_placed.arn }
output "queues"    { value = { for k, q in aws_sqs_queue.main : k => q.arn } }
output "dlqs"      { value = { for k, q in aws_sqs_queue.dlq  : k => q.arn } }

O IaC — Azure

Mesmo cenário, mesmas tags, mesmo maxDeliveryCount = 5. Note disableLocalAuth: true no namespace e RBAC por assinatura no final.

// Deployment scope: resourceGroup
targetScope = 'resourceGroup'

@description('Project short code, e.g. osecloud')
param project string

@allowed([ 'dev', 'stg', 'prd' ])
param environment string

@description('Azure region.')
param location string = resourceGroup().location

@description('Logical consumers that subscribe to the OrderPlaced topic.')
param consumers array = [ 'inventory', 'payment', 'notification' ]

@description('Consumer identity object IDs (managed identities that will receive Data Receiver role). Key must match a name in `consumers`.')
param consumerPrincipalIds object = {}

@description('Service Bus SKU. Use Premium when you need ordering at scale, VNet integration, or >1MB messages.')
@allowed([ 'Standard', 'Premium' ])
param skuName string = 'Standard'

var namePrefix = toLower('${project}-${environment}')
var tags = {
  project:     project
  environment: environment
  workload:    'eda-orders'
  costCenter:  'platform-events'
  managedBy:   'bicep'
}

// --- Namespace ------------------------------------------------------------
resource sbNamespace 'Microsoft.ServiceBus/namespaces@2022-10-01-preview' = {
  name:     '${namePrefix}-sb'
  location: location
  sku: {
    name: skuName
    tier: skuName
  }
  properties: {
    minimumTlsVersion: '1.2'
    publicNetworkAccess: 'Enabled' // set to 'Disabled' + private endpoint in prd
    disableLocalAuth: true         // force AAD/Managed Identity - no SAS keys
  }
  tags: tags
}

// --- Topic ----------------------------------------------------------------
resource topic 'Microsoft.ServiceBus/namespaces/topics@2022-10-01-preview' = {
  parent: sbNamespace
  name: 'orders-placed'
  properties: {
    defaultMessageTimeToLive: 'P14D'
    enableBatchedOperations: true
    supportOrdering: true          // preserves order within a session (partition) - only honoured with session-enabled subscriptions
  }
}

// --- Subscriptions + DLQ (DLQ is implicit per subscription) --------------
resource subs 'Microsoft.ServiceBus/namespaces/topics/subscriptions@2022-10-01-preview' = [for name in consumers: {
  parent: topic
  name:   '${name}-sub'
  properties: {
    deadLetteringOnMessageExpiration:    true
    deadLetteringOnFilterEvaluationExceptions: true
    maxDeliveryCount: 5             // redrive threshold → moves to $DeadLetterQueue
    lockDuration:     'PT1M'        // matches visibility-timeout in AWS terms
    defaultMessageTimeToLive: 'P4D'
    requiresSession: false          // set true for FIFO-per-session guarantees
  }
}]

// --- RBAC: Azure Service Bus Data Receiver on each subscription ----------
var dataReceiverRoleId = '4f6d3b9b-027b-4f4c-9142-0e5a2a2247e0' // Service Bus Data Receiver

resource rbacReceiver 'Microsoft.Authorization/roleAssignments@2022-04-01' = [for (name, i) in consumers: if (contains(consumerPrincipalIds, name)) {
  name:  guid(subs[i].id, consumerPrincipalIds[name], dataReceiverRoleId)
  scope: subs[i]
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', dataReceiverRoleId)
    principalId:      consumerPrincipalIds[name]
    principalType:    'ServicePrincipal'
  }
}]

output namespaceId       string = sbNamespace.id
output topicId           string = topic.id
output subscriptionNames array  = [for (name, i) in consumers: subs[i].name]

Um aviso sobre a versão da API: 2022-10-01-preview ainda é rotulada como preview no momento da escrita. Se sua equipe de plataforma proibe versões de API em preview em produção, fixe na última versão GA estável e re‑teste disableLocalAuth — seu comportamento mudou entre versões da API.

Sete restrições arquiteturais

Trate estas como critérios de aceitação para qualquer pipeline EDA que você entregar em qualquer nuvem. Elas são uma lista de verificação, não uma lista de desejos.

At‑least‑once é o padrão em ambos os lados. Exactly‑once é uma propriedade do consumidor — handlers idempotentes mais um armazenamento de dedup — não uma garantia do broker. Janelas do lado do broker (SQS FIFO 5 min, detecção de duplicatas do Service Bus até 7 dias) estreitam o problema; elas não o eliminam.
Timeout de visibilidade e duração de bloqueio devem exceder a latência P99 do handler. Se o broker redistribuir enquanto o primeiro handler ainda está trabalhando, você processa em duplicidade. Meça P99 sob carga, adicione margem e alerta quando a duração do handler se aproximar do timeout.
Ordenação é uma aposta que você paga. FIFO limita o throughput da AWS a 300–3.000 msgs/s; sessões serializam assinaturas do Azure. Habilite‑a apenas quando o domínio exigir ordenação — nunca como um cobertor de segurança.
DLQs não são um cemitério. Elas precisam de alertas (profundidade de DLQ > 0 pagina o plantonista) e um procedimento de replay documentado — redrive do SQS ou recebimento e reenvio do $DeadLetterQueue do Service Bus. Uma DLQ sem um runbook de replay é um vazamento silencioso.
Mensagens grandes são um antipadrão. > 256 KB na AWS implica claim‑check via S3. O Service Bus Premium suporta 100 MB, mas custo de transporte e pressão de memória do consumidor ainda argumentam a favor de claim‑check nesse tamanho.
Marque cada recurso com project, environment, workload, costCenter, managedBy. Sem essas tags, FinOps não pode atribuir gastos e a equipe de plataforma não pode impor políticas de ciclo de vida. Os snippets acima carregam o conjunto completo; não os remova.
Sem chaves SAS, sem chaves de usuário IAM. Identidade Gerenciada no Azure, funções IAM na AWS. disableLocalAuth: true no namespace do Service Bus, condição aws:SourceArn em cada política de fila SQS. Qualquer outra coisa é uma credencial de longa duração esperando para vazar.

A escolha entre SNS/SQS e Service Bus raramente é binária. Comece no Service Bus Standard ou SNS + SQS. Mova para Premium ou FIFO apenas quando uma restrição acima — tamanho, ordenação, isolamento — forçar você para lá.

Practical Guide: Building a Cell-Based Architecture on Azure with Terraform

Tue, 21 Apr 2026 00:00:00 GMT

1. Introdução

À medida que as aplicações em nuvem escalam para atender públicos globais, depender de uma única pilha de infraestrutura centralizada introduz vulnerabilidades críticas. Uma falha localizada ou um vizinho ruidoso pode desencadear uma interrupção sistêmica. A Arquitetura Baseada em Células mitiga isso ao particionar o sistema em unidades isoladas, idênticas e autocontidas chamadas "células." Ao rotear inquilinos ou usuários específicos para células dedicadas, você restringe o raio de explosão de qualquer degradação estritamente àquela célula, preservando a disponibilidade do restante do sistema.

Ao final deste tutorial, você será capaz de projetar e provisionar uma arquitetura celular no Microsoft Azure. Utilizaremos o Azure Front Door como ponto de entrada global, o Azure Functions (Python) para roteamento dinâmico de tráfego e processamento, e o Azure Cosmos DB para gerenciamento de estado isolado. Dominar esse padrão no Azure não apenas reforça suas cargas de trabalho atuais, mas também consolida princípios fundamentais de multi-nuvem, pois os conceitos de roteamento desacoplado e isolamento de estado são diretamente transferíveis entre diferentes provedores de nuvem em um cenário corporativo unificado.

2. Pré-requisitos

Para executar as configurações e o código deste tutorial, verifique se você possui as seguintes ferramentas e níveis de acesso:

Uma assinatura ativa do Microsoft Azure com permissões de Proprietário ou Colaborador para criar Grupos de Recursos, contas do Cosmos DB, Azure Functions e Azure Front Door.
Terraform CLI (versão 1.0 ou superior) instalado localmente para provisionamento de Infraestrutura como Código (IaC).
Python (versão 3.9 ou superior) instalado localmente, junto com o Azure Functions Core Tools para desenvolvimento e empacotamento local.
Azure CLI instalado e autenticado (az login) em seu ambiente local.
Compreensão fundamental de conceitos de particionamento e sintaxe HCL do Terraform.

3. Passo a Passo

Antes de mergulhar no código de infraestrutura, vamos visualizar o fluxo de execução. O diagrama de sequência abaixo detalha como uma solicitação global é interceptada, avaliada e encaminhada com segurança para uma pilha celular estritamente isolada no Azure.

3.1 Definindo o Blueprint da Célula (Módulo Terraform)

O que fazer: Crie um módulo Terraform reutilizável que represente uma única "Célula" isolada. Isso inclui uma Conta de Armazenamento dedicada, um Plano de Serviço de Aplicativo, uma Azure Function (Worker) e um banco de dados Cosmos DB.

Por que fazer isso: A regra principal da arquitetura celular é a consistência absoluta entre ambientes. Ao encapsular a infraestrutura em um módulo Terraform, você garante que cada célula gerada seja uma réplica exata, evitando desvio de configuração e simplificando a escala horizontal.

Exemplo: Crie um diretório chamado modules/cell e adicione um arquivo main.tf.

# modules/cell/main.tf
variable "location" { type = string }
variable "resource_group_name" { type = string }
variable "cell_id" { type = string }

resource "azurerm_cosmosdb_account" "cell_db" {
  name                = "cosmos-cell-${var.cell_id}"
  location            = var.location
  resource_group_name = var.resource_group_name
  offer_type          = "Standard"
  kind                = "GlobalDocumentDB"

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location          = var.location
    failover_priority = 0
  }
}

resource "azurerm_cosmosdb_sql_database" "cell_sqldb" {
  name                = "app-state"
  resource_group_name = var.resource_group_name
  account_name        = azurerm_cosmosdb_account.cell_db.name
}

resource "azurerm_storage_account" "cell_storage" {
  name                     = "stcell${var.cell_id}"
  resource_group_name      = var.resource_group_name
  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "cell_plan" {
  name                = "plan-cell-${var.cell_id}"
  location            = var.location
  resource_group_name = var.resource_group_name
  os_type             = "Linux"
  sku_name            = "Y1" # Consumption plan
}

resource "azurerm_linux_function_app" "cell_worker" {
  name                       = "func-worker-${var.cell_id}"
  location                   = var.location
  resource_group_name        = var.resource_group_name
  service_plan_id            = azurerm_service_plan.cell_plan.id
  storage_account_name       = azurerm_storage_account.cell_storage.name
  storage_account_access_key = azurerm_storage_account.cell_storage.primary_access_key

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }

  app_settings = {
    "CELL_ID"            = var.cell_id
    "COSMOS_DB_ENDPOINT" = azurerm_cosmosdb_account.cell_db.endpoint
  }
}

output "function_default_hostname" {
  value = azurerm_linux_function_app.cell_worker.default_hostname
}

3.2 Criando Múltiplas Células

O que fazer: Na configuração raiz do Terraform, defina o grupo de recursos base e itere sobre uma coleção de identificadores para implantar múltiplas células simultaneamente.

Por que fazer isso: Isso traduz o módulo teórico em ambientes físicos isolados. O uso de um loop for_each permite escalar sem esforço de duas para cinquenta células apenas atualizando uma variável local, abstraindo a complexidade de gerenciar infraestruturas paralelas.

Exemplo: No seu diretório raiz, crie o arquivo main.tf.

# main.tf
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg" {
  name     = "rg-cellular-architecture"
  location = "East US"
}

locals {
  cells = ["alpha", "beta"]
}

module "isolated_cells" {
  source   = "./modules/cell"
  for_each = toset(local.cells)

  cell_id             = each.key
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

3.3 Desenvolvendo o Roteador de Célula em Python

O que fazer: Escreva o código da Função do Azure em Python que atuará como roteador de entrada global. Ele deve inspecionar solicitações HTTP recebidas, determinar o mapeamento apropriado de locatários e encaminhar a solicitação para a célula correta.

Por que fazer isso: O roteador abstrai a topologia interna do cliente. Aplicativos interagem com um único endpoint de API, sem saber que sua solicitação está sendo roteada para cell-alpha ou cell-beta. Esse mapeamento dinâmico permite realizar migrações ao vivo de locatários entre células para balancear carga sem tempo de inatividade.

Exemplo: Crie o código Python para sua função de roteamento (__init__.py dentro da pasta da Função do Azure).

import logging
import json
import os
import urllib.request
import azure.functions as func

# In production, fetch this from Cosmos DB (Tenant Registry)
CELL_ENDPOINTS = {
    "alpha": os.environ.get("CELL_ALPHA_URL", "https://func-worker-alpha.azurewebsites.net"),
    "beta": os.environ.get("CELL_BETA_URL", "https://func-worker-beta.azurewebsites.net")
}

def get_target_cell(tenant_id: str) -> str:
    # Mocking a Cosmos DB registry lookup
    # A real implementation would query the global metadata database
    if tenant_id.startswith("A"):
        return "alpha"
    return "beta"

def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Global Router processing a request.')

    try:
        req_body = req.get_json()
        tenant_id = req_body.get('tenant_id')
        
        if not tenant_id:
            return func.HttpResponse(
                "Missing partition key: tenant_id", 
                status_code=400
            )

        target_cell = get_target_cell(tenant_id)
        target_url = f"{CELL_ENDPOINTS[target_cell]}/api/process"
        
        # Proxy the request to the isolated cell
        data = json.dumps(req_body).encode('utf-8')
        proxy_req = urllib.request.Request(
            target_url, 
            data=data,
            headers={'Content-Type': 'application/json'}
        )
        
        with urllib.request.urlopen(proxy_req) as response:
            cell_response = response.read().decode('utf-8')

        return func.HttpResponse(
            json.dumps({
                "status": "success",
                "x_routed_to": target_cell,
                "data": json.loads(cell_response)
            }),
            mimetype="application/json",
            status_code=200
        )

    except Exception as e:
        logging.error(f"Routing error: {str(e)}")
        return func.HttpResponse("Internal Server Error", status_code=500)

3.4 Provisionando a Camada de Roteamento Global

O que fazer: Implante a Função do Azure de roteamento central e configure um perfil do Azure Front Door para ficar na frente dela.

Por que fazer isso: O Azure Front Door atua como um ponto de entrada global seguro e distribuído. Ele absorve ataques DDoS na borda, fornece recursos de WAF e garante que a Função de Roteador Global seja protegida contra exposição direta e não autenticada à internet.

Exemplo: Adicione a infraestrutura de roteamento ao seu main.tf raiz.

# Shared storage for the Global Router
resource "azurerm_storage_account" "router_storage" {
  name                     = "stglobalrouter"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "router_plan" {
  name                = "plan-global-router"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  os_type             = "Linux"
  sku_name            = "Y1"
}

resource "azurerm_linux_function_app" "global_router" {
  name                       = "func-global-router-gateway"
  location                   = azurerm_resource_group.rg.location
  resource_group_name        = azurerm_resource_group.rg.name
  service_plan_id            = azurerm_service_plan.router_plan.id
  storage_account_name       = azurerm_storage_account.router_storage.name
  storage_account_access_key = azurerm_storage_account.router_storage.primary_access_key

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }

  app_settings = {
    "CELL_ALPHA_URL" = "https://${module.isolated_cells[\"alpha\"].function_default_hostname}"
    "CELL_BETA_URL"  = "https://${module.isolated_cells[\"beta\"].function_default_hostname}"
  }
}

Execute terraform init, terraform plan e terraform apply para implantar toda a arquitetura multi-célula.

4. Solução de Problemas Comuns

A transição para uma arquitetura celular requer uma mudança na forma como você gerencia estado e tráfego. Aqui estão problemas comuns que você pode encontrar:

Limitação de Cosmos DB (HTTP 429) em uma Célula Específica:
- Problema: Uma célula começa a rejeitar solicitações, enquanto outras operam normalmente. Isso geralmente indica um "vizinho ruidoso" – um locatário cuja carga de trabalho subiu repentinamente, esgotando as Unidades de Solicitação (RUs) provisionadas para o banco de dados dessa célula específica.
- Solução: Verifique as métricas no Azure Monitor. Se um locatário tiver ultrapassado o tamanho da célula compartilhada, você deve executar uma migração ao vivo. Atualize o Registro Global de Locatários (Banco de Dados de Metadados) para apontar aquele tenant_id específico para uma célula dedicada recém-provisionada, redirecionando seu tráfego de forma transparente.
Sobrecarga de Latência na Camada de Roteamento:
- Problema: As solicitações demoram significativamente mais porque precisam passar pelo Front Door, pela Função de Roteador e, finalmente, pela Função de Célula.
- Solução: A lógica do roteador deve ser otimizada agressivamente. Implemente cache no nível do Roteador Global usando o Cache do Azure para Redis para que a função não precise consultar o Cosmos DB para o mapeamento de locatários em cada solicitação.
Inicializações a Frio em Funções do Azure:
- Problema: A primeira solicitação para uma célula específica leva vários segundos para ser executada.
- Solução: Como usamos o Plano de Consumo (Y1) para eficiência de custo neste tutorial, as inicializações a frio são esperadas. Para cargas de trabalho de produção, mude o Plano de Serviço de Aplicativo para Premium (EP1 ou superior) para manter as instâncias pré-aquecidas, garantindo respostas consistentes com baixa latência.

5. Conclusão

Construir uma Arquitetura Baseada em Células no Azure transforma vulnerabilidades monolíticas em unidades gerenciáveis e contidas. Ao utilizar o Terraform, estabelecemos uma linha de base reprodutível para ambientes isolados e implementamos uma camada de roteamento Python para encaminhar tráfego dinamicamente.

Esse desacoplamento garante que picos massivos de tráfego ou implantações com problemas sejam restritos a domínios únicos. Ao amadurecer essa arquitetura, foque em automatizar o processo de "Migração de Locatários" — mover dados ativos entre instâncias do Cosmos DB sem tempo de inatividade — e padronizar seus módulos do Terraform para garantir que esse padrão possa ser adotado rapidamente em vários ambientes de nuvem.

Practical Guide: Building a Cell-Based Architecture on AWS with Terraform

Mon, 20 Apr 2026 00:00:00 GMT

1. Introdução

Na era cloud-native, sistemas muitas vezes chegam a um ponto onde escalar uma arquitetura única introduz riscos inaceitáveis. Uma falha em um componente central pode resultar em um desastre global, afetando todos os usuários simultaneamente. A Arquitetura Baseada em Células resolve isso dividindo o sistema em múltiplas instâncias isoladas, autônomas e idênticas chamadas "células". Ao colocar usuários (ou locatários) em células específicas, você reduz drasticamente o impacto de falhas.

Embora este tutorial se concentre em uma implementação AWS, projetar estratégias celulares é um pilar da engenharia multinuvem robusta. Os princípios de isolar estado e rotear tráfego com base em chaves de partição se aplicam perfeitamente a outros provedores, como o Microsoft Azure, garantindo alta disponibilidade independentemente da nuvem subjacente.

No final deste tutorial, você entenderá como prover uma infraestrutura celular na AWS usando Terraform. Criaremos um blueprint para uma "célula", estamparemos múltiplas instâncias idênticas e construiremos uma camada de roteador em Python para direcionar tráfego ao ambiente isolado correto.

2. Pré-requisitos

Para implementar este padrão arquitetônico com sucesso, você precisará de:

Uma conta ativa da Amazon Web Services (AWS) com privilégios administrativos.
Terraform instalado localmente (versão 1.0 ou superior) para Infraestrutura como Código.
Python (versão 3.9 ou superior) para escrever a lógica de roteamento.
Credenciais AWS configuradas em seu ambiente (aws configure).
Compreensão fundamental de arquitetura de software e lógica de particionamento.

3. Passo a Passo

Uma Arquitetura Baseada em Células introduz uma "Camada de Roteamento Fino" na frente de sua infraestrutura principal. O diagrama abaixo ilustra como uma requisição de entrada é avaliada e encaminhada para uma pilha celular estritamente isolada.

3.1 Definindo o Blueprint da Célula (Módulo Terraform)

O que fazer: Crie um módulo Terraform reutilizável que defina exatamente o que é uma única "Célula". Por que fazer isso: O princípio central da arquitetura celular é que toda célula é idêntica. Ao usar um módulo Terraform, você garante que qualquer atualização na infraestrutura seja aplicada uniformemente em todas as células isoladas, evitando desvio de configuração (configuration drift).

Exemplo: Crie uma pasta chamada modules/cell e adicione um arquivo main.tf dentro dela. Este blueprint contém um API Gateway, uma função Lambda e uma tabela DynamoDB isolada.

# modules/cell/main.tf
variable "cell_id" {
  type        = string
  description = "Identificador único para a célula (ex: cell-1)"
}

resource "aws_dynamodb_table" "cell_state" {
  name           = "app-state-${var.cell_id}"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

resource "aws_lambda_function" "cell_compute" {
  filename      = "cell_worker.zip"
  function_name = "worker-${var.cell_id}"
  role          = aws_iam_role.cell_role.arn
  handler       = "worker.handler"
  runtime       = "python3.11"

  environment {
    variables = {
      CELL_ID    = var.cell_id
      TABLE_NAME = aws_dynamodb_table.cell_state.name
    }
  }
}

// (Configurações adicionais de IAM Gateway e API Gateway seguem aqui)

3.2 Criando Múltiplas Células

O que fazer: No seu main.tf raiz, itere sobre uma lista de identificadores de célula para provisionar múltiplos ambientes isolados e idênticos. Por que fazer isso: Isso permite que você escale horizontalmente, adicionando novas pilhas de infraestrutura completamente independentes, em vez de aumentar o tamanho de um monólito de banco de dados ou cluster de computação.

Exemplo: No seu diretório raiz, crie um main.tf para invocar o módulo.

# main.tf
provider "aws" {
  region = "us-east-1"
}

module "cell_alpha" {
  source   = "./modules/cell"
  cell_id  = "alpha"
}

module "cell_beta" {
  source   = "./modules/cell"
  cell_id  = "beta"
}

3.3 Desenvolvendo a Camada de Roteamento em Python

O que fazer: Escreva a Função Lambda do AWS que atuará como roteador de entrada global. Ela deve inspecionar as requisições HTTP de entrada, determinar o mapeamento apropriado de locatários e encaminhar a requisição para a célula correta.

Por que fazer isso: O roteador abstrai a topologia interna do cliente. Aplicações interagem com um único endpoint de API, sem saber que sua requisição está sendo roteada para cell-alpha ou cell-beta. Esse mapeamento dinâmico permite realizar migrações ao vivo de locatários entre células para balancear a carga sem tempo de inatividade.

Exemplo: Crie o código Python para sua função de roteamento (router.py).

import json
import hashlib
import urllib.request

# Em produção, obtenha isso de um armazenamento de configuração global
CELL_ENDPOINTS = {
    "cell-alpha": "https://alpha.execute-api.us-east-1.amazonaws.com/prod",
    "cell-beta": "https://beta.execute-api.us-east-1.amazonaws.com/prod"
}

def get_target_cell(partition_key: str) -> str:
    """Hashes consistentemente a chave de partição para uma célula específica."""
    hash_val = int(hashlib.md5(partition_key.encode('utf-8')).hexdigest(), 16)
    
    # Distribuição simples por módulo
    if hash_val % 2 == 0:
        return "cell-alpha"
    return "cell-beta"

def lambda_handler(event, context):
    try:
        body = json.loads(event.get('body', '{}'))
        tenant_id = body.get('tenant_id')
        
        if not tenant_id:
            return {"statusCode": 400, "body": "Missing partition key: tenant_id"}
            
        target_cell = get_target_cell(tenant_id)
        target_endpoint = CELL_ENDPOINTS[target_cell]
        
        # Encaminha a requisição para a célula isolada (Simplificado para demonstração)
        req = urllib.request.Request(
            f"{target_endpoint}/process", 
            data=event.get('body').encode('utf-8'),
            headers={'Content-Type': 'application/json'}
        )
        
        with urllib.request.urlopen(req) as response:
            cell_response = response.read()
            
        return {
            "statusCode": 200,
            "body": json.dumps({
                "routed_to": target_cell,
                "cell_response": json.loads(cell_response)
            })
        }
        
    except Exception as e:
        return {"statusCode": 500, "body": str(e)}

3.4 Provisionando a Camada de Roteamento

O que fazer: Adicione a camada de roteamento à sua configuração Terraform raiz para expor um ponto de entrada unificado aos seus usuários. Por que fazer isso: Isso centraliza o controle de acesso. Todo o tráfego externo atinge o roteador, que então proxyf os dados sobre a rede backbone da AWS para as células respectivas, garantindo controle de acesso estrito no limite.

Exemplo: Adicione isso ao seu main.tf raiz:

data "archive_file" "router_zip" {
  type        = "zip"
  source_file = "router.py"
  output_path = "router.zip"
}

resource "aws_lambda_function" "cell_router" {
  filename      = data.archive_file.router_zip.output_path
  function_name = "GlobalCellRouter"
  role          = aws_iam_role.router_role.arn # (Assume-se que um papel básico de execução foi criado)
  handler       = "router.lambda_handler"
  runtime       = "python3.11"
}

resource "aws_lambda_function_url" "router_url" {
  function_name      = aws_lambda_function.cell_router.function_name
  authorization_type = "NONE"
}

output "global_entrypoint" {
  value       = aws_lambda_function_url.router_url.function_url
  description = "A URL única com a qual os clientes interagem."
}

4. Solução de Problemas Comuns

Implantar arquiteturas celulares muda a complexidade do dimensionamento de infraestrutura para roteamento de tráfego e gerenciamento de estado. Esteja preparado para lidar com estes desafios comuns:

Desvio de Partição (Vizinhos Ruidosos):
- Problema: Uma célula fica sobrecarregada enquanto outras ficam ociosas porque um tenant_id específico gera 80% do tráfego.
- Solução: Monitore as métricas das células de perto. Se um locatário ultrapassar o tamanho de uma célula compartilhada, você deve implementar um processo de "migração de locatário" para mover seus dados para uma célula exclusiva de locatário único, atualizando a lógica de mapeamento do roteador.
Agregação de Dados entre Células:
- Problema: Você precisa gerar um relatório global, mas os dados estão divididos por várias tabelas DynamoDB isoladas.
- Solução: Não consulte as células diretamente para dados globais. Em vez disso, implemente uma estratégia assíncrona de data lake onde cada célula transmite suas mudanças de estado (por exemplo, via DynamoDB Streams e Kinesis) para um armazenamento analítico central.
Gargalo na Camada de Roteamento:
- Problema: A Camada de Roteador de Célula cai, causando uma interrupção global — exatamente o que a arquitetura celular tenta evitar.
- Solução: A camada de roteamento deve ser incrivelmente leve e depender de serviços de borda altamente resilientes e geograficamente distribuídos (como Amazon Route 53 ou CloudFront) em vez de uma única instância de computação.

5. Conclusão

Ao implementar uma Arquitetura Baseada em Células, você estabelece fronteiras definitivas de isolamento de falhas. Nós utilizamos o Terraform para definir um blueprint de célula repetível e criamos uma camada de roteamento Python fina para direcionar o tráfego dinamicamente.

Esta abordagem minimiza o raio de impacto de falhas localizadas, tornando seus sistemas inerentemente mais resilientes. À medida que você expande este conceito, considere como esta estratégia de roteamento desacoplado se traduz em cenários de multinuvem, permitindo que você roteie o tráfego perfeitamente entre uma célula AWS e uma célula Azure baseada em desempenho, custo ou requisitos regulatórios.

Practical Guide: Event-Driven Infrastructure on Azure with Terraform

Sun, 19 Apr 2026 00:00:00 GMT

1. Introdução

Arquiteturas orientadas a eventos desacoplam componentes do sistema, substituindo a comunicação síncrona direta por um modelo de publicação/assinatura altamente escalável. Ao final deste tutorial, você será capaz de provisionar uma infraestrutura completa baseada em eventos no Microsoft Azure. Essa configuração utiliza o Azure Event Grid como espinha dorsal de roteamento de eventos, o Azure Service Bus para enfileiramento confiável de mensagens e o Azure Functions para processamento computacional serverless.

Dominar essa topologia é um requisito estrutural para o design de software moderno. Isolar produtores de consumidores garante que falhas localizadas não cascateiem pelo sistema, permitindo a escala independente de microsserviços. Além disso, traduzir esses conceitos entre diferentes provedores de nuvem fortalece uma estratégia robusta de multicloud, permitindo mapear padrões arquiteturais (como Event Bus -> Fila -> Compute Serverless) perfeitamente em uma landing zone baseada no Azure.

2. Pré-requisitos

Para executar as configurações propostas neste guia, certifique-se de que possui os seguintes pré-requisitos estabelecidos:

Uma conta ativa da Microsoft Azure com permissões para criar Grupos de Recursos, Tópicos do Event Grid, Namespaces do Service Bus e Function Apps.
Terraform instalado localmente (versão 1.0 ou superior) para provisionamento de Infraestrutura como Código (IaC).
Python (versão 3.9 ou superior) instalado localmente para desenvolver a lógica da função.
A CLI do Azure (az) instalada e autenticada em seu ambiente local.
Familiaridade com navegação em terminal e sintaxe HCL do Terraform.

3. Passo a passo

Antes de mergulhar no código, é crítico visualizar o ciclo de vida do evento. O diagrama de sequência abaixo mapeia o fluxo de informações através dos serviços Azure provisionados.

3.1 Configurando o Provedor e Grupo de Recursos

O que fazer: Defina o provedor Azure Resource Manager (azurerm) no Terraform e crie um Grupo de Recursos fundamental para agrupar logicamente todos os ativos de infraestrutura.

Por que fazer: O Terraform requer definições de provedores para autenticar e interagir com a API específica da nuvem. O Grupo de Recursos é uma construção obrigatória do Azure que controla o ciclo de vida e o gerenciamento de acesso dos recursos que contém.

Exemplo:
Crie um arquivo chamado main.tf e adicione a seguinte configuração:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg" {
  name     = "rg-event-driven-architecture"
  location = "East US"
}

3.2 Criando o Tópico do Event Grid

O que fazer: Provisionar um Tópico Personalizado (Custom Topic) no Azure Event Grid.

Por que fazer: Um Tópico Personalizado serve como o endpoint dedicado onde suas aplicações publicam eventos de negócios. Isolar eventos de negócios em um tópico personalizado evita misturar a lógica da aplicação com eventos de infraestrutura subjacentes do Azure.

Exemplo:
Acrescente o seguinte bloco ao seu main.tf:

resource "azurerm_eventgrid_topic" "custom_topic" {
  name                = "app-domain-events-topic"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

3.3 Provisionando o Namespace e Fila do Service Bus

O que fazer: Criar um Namespace do Service Bus e uma Fila específica dentro dele para absorver os eventos recebidos.

Por que fazer: Embora o Event Grid possa empurrar diretamente para uma Azure Function, o roteamento através de uma Fila do Service Bus introduz um buffer crítico. Isso garante alta disponibilidade, durabilidade de mensagens e evita sobrecarregar o serviço de computação downstream durante picos de tráfego.

Exemplo:
Adicione as configurações do Service Bus:

resource "azurerm_servicebus_namespace" "sb_namespace" {
  name                = "sb-event-driven-demo"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  sku                 = "Standard"
}

resource "azurerm_servicebus_queue" "event_queue" {
  name         = "event-processing-queue"
  namespace_id = azurerm_servicebus_namespace.sb_namespace.id
}

3.4 Desenvolvendo a Azure Function em Python

O que fazer: Escrever o código Python usando o modelo de programação v2 das Azure Functions para processar mensagens que chegam na Fila do Service Bus.

Por que fazer: A função representa a lógica de negócio que reage ao evento. O modelo v2 utiliza decoradores, fornecendo uma maneira limpa e concisa de definir gatilhos e vinculações diretamente no código, tratando automaticamente a desserialização da mensagem.

Exemplo:
Crie um arquivo chamado function_app.py no diretório do seu projeto:

import logging
import json
import azure.functions as func

# Inicializa o App da Function
app = func.FunctionApp()

@app.service_bus_queue_trigger(
    arg_name="msg", 
    queue_name="event-processing-queue",
    connection="ServiceBusConnection"
)
def process_domain_event(msg: func.ServiceBusMessage):
    logger = logging.getLogger()
    logger.info("Initiating Service Bus event processing.")

    try:
        # Decodifica e carrega o corpo da mensagem
        msg_body = msg.get_body().decode('utf-8')
        event_payload = json.loads(msg_body)
        
        logger.info(f"Complete event payload: {json.dumps(event_payload, indent=2)}")
        
        # O esquema do Event Grid tipicamente encapsula dados em um campo 'data'
        data = event_payload.get('data', {})
        order_id = data.get('order_id')
        
        logger.info(f"Successfully processed business operation for order: {order_id}")

    except json.JSONDecodeError:
        logger.error("Failed to decode message payload as JSON.")
    except Exception as e:
        logger.error(f"Unexpected error during processing: {str(e)}")

3.5 Provisionando a Infraestrutura de Computação para a Function

O que fazer: Definir a Conta de Armazenamento, o Plano de Serviço (Consumo), e o App de Function Linux via Terraform, injetando as strings de conexão necessárias como variáveis de ambiente.

Por que fazer: Azure Functions requerem uma conta de armazenamento de suporte para gerenciamento de estado e um plano de execução para definir escala e preço. Injetar ServiceBusConnection vincula seguramente a camada de computação à camada de mensagens.

Exemplo:
Adicione os recursos de computação ao seu main.tf:

resource "azurerm_storage_account" "sa" {
  name                     = "saeventdrivendemo123" # Deve ser globalmente único
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "asp" {
  name                = "asp-event-driven"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  os_type             = "Linux"
  sku_name            = "Y1" # Plano de Consumo Serverless
}

resource "azurerm_linux_function_app" "function_app" {
  name                       = "func-order-processor-app"
  resource_group_name        = azurerm_resource_group.rg.name
  location                   = azurerm_resource_group.rg.location
  service_plan_id            = azurerm_service_plan.asp.id
  storage_account_name       = azurerm_storage_account.sa.name
  storage_account_access_key = azurerm_storage_account.sa.primary_access_key

  site_config {
    application_stack {
      python_version = "3.11"
    }
  }

  app_settings = {
    "FUNCTIONS_WORKER_RUNTIME" = "python"
    "ServiceBusConnection"     = azurerm_servicebus_namespace.sb_namespace.default_primary_connection_string
  }
}

3.6 Criando a Assinatura do Event Grid (Regra de Roteamento)

O que fazer: Configurar uma Assinatura de Evento que filtra eventos que chegam ao Tópico Personalizado e os roteia para a Fila do Service Bus.

Por que fazer: Filtragem avançada garante que apenas eventos relevantes alcancem a camada de computação, evitando execuções desnecessárias e reduzindo custos. Isso atua como o roteador inteligente na arquitetura.

Exemplo:
Complete o arquivo main.tf com a assinatura de roteamento:

resource "azurerm_eventgrid_event_subscription" "queue_subscription" {
  name  = "route-order-created"
  scope = azurerm_eventgrid_topic.custom_topic.id

  service_bus_queue_endpoint_id = azurerm_servicebus_queue.event_queue.id

  advanced_filter {
    string_in {
      key    = "data.detail-type"
      values = ["OrderCreated"]
    }
  }
}

Para implantar a infraestrutura, execute terraform init, terraform plan e terraform apply. Note que, enquanto o Terraform provisiona a infraestrutura, a implantação atual do código Python é tipicamente tratada via Azure Functions Core Tools (func azure functionapp publish func-order-processor-app) ou um pipeline de CI/CD como GitHub Actions.

4. Solução de Problemas Comuns

Implantar sistemas distribuídos pode introduzir desafios de integração. Aqui estão os problemas mais comuns e como resolvê-los:

String de Conexão do Service Bus Ausente ou Inválida:
Problema: A Azure Function falha ao disparar, e os logs mostram erros de vinculação.
Solução: Verifique as Configurações do Aplicativo (Application Settings) no Portal do Azure para o App de Function. Certifique-se de que ServiceBusConnection corresponde exatamente à string de conexão primária do Namespace do Service Bus e está grafada corretamente no decorador app.service_bus_queue_trigger.
Incompatibilidade de Esquema do Event Grid:
Problema: Eventos são publicados com sucesso no tópico, mas nunca chegam na Fila do Service Bus.
Solução: Inspecione a estrutura da carga útil. O Azure Event Grid requer um esquema específico (id, subject, data, eventType, etc.). Se você está filtrando por data.detail-type no Terraform, certifique-se de que seu JSON publicado contém explicitamente um objeto data com uma chave detail-type correspondente a "OrderCreated".
Conflitos de Nomeamento da Conta de Armazenamento:
Problema: O Terraform falha durante a fase de terraform apply ao criar o azurerm_storage_account.
Solução: Nomes de contas de armazenamento no Azure devem ser globalmente únicos entre todos os clientes da Azure, puramente minúsculos, e ter entre 3 a 24 caracteres. Ajuste o atributo name no bloco do Terraform para uma string altamente única.

5. Conclusão

Este tutorial estabeleceu uma arquitetura resiliente e desacoplada nativa do Microsoft Azure. Ao utilizar o Terraform, provisionamos o Event Grid para roteamento inteligente de eventos, o Service Bus para enfileiramento robusto de mensagens e o Azure Functions para computação escalável.

Implementar esses padrões fornece um paralelo claro com outros ecossistemas de nuvem, reforçando uma fundação sólida para projetar arquiteturas celulares e estratégias de multicloud. Como próximo passo, explore a implementação de Filas de Mensagens Mortas (DLQ) dentro do Service Bus para tratar sistematicamente mensagens venenosas, garantindo que sua aplicação distribuída permaneça robusta mesmo diante de dados não processáveis.

Practical Guide: Building an Active-Active Multicloud Cell-Based Architecture

Thu, 20 Feb 2025 00:00:00 GMT

1. Introduction

Uma arquitetura baseada em células multicloud representa o ápice de isolamento de falhas e neutralidade de fornecedor. Distribuindo autonomamente "células" entre diferentes provedores de cloud, como colocar a Célula Alpha no AWS e a Célula Beta no Azure, você elimina o risco de uma interrupção regional ou global de um único fornecedor derrubar toda a aplicação. Essa arquitetura impede o bloqueio de fornecedor ao impor uma camada de entrada agnóstica e exige princípios de Design Orientado por Domínio para manter limites de domínio isolados.

3. Step-by-Step

Pré-requisitos

Contas ativas em AWS e Azure com credenciais administrativas.
Terraform (1.0+) instalado localmente, com os provedores hashicorp/aws e hashicorp/azurerm autenticados.
Python (3.11+) para implementar a lógica de roteamento edge agnóstico.
Nome de domínio registrado e acesso a um provedor de DNS na edge (ex.: Cloudflare).
Conhecimento de Design Orientado por Domínio (DDD) para garantir que os workloads das células sejam completamente acoplados e stateless.

Provisionamento do Data Plane AWS Cell (Cell Alpha): Implante DynamoDB, Lambda e API Gateway via main.tf:

aws_dynamodb_table.aws_cell_state
aws_lambda_function.aws_cell_worker

Azure Cell (Cell Beta): Implante Cosmos DB, Azure Functions e Service Plans via main.tf:

azurerm_resource_group.az_cell_rg
azurerm_cosmosdb_account.az_cell_db

Roteador de Edge Agnóstico Implemente a lógica de roteamento em Python:

# GLOBAL_REGISTRY mapeia IDs de tenant para endpoints de cloud
def route_request(request_body: str) -> dict:
    ... # Encaminha requisições entre endpoints AWS/Azure

Desafios

Fragmentação de Estado: Utilize Data Lakes unificados (ex.: Snowflake ou Databricks) para análises cruzadas. Configure as funções Lambda e Azure para transmitir mudanças de estado para esse repositório central.
Latência entre Nuvens: Cache o registro de tenants na edge usando Cloudflare KV, Fastly Compute dictionaries ou Redis Enterprise Active-Active, garantindo que a metadata de roteamento esteja próximo ao roteador edge.
Drift de CI/CD: Imponha Arquitetura Hexagonal com lógica de domínio pura em Python compartilhada entre nuvens; apenas os adaptadores de I/O (DynamoDB vs. Cosmos DB) devem variar.

5. Conclusão

Adotar uma arquitetura baseada em células multicloud garante defesa final contra lock‑in de fornecedor e falhas catastróficas. Usamos Terraform para orquestrar simultaneamente data planes isolados no AWS e no Azure, e desenvolvemos um roteador Python edge que direciona tráfego conforme o identity do tenant. Esse modelo permite escala horizontal ilimitada tratando AWS e Azure como utilidades intercambiáveis. No próximo passo, concentre‑se na automação da migração de tenants entre clouds, permitindo evacuar recursos do AWS para o Azure em tempo real caso métricas indiquem degradação em um provedor específico.