rss.livelink.threads-in-node

Detectando Anomalias de Custo no Azure com FinOps Hub + SRE Agent

arsilvan — Thu, 23 Apr 2026 12:59:25 GMT

Introdução

Um dos maiores desafios em ambientes cloud é manter a visibilidade sobre os custos. Picos inesperados podem passar despercebidos por dias e quando chegam na fatura, já é tarde demais.

Neste artigo, vou mostrar como configurei uma análise automática diária de anomalias de custo usando o Azure SRE Agent, conectado ao FinOps Hub (Azure Data Explorer), com notificação automática no Microsoft Teams quando algo fora do padrão é detectado.

🏗️ Arquitetura da Solução

FinOps Hub (ADX) → SRE Agent (Scheduled Task) → KQL Anomaly Detection

↓ anomalia detectada?

SIM → Adaptive Card → Teams Channel

NÃO → Log: 'custos dentro do esperado'

Pré-requisitos

	Requisito	Detalhe
✅	FinOps Hub implantado	Com dados de custo sendo ingeridos no Azure Data Explorer
✅	Azure SRE Agent configurado	Com acesso à subscription onde o FinOps Hub está
✅	Canal no Microsoft Teams	Onde as notificações serão postadas
✅	Permissões adequadas	Managed Identity com Viewer no database Hub do ADX

Passo a Passo

① Identificar o Cluster ADX do FinOps Hub

O primeiro passo é localizar o cluster Azure Data Explorer onde o FinOps Hub armazena os dados de custo. No Azure SRE Agent, usamos o Azure Resource Graph:

az graph query -q "Resources | where type =~ 'Microsoft.Kusto/clusters'" --first 10 --subscription <subscription-id>

No meu caso como exemplo, o cluster retornado foi:

Propriedade	Valor
Nome	finopshubadx
URI	https://finopshubadx.northcentralus.kusto.windows.net
Database	Hub
SKU	Dev(No SLA)_Standard_D11_v2
Região	North Central US

② Configurar Permissões (RBAC no ADX)

A managed identity do SRE Agent precisa de acesso Viewer ao database Hub do ADX. Sem isso, a query KQL falhará com erro 403.

Opção A — Azure CLI:

az kusto database-principal-assignment create \
--cluster-name finopshubadx \
--database-name Hub \
--resource-group <resource-group> \
--subscription <subscription-id> \
--principal-assignment-name "sre-agent-viewer" \
--principal-id "<managed-identity-client-id>" \
--principal-type App --role Viewer

Opção B — Portal:

ADX → Cluster → Database Hub → Permissions → Add → Viewer → Selecionar managed identity

Opção C — KQL (ADX Web UI):

.add database Hub viewers ('aadapp=<client-id>') 'SRE Agent'

③ A Query KQL de Detecção de Anomalias

Esta query utiliza series_decompose_anomalies do Kusto para detectar padrões anômalos nos custos diários ao longo dos últimos 12 meses:

let numberOfMonths = 12;
let start = startofmonth(ago(numberOfMonths * 30d));
let end = now();
let interval = 1d;

Costs()
| where ChargePeriodStart between (start .. end)
| summarize DailyCost = sum(EffectiveCost)
by bin(ChargePeriodStart, interval)
| make-series CostSeries = sum(DailyCost)
on ChargePeriodStart from start to end step interval
| extend anomalies = series_decompose_anomalies(CostSeries)
| project ChargePeriodStart, CostSeries, anomalies

💡 Como a query funciona

Costs() → Função do FinOps Hub que retorna dados de custo consolidados
make-series → Cria série temporal diária contínua (sem gaps)
series_decompose_anomalies → Algoritmo ML nativo do Kusto que detecta spikes e drops usando decomposição sazonal + STL
Score > 0 → custo acima do esperado | Score < 0 → abaixo do esperado
Quanto maior o |score|, mais significativa a anomalia

④ Configurar Webhook no Microsoft Teams

Para receber notificações no Teams, criamos um Incoming Webhook via Power Automate Workflows (método recomendado pela Microsoft):

No canal do Teams, clique nos 3 pontos (...) → Workflows
Pesquise "Post to a channel when a webhook request is received"
Selecione o Team e Channel desejados → Add workflow
Copie a URL gerada (formato: https://prod-xx...logic.azure.com/...)
Ative o workflow no Power Automate (My flows → Turn on)

⚠️ Atenção: O workflow pode ser criado com status 'Suspended'. Ative em: Power Automate → My flows → Turn on.

⑤ Criar a Scheduled Task no SRE Agent

Agora a parte principal: criar a tarefa agendada (Scheduled Task) no Azure SRE Agent. Basta pedir em linguagem natural:

"Crie uma tarefa diária para analisar anomalias de custo no FinOps Hub e me notificar pelo Teams quando houver anomalias detectadas."

O SRE Agent criará a task com os seguintes parâmetros:

Parâmetro	Valor
Nome	Daily FinOps Cost Anomaly Analysis
Schedule	0 8 * * * (diariamente às 08:00 UTC)
ADX Cluster	https://finopshubadx.northcentralus.kusto.windows.net
Database	Hub
Query	KQL com series_decompose_anomalies (12 meses)
Notificação	Adaptive Card no Teams via webhook
Escalação	HIGH se anomalias por 3+ dias consecutivos
Idempotência	Sem anomalia = 'custos dentro do esperado'

Task details:

Obs: Modificar os campos na task para adequar seu ambiente

Autonomous Scheduled Run - Daily FinOps Cost Anomaly Analysis ## Scope - Subscription: xxxxxxx-xxxxxxx-xxxxxx-xxxx-xxxxx - ADX Cluster: https://finopshub.northcentralus.kusto.windows.net - Database: Hub - Resource Group: finopshub-rg ## Goal Detect cost anomalies in Azure spending using the FinOps Hub data. Run the KQL query against the ADX cluster, analyze results, and notify via Teams if anomalies are found. ## Step 1: Execute KQL Query Use the KustoQuery subagent to run this query against the ADX cluster (https://finopshubadx.northcentralus.kusto.windows.net, database: Hub): ```kql let numberOfMonths = 12; let start = startofmonth(ago(numberOfMonths * 30d)); let end = now(); let interval = 1d; Costs() | where ChargePeriodStart between (start .. end) | summarize DailyCost = sum(EffectiveCost) by bin(ChargePeriodStart, interval) | make-series CostSeries = sum(DailyCost) on ChargePeriodStart from start to end step interval | extend anomalies = series_decompose_anomalies(CostSeries) | project ChargePeriodStart, CostSeries, anomalies ``` ## Step 2: Analyze Results - Parse the anomalies array from series_decompose_anomalies output - Identify days where anomaly score is significantly positive (cost spike) or negative (unusual drop) - For each anomaly found, calculate: the date, actual cost value, expected baseline, and percentage deviation - Focus on the last 7 days of data for actionable anomalies, but use the full 12-month history for context ## Step 3: Generate Report Create a summary with: - Total anomalies detected in the last 7 days - For each anomaly: date, cost value, deviation from expected, severity (high/medium/low) - Trend analysis: whether costs are trending up, down, or stable - Top recommendations (e.g., investigate specific resource groups, check for new deployments, review reserved instances) ## Step 4: Teams Notification (ONLY if anomalies detected in last 7 days) If anomalies are found, send a notification to Microsoft Teams using the executing_code skill (ExecutePythonCode) to POST to this webhook URL: https://839eace659ab424397eca5b8fcc104.e4.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/88ec6b6c43014d8f8cb13999714dddd8/triggers/manual/paths/invoke?api-version=1&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=br2rNi4x1zKjWp6CgKWcajvEUW_7EUBkHrkbnp6Hk2g Use Adaptive Card format for the Teams message with: - Title: "⚠️ Azure Cost Anomaly Detected" - Summary of anomalies (dates, values, deviations) - Severity indicator - Link back to this SRE Agent thread for details Python code example for the webhook POST: ```python import urllib.request import json webhook_url = "<colar-url-webhook-aqui>" card = { "type": "message", "attachments": [{ "contentType": "application/vnd.microsoft.card.adaptive", "content": { "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "type": "AdaptiveCard", "version": "1.4", "body": [ {"type": "TextBlock", "text": "⚠️ Azure Cost Anomaly Detected", "weight": "Bolder", "size": "Large"}, {"type": "TextBlock", "text": "<ANOMALY_SUMMARY_HERE>", "wrap": True}, {"type": "FactSet", "facts": [ {"title": "Date", "value": "<DATE>"}, {"title": "Actual Cost", "value": "<COST>"}, {"title": "Expected", "value": "<EXPECTED>"}, {"title": "Deviation", "value": "<DEVIATION>%"}, {"title": "Severity", "value": "<SEVERITY>"} ]} ], "actions": [{"type": "Action.OpenUrl", "title": "View in SRE Agent", "url": "https://sre.azure.com/agents/subscriptions/<sua-subscricao>/resourceGroups/finopshub-rg/providers/Microsoft.App/agents/finopshub/views/thread/7314d219-77d6-4e12-a3fb-f30606d13077"}] } }] } req = urllib.request.Request(webhook_url, data=json.dumps(card).encode('utf-8'), headers={'Content-Type': 'application/json'}, method='POST') response = urllib.request.urlopen(req) ``` ## Step 5: Report in Thread Always post a summary in this thread with: - Whether anomalies were found or not - Key metrics and trends - If no anomalies: "No material cost anomalies detected. Daily costs within expected range." ## Constraints - Read-only operations only against ADX - Max 5 KQL queries per execution - Do not modify any Azure resources ## Idempotence If no anomalies detected in the last 7 days and costs are within normal thresholds, output: "No material cost anomalies detected. Daily costs within expected range." ## Escalation If anomalies are detected for 3+ consecutive days, flag as HIGH severity in the Teams notification and recommend immediate investigation.

⑥ Notificação no Teams (Adaptive Card)

Quando anomalias são detectadas, o SRE Agent envia um Adaptive Card rico para o Teams:

⚠️ AZURE COST ANOMALY DETECTED
🔴 HIGH — 2026-04-21
Custo Real	$1,847.32
Custo Esperado	$623.15
Desvio	+196.5% (↑ $1,224.17)
Score Anomalia	4.7 (threshold: 1.5)

🟡 MEDIUM — 2026-04-20
Custo Real	$987.44
Desvio	+59.5% (↑ $368.54)
📊 Trend (7d)	$601 → $615 → $622 → $619 → $987 → $1,847

Exemplo de Adaptive Card enviado ao canal do Teams

O card inclui botões: Ver Detalhes no SRE Agent e Abrir FinOps Hub (ADX) para investigação.

⑦ Testar a Integração (Simular Anomalia)

Antes de confiar no agendamento, teste pedindo ao SRE Agent:

"Simular uma anomalia de custo para eu receber no Teams"

O agente enviará um Adaptive Card de teste com dados simulados para validar que o webhook está funcionando.

Dica: Se o webhook retornar erro 400 - WorkflowTriggerIsNotEnabled, ative o flow em: Power Automate → My flows → Turn on.

Como Funciona no Dia a Dia

Horário	Ação	Resultado
08:00 UTC	SRE Agent executa query KQL no ADX	Dados de custo (12 meses)
08:01 UTC	Análise de anomalias (últimos 7 dias)	Identifica spikes e drops
08:02 UTC	Se anomalia → Teams notification	Adaptive Card no canal
08:02 UTC	Se normal → log no thread	"Custos dentro do esperado"
Contínuo	3+ dias anomalia → escalação HIGH	Investigação recomendada

Gerenciamento da Task

Após criada, a tarefa pode ser gerenciada pelo SRE Agent:

Pausar: "Pausar a tarefa de anomalia de custo"
Retomar: "Retomar a tarefa"
Alterar horário: "Mudar para executar às 10h UTC"
Ver histórico: "Mostrar histórico de execuções"
Cancelar: "Cancelar a tarefa de anomalia"

Conclusão

Com essa configuração, você tem um sistema inteligente de vigilância de custos que:

🔍 Analisa 12 meses de histórico para detectar padrões sazonais

🤖 Usa ML nativo do Kusto — sem infraestrutura adicional

📱 Notifica proativamente no Teams — só quando há anomalia

📈 Escala automaticamente a severidade em anomalias persistentes

💬 Mantém histórico completo no thread do SRE Agent

🔧 É gerenciável por linguagem natural — sem YAML, sem pipelines

A combinação FinOps Hub + Azure SRE Agent + Teams transforma a governança de custos de reativa (olhar dashboards) em proativa e automatizada.

🚀 Quer implementar na sua organização?

Se você quer testar, o Azure SRE Agent está disponível como preview. Configure um agente na sua subscription e comece a conversar em linguagem natural.

Já usa FinOps Hub? Conte nos comentários como você monitora anomalias de custo hoje!

#FinOps #Azure #SREAgent #CostManagement #AzureDataExplorer #CloudGovernance #DevOps #MicrosoftTeams #AIOps

Uso de contextos no Entra ID

wdossantos — Thu, 23 Apr 2026 12:53:59 GMT

Visão Geral

Com a crescente necessidade de segurança adaptativa, o Microsoft Entra ID oferece recursos avançados para aplicar políticas dinâmicas de acesso. Em cenários corporativos, autenticação e autorização tradicionais, baseadas apenas em roles e claims estáticos, nem sempre são suficientes. Imagine que um usuário já está logado e possui permissão para acessar uma API, mas você precisa garantir que, para uma operação crítica como deletar um registro, ele esteja dentro da rede corporativa, em um dispositivo gerenciado ou tenha assinado um termo de confidencialidade. É exatamente isso que os contextos de autenticação do Microsoft Entra ID resolvem.

Neste artigo vou detalhar todo o processo, desde a habilitação do Continuous Access Evaluation (CAE), passando pela configuração dos contextos e das políticas de acesso condicional no portal do Entra ID, até a integração prática com uma aplicação .NET dividida em frontend web e API de backend. No código, veremos como o MSAL intercepta o fluxo, verifica se o token contém a claim acrs com o contexto exigido e, caso não contenha, dispara um challenge que leva o usuário de volta ao Entra ID para cumprir o requisito adicional. Se o contexto já estiver satisfeito, o fluxo é transparente para o usuário.

O objetivo é destacar a granularidade no controle de acesso, a estrutura de contexto, os desafios de implementação e potenciais aplicações práticas.

Diagrama de Arquitetura

1. Caso de Uso

Para exemplificar, utilizamos uma aplicação .NET simples, dividida em dois componentes:

API de backend, que expõe endpoints protegidos
Aplicação web frontend, que consome a API via tokens

Fluxo Básico

A aplicação web é protegida pelo Entra ID
Ao iniciar, o MSAL (SDK de identidade da Microsoft) verifica se o usuário está autenticado
Se não estiver, solicita a autenticação
Após autenticado, a aplicação armazena um token para consumir a API

O Diferencial

Não basta um token de acesso convencional para consumir um endpoint específico da API. É necessário um token com uma claim especial (acrs), contendo exatamente o valor do contexto esperado.

2. Configuração do Entra ID

App Registration e Contextos

O processo inicia com o registro das aplicações (cliente e API) no Entra ID, mantendo as etapas tradicionais de permissionamento e definição de escopos.

A novidade está na configuração de contextos, que são pares chave-valor criados no Entra ID e utilizados em políticas de acesso condicional.

Pré-requisito: Licença Entra ID P1 para uso de acesso condicional.

O contexto é configurado em uma aba específica dentro das políticas de acesso condicional.

Ao criar um novo contexto, define-se o nome, descrição e o ID sequencial (ex: c1). O checkbox "Publish to apps" torna o contexto disponível para as aplicações consumirem:

Estrutura e Limitações dos Contextos

Aspecto	Detalhe
Identificação	Número sequencial (ex: c1, c2, até c99)
Limite	Vinculado ao número máximo de regras de acesso condicional (195)
Composição	Nome + Descrição
Utilidade	Depende da implementação na aplicação

Aplicação Prática dos Contextos

O contexto permite granularidade adicional além das tradicionais roles e claims do token JWT:

Rede corporativa: restringir acesso a uma área apenas para usuários dentro da rede interna
Dispositivos gerenciados: exigir que o dispositivo esteja em compliance
Assinatura de termos: exigir ações adicionais (ex: NDA) antes do acesso a dados sensíveis, mesmo que o token permita o acesso

Por fim, o contexto é vinculado a uma política de acesso condicional. No exemplo abaixo, a policy "Teste - C10" associa o contexto "Teste WebApp" como target resource:

3. Implementação no Código

3.1 Configuração no Cliente (Startup.cs)

No processo de inicialização, utiliza-se o método AddMicrosoftIdentityWebAppAuthentication para configurar a autenticação, incluindo o parâmetro ClientCapabilities, que habilita o uso de contexto.

Além disso, é adicionado o handler MicrosoftIdentityConsentAndConditionalAccessHandler para gerenciar o fluxo de acesso condicional.

// Habilita autenticação com suporte a contexto e acesso condicional services.AddMicrosoftIdentityWebAppAuthentication(Configuration) .EnableTokenAcquisitionToCallDownstreamApi( Configuration.GetSection("TodoList:Scopes").Get<string[]>() ) .AddInMemoryTokenCaches(); // Handler para gerenciar challenge de acesso condicional services.AddScoped<MicrosoftIdentityConsentAndConditionalAccessHandler>();

3.2 Configuração (appsettings.json)

O ponto-chave é o ClientCapabilities: ["cp1"], que habilita o suporte a Continuous Access Evaluation:

{ "AzureAd": { "Instance": "https://login.microsoftonline.com/", "Domain": "cyber.meudominio.com.br", "TenantId": "...-8888-4400-8c9c-...", "ClientId": "...-e635-...-bb9f-...", "CallbackPath": "/signin-oidc", "SignedOutCallbackPath": "/signout-oidc", "ClientCapabilities": [ "cp1" ], "ClientSecret": "XHm8Q~6_rNy_ib-....~KbcvF" } }

A classe Configuration, passada para AddMicrosoftIdentityWebAppAuthentication, localiza e carrega automaticamente a seção AzureAd do arquivo de configuração.

3.3 Método Crítico: Validação do Contexto

No endpoint crítico (ex: deletar item), o código verifica se o token do usuário contém a claim acrs com o valor do contexto exigido:

// GET: TodoList/Delete/5 public async Task<ActionResult> DeleteItem(int id) { string requiredAuthContextId = "c10"; string acrsClaimType = "acrs"; // Construção do claimsChallenge var claimsChallengeObj = new { id_token = new { acrs = new { essential = true, value = requiredAuthContextId } } }; string claimsChallenge = System.Text.Json.JsonSerializer.Serialize(claimsChallengeObj); // Verifica se o usuário possui o claim necessário Claim acrsClaim = User.FindAll(acrsClaimType) .FirstOrDefault(x => x.Value == requiredAuthContextId); if (acrsClaim?.Value != requiredAuthContextId) { // Dispara challenge para cumprir o contexto exigido _consentHandler.ChallengeUser( new[] { "api://ce845259-3c67-43c1-9816-43f82f4d7704/ToDoList.Read", "api://ce845259-3c67-43c1-9816-43f82f4d7704/ToDoList.ReadWrite" }, claimsChallenge ); } try { var todo = await _downstreamApi.GetForUserAsync<Todo>( "TodoList", options => options.RelativePath = $"api/todolist/{id}"); if (todo == null) return NotFound(); return View(todo); } catch (Exception) { return RedirectToAction("Index"); } }

Lógica do Fluxo

Claim presente e válida: a operação é permitida normalmente
Claim ausente: o ChallengeUser() abre a tela do Entra ID para o usuário cumprir o requisito (ex: MFA, assinatura de termo)
Contexto já satisfeito: o fluxo é transparente para o usuário

4. Fluxo de Challenge e Resposta

Do lado da API (Backend)

Quando o contexto não é atendido, a API retorna:

401 Unauthorized com headers customizados
Informações sobre o contexto exigido no corpo/headers da resposta

Do lado do Cliente (Frontend)

O cliente captura exceções específicas (WebApiMsalUiRequiredException)
Extrai informações do header da resposta
Executa o fluxo de challenge conforme necessário
Após cumprido o requisito, o token é renovado com a claim acrs

5. Considerações Finais

O uso de contextos no Entra ID amplia as possibilidades de controle de acesso, permitindo requisitos dinâmicos e contextuais além das roles tradicionais
A implementação exige integração cuidadosa entre backend e frontend, além de testes para garantir o correto tratamento dos fluxos de challenge e resposta
A documentação limitada reforça a importância de compartilhar experiências e boas práticas para fomentar o uso do recurso
Requer licença Entra ID P1 para acesso condicional

Referências

FinOps Hub Privado: Implementação Manual em Ambientes Corporativos

carolinamelo — Fri, 10 Apr 2026 16:51:20 GMT

O que é o FinOps Hub?

O FinOps Hub é uma solução open source da Microsoft, parte do FinOps Toolkit, que fornece uma base escalável e extensível para análise, governança e otimização de custos em nuvem. A solução centraliza dados de custos por meio de recursos de armazenamento e pipelines de dados, permitindo que as organizações padronizem a forma como analisam seus gastos na nuvem, adotando o modelo de dados FOCUS definido pela FinOps Foundation.

Além de disponibilizar relatórios e dashboards prontos, o FinOps Hub expõe os dados de custos de forma estruturada por meio do Azure Data Explorer ou do Microsoft Fabric, possibilitando a criação de relatórios customizados no Power BI e o desenvolvimento de soluções internas sob medida, de acordo com as necessidades do negócio.

Objetivo

Esse artigo visa orientar a implementação manual do acesso privado ao FinOps Hub após uma implementação pública, sem usar diretamente a opção de implementação privada oferecida pelo template.

Por que implementar o FinOps Hub com acesso privado de forma manual?

O template disponibilizado para a implementação do FinOps Hub permite que selecionemos duas formas de implementação:

Pública: forma de implementação mais simples e comum. Os recursos são provisionados com acesso público habilitado, sendo acessados por meio de seus endpoints públicos padrões do Azure. O controle de acesso é feito exclusivamente via permissões RBAC.
Privada: forma de implementação mais segura. Os recursos são provisionados com acesso público desabilitado e expostos apenas por meio de private endpoints, ficando acessíveis somente através de redes privadas que possuem conectividade com a rede onde esses endpoints estão implementados.

Embora a comunicação privada traga ganhos significativos de segurança, sua habilitação através do template do FinOps Hub introduz algumas implicações importantes no processo de implantação. O template, de forma automática, tenta:

Criar uma rede virtual (/26);
Provisionar Private DNS Zones;
Criar os registros DNS associados aos private endpoints;
Configurar os links entre as VNets e as zonas DNS.

Em muitas organizações, esse tipo de configuração é restrito por políticas internas. A criação de redes, zonas DNS e seus respectivos vínculos costuma ser responsabilidade de times especializados, que garantem a padronização e a aderência às diretrizes arquiteturais definidas pela empresa.

Em cenários onde a organização adota, por exemplo, uma topologia Hub & Spoke, com landing zones bem definidas para workloads e conectividade, é fundamental considerar alguns pontos adicionais:

Garantir que a rede criada para os private endpoints não tenha sobreposição (overlap) com outras redes existentes;
Assegurar que exista peering com a VNet de hub;
Integrar os registros DNS dos novos private endpoints às Private DNS Zones centralizadas;
Configurar corretamente os VNet links;
Garantir que a resolução de nomes esteja funcional no ambiente on-premises, permitindo o acesso ao FinOps Hub por meio de VPN, ExpressRoute ou outras formas de conectividade híbrida.

Esses fatores explicam por que, em muitos casos, o uso do template com configuração privada se torna inviável quando utilizado de forma isolada. Isso ocorre porque, frequentemente, o time de FinOps não é o mesmo time responsável por redes e DNS, possuindo permissão para implantar apenas parte dos recursos necessários.

Nesses cenários, a implementação privada exige a orquestração entre diferentes times, cada um atuando dentro de suas responsabilidades. Como resultado, algumas etapas que o template tenta executar automaticamente precisam ser realizadas manualmente, conforme descrito nas próximas seções.

Passo a Passo para Implementação

Faça a implementação do template seguindo o tutorial documentado, com “Networking” em modo público.
Assim que o template é implementado, alguns scripts de configuração são executados. Aguarde até que esses scripts sejam executados, ou seja, desapareçam do grupo de recursos onde o FinOps Hub foi implementado para seguir com os próximos passos. Exemplos dos “Deployment Scripts” que desaparecerão:

Crie uma rede de tamanho mínimo /26 – valide com o time de infraestrutura o espaçamento que pode ser utilizado. Dentro dessa rede implemente uma subrede:
- private-endpoint-subnet (/28) – subrede para os private endpoints.
Garanta a existência das Private DNS Zones: se seu ambiente possui zonas de DNS privadas centralizadas pré-configuradas. Garanta que as seguintes zonas já existam na subscription padrão para os seus recursos de rede:
- privatelink.blob.core.windows.net– para o Data Explorer e storage
- privatelink.dfs.core.windows.net– para o Data Explorer and o data lake hospedando os dados de FinOps data e configuração das pipelines
- privatelink.table.core.windows.net– para Data Explorer
- privatelink.queue.core.windows.net– para o Data Explorer
- privatelink.{location}.kusto.windows.net– para Data Explorer

Configurando a Storage Account com Acesso Privado

O primeiro recurso que a ser configurado será a Storage Account.

A configuração a seguir deve ser realizada duas vezes uma para o target sub-resource “blob” e outra para o target sub-resource “dfs”.
- Acesse “Networking” e a aba “Private Endpoints”
- Na aba “Basics” defina:
  - Subscription: mesma que o FinOps Hub foi implementado
  - Resource Group: mesmo que o FinOps Hub foi implementado
  - Name: use um nome que remeta ao recurso criado (private endpoint) e o sub recurso que ele fará exposição (blob/dfs). Exemplo: pe-storageaccount-blob/ pe-storageaccount-dfs
- Na aba “Resource” defina o target sub-resource para o qual a configuração está sendo feita. No caso, primeiro foi feito para “blob” e depois “dfs”.
- Na aba “Virtual Network”, deve-se selecionar a rede criada para os private endpoints bem como a subrede (private-endpoint-subnet).
- Na aba “DNS” selecione a private DNS zone na qual são realizados os registros do seus private endpoints. Quando estiver configurando o private endpoint para blob será privatelink.blob.core.windows.net e para dfs privatelink.dfs.core.windows.net.
- Adicione Tags caso seja necessário.
- Clique em “Review + create”.
- Ao final, dois private endpoints devem estar criados para a storage account:

Agora será necessário configurar o private endpoint usado pelo Data Factory para acessar a Storage Account.
- Acesse o Data Factory e clique em "Launch Studio".
- No menu lateral, selecione a opção "Manage" -> "Linked services":
- Selecione o serviço correspondente ao Azure Data Lake Storage Gen2.
- Em “Connect via integration runtime” substitua “AutoResolveIntegrationRuntime” por New+:
- Em “Integration runtime setup” selecione “Azure” -> Botão “Continue”:
- Na aba “Settings”, apenas altere o campo “Name”. Use algo como “ManagedIntegrationRuntime”. Os demais campos, mantenha como estão:
- Na aba “Virtual Network”, configure conforme a imagem abaixo:
- Por fim, na aba “Data flow runtime”, use as configurações abaixo:
- Clique em “Create”.
- Agora, voltando a página “Edit linked Service”, adicione o “Managed Private Endpoint”. Ele ficará em estado “Pending”.
- Clique em “Save”.
- Além disso, use a managed identity fornecida na página “Edit linked Service”, e lhe dê os seguintes acessos na storage account:
  - Reader
  - Storage Account Contributor
  - Storage Blob Data Contributor
- Por fim, acesse a seção “Networking” da Storage Account novamente, selecione o private endpoint criado pelo Data Factory e clique no botão “Approve”.

Configurando o Linked Service ftkRepo no Data Factory

Voltando na seção “Manage” do Azure Data Factory, será necessário editar o serviço “ftkRepo”. Nele, o único campo a ser alterado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account.

Clique em “Save”.

Configurando o Azure Data Explorer com Acesso Privado

Acesse a seção “Networking” cluster do Data Explorer criado pelo script do FinOps Hub e acesse a aba “Private Endpoint Connections”
Clique em “+ Private Endpoint”.
Em “Basics” inclua um nome para o private endpoint e garanta que a região selecionada é a de implementação do seu FinOps Hub e da vnet criada para ele.
Na aba “Virtual Network” selecione a rede e subrede criadas para os private endpoints.
Na aba “DNS”, associar cada configuração a sua private DNS zone correspondente. Se essas zonas já existirem no ambiente e forem utilizadas de forma centralizada, usar as existentes. Caso contrário, a configuração poderá criar private DNS zones novas:
Novamente será preciso configurar o private endpoint gerenciado pelo Data Factory. Para isso, acesse “Managed” -> “Linked Services” e selecione o serviço referente ao Azure Data Explorer.
Nessa seção, o único campo a ser editado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account.
Agora ainda em “Manage” no Data Factory, selecione a opção “Managed Private Endpoints”. Clique em “+New” -> “Azure Data Explorer (Kusto)”
Forneça um nome para o private endpoint, marque a subscription na qual o Data Explorer foi implementado e em "Cluster" selecione o recurso implementado via template do FinOps Hub:
Ao final, deve-se ter dois private endpoints configurados no Azure Data Explorer:

Ajustes Finais e Validações de Conectividade

Tanto para a Storage Account quanto para o Data Explorer, acesse as configurações de rede e altere o Public network access para “Disabled”.
Por fim, no seu servidor local de DNS, crie o registro para o Data Explorer apontando para o forwarder correto no Azure seja ele uma máquina virtual ou o inbound endpoint do Azure Private Resolver. Não use o domínio com privatelink, mas sim o padrão, no caso do Data Explorer a forma geral é <localização>.kusto.windows.net conforme o exemplo abaixo:

Ao configurar os apontamentos corretamente, será possível configurar os dashboards em máquinas locais/on-premises que tenham acesso privado ao ambiente Azure. Os dashboards precisam ser capazes de resolver a URL do cluster Data Explorer que é apontado como parâmetro do Dashboard em PowerBI.
Se desejar validar a comunicação antes de configurar o dashboard de Power BI, teste da sua máquina local a resolução da URI do Data Explorer implementado para o FinOps Hub, usando nslookup conforme o exemplo abaixo.

Segurança Corporativa no Azure VMware Solution (AVS): Como Inspecionar o Tráfego com Firewall NVA

LeandroBarbosa — Wed, 11 Mar 2026 14:50:40 GMT

Muitas vezes faz sentido usar uma NVA (Network Virtual Appliance) como firewall dentro do AVS, porque permite reaproveitar a solução de firewall já existente (Palo Alto, Check Point, etc..) e manter a proficiência do time de segurança, evita parte da complexidade de roteamento que pode surgir ao forçar o tráfego passar por um firewall “fora” do AVS . Além disso, administrar esse firewall dentro do AVS continua familiar para quem já opera VMware, e você ganha acesso a recursos avançados de inspeção do fabricante (como filtragem por aplicação em camada 7 e inspeção SSL/TLS), que são muito úteis para controle de tráfego outbound e políticas corporativas.

Neste artigo eu demonstro e um laboratório prático de inspeção de tráfego Norte-Sul e Leste-Oeste, fazendo isolamento por ambiente (DEV/PRD) dentro do Azure VMware Solution (AVS) usando NSX-T (Tier-0/Tier-1) e um Firewall NVA (pfSense) implantado no SDDC. Também serão demonstradas as principais configurações no NSX (criação/associação de segments, gateways T0/T1 e ajustes de roteamento necessários para forçar o tráfego a passar pela NVA).

Arquitetura

Informações do Laboratório

Segmentos de Trânsito

Transit_Outside | CIDR: 192.168.30.0/24 | GW: 192.168.30.1
Transit_PRD | CIDR: 192.168.21.0/24 | GW: 192.168.21.1
Transit_DEV | CIDR: 192.168.22.0/24 | GW: 192.168.22.1

Segmentos de Workloads

PRD_WEB | CIDR: 192.168.70.0/24 | GW: 192.168.70.1
PRD_DATA | CIDR: 192.168.71.0/24 | GW: 192.168.71.1
DEV_WEB | CIDR: 192.168.80.0/24 | GW: 192.168.80.1
DEV_DATA | CIDR: 192.168.81.0/24 | GW: 192.168.81.1

Interfaces da NVA (pfSense)

Transit_Outside: 192.168.30.5
Transit_PRD: 192.168.21.5
Transit_DEV: 192.168.22.5

Configuração do Azure VMware Solution

Na configuração Internet connectivity (egress/ingress) do Azure VMware Solution (AVS) irei utilizar a opção "Connect using Public IP down to the NSX Edge". Isso permite usar o NSX Data Center para criar regras de outbound e inbound (DNAT/SNAT) usando esses IPs públicos diretamente no Edge do AVS.

Configuração de SNAT e NoSnat no NSX

Regras “No SNAT” : Define que não deve haver tradução de origem quando o tráfego vai para redes privadas RFC1918. Isso preserva o IP original de origem para comunicação interna (ex.: on-prem, Azure, spoke VNets/rotas privadas), evita quebra de roteamento/retorno.
Regra “SNAT”: Aplica tradução de origem para o restante do tráfego (Internet). Ou seja, quando uma VM com IP privado sai para fora, o NSX troca o IP de origem pelo IP público configurado ( 20.20.138.0/32).

Criação dos Gateways TIER-1 (PRD e DEV).

Importante: Estes gateway são "Isolados", portando não serão conectados ao TIER-0

T1_PRD_Isolado

T1_DEV_Isolado

Resultado

Criação dos Segmentos de Trânsito PRD e DEV

Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_Isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior

TRANSIT_PRD

TRANSIT_DEV

Criação do Segmento PRD WEB e DATA

Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior

PRD_WEB

PRD_DATA

DEV_WEB

DEV_DATA

Visão Geral dos Segmentos

Configuração de Rotas

Rotas no Gateway T1 Default

No Gateway T1 Default que está conectado ao T0 , irei configurar rotas para todos os segmentos com Next Hop ao ip da interface Outside do meu PFsense (192.168.30.5) .

obs: o nome do gateway T1 é diferente em cada AVS SDDC, no meu ambiente é "TNT13-T1"

Informei o CIDR da Rede , neste caso é para o segmento TRANSIT_PRD

Next Hop aqui é o ip da interface Outside do PFsense ( 192.168.30.5) , que está conectada diretamente a este GW T1.

Repeti os mesmos passos para todos os outros Segmentos, sempre com next hop para 192.168.30.5.

Interfaces Firewall Pfsense

Neste cenário o Firewall possui apenas três interfaces.

Deve ser configurada a rota default ( 0.0.0.0/0) para o gateway do Segmento Transit Outside ( 192.168.30.1)

Interfaces do Pfsense

Rotas no Gateways de Transito : T1_PRD_isolado

Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.21.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1

Configuração da Rodas default

Next Hop para ip da Interface Inside PFsense.

Rotas no Gateways de Transito : T1_DEV_Isolado

Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.22.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1

Configuração da Rodas default

Next Hop para ip da Interface Inside PFsense.

Teste de Acesso

Tráfego Norte-Sul ( Saída Internet)

Para comprovar que conseguimos agora ter o tráfego Norte-Sul, pelo NVA PFense , irei fazer um teste a partir da máquina no segmento PRD_WEB , com ip 192.168.70.1

É possivel observar que o ip públlico de saída é do AVS

Agora vou criar uma regra no Pfsense bloqueando a porta 443 , mas deixando liberada as outras portas.

Podemos comprovar que o tráfego está sendo inspersionado fazendo um teste de conexão na porta 53 e outro teste https.

No Pfsense podemos ver o bloqueio

Tráfego Leste-Oeste

Para testar o tráfego leste oeste entre os Segmentos PRD_WEB ( VM 192.168.70.10 ) e DEV_WEB ( VM 192.168.80.10) , irei deixar ICMP liberado e bloquear a porta 3389 ( RDP)

Fazendo o teste a partir da máquina 192.168.70.10

Verificando no PFsense o bloqueio da porta 3389

Resumo

Neste laboratório demonstrei como integrar uma NVA ao Azure VMware Solution usando NSX-T com Tier-0/Tier-1, criando T1s isolados para DEV e PRD, segments de trânsito e a configuração de SNAT/NoSNAT no NSX para controlar o egress. Também mostrei o ajuste de rotas para garantir que o tráfego siga pelo caminho de inspeção no firewall. Validei a arquitetura com testes práticos de tráfego Norte-Sul (saída para Internet com IP público do AVS) e Leste-Oeste (controle entre DEV e PRD), comprovando a inspeção via logs e bloqueios aplicados no pfSense. Como próximos passos para produção, recomenda-se padronizar regras, logging, e revisar resiliência/HA do firewall e rotas para reduzir pontos únicos de falha.

Referências

Anonimização de Dados Sensíveis com a plataforma de IA do Azure

anaritak — Fri, 26 Dec 2025 17:51:22 GMT

A Lei Geral de Proteção de Dados (LGPD) estabelece padrões rigorosos para o tratamento de dados pessoais e sensíveis no Brasil. Dados pessoais incluem informações que identificam diretamente um indivíduo, como nome, endereço, telefone, CPF, RG e data de nascimento. Já os dados sensíveis abrangem categorias especiais, como origem racial ou étnica, crenças religiosas, opiniões políticas, dados de saúde ou genéticos, biometria, orientação sexual e filiação sindical. Esses dados exigem cuidados adicionais, pois impactam diretamente a privacidade e os direitos dos titulares.

No contexto do processamento e compartilhamento de documentos — especialmente em setores como o público e o médico — é essencial reconhecer e classificar corretamente esses tipos de dados. Documentos oficiais ou registros de saúde frequentemente contêm tanto informações pessoais quanto dados altamente sensíveis, tornando a anonimização uma necessidade prática além de uma exigência legal.

Proposta de Arquitetura

Para atender à demanda de anonimização de dados sensíveis em documentos, soluções modernas de inteligência artificial, como Azure Document Intelligence e Azure Language Service, oferecem capacidade para detectar e classificar automaticamente informações pessoais. Esses serviços aceleram o processo de proteção de dados, mas seus modelos genéricos podem não abranger totalmente todas as categorias previstas pela LGPD — especialmente aquelas mais complexas ou dependentes de contexto, como opiniões políticas, crenças religiosas ou informações específicas de saúde.

Um caso simbólico pode ilustrar esse cenário: imagine uma plataforma responsável pelo armazenamento e compartilhamento de documentos administrativos. Para garantir que conteúdos sensíveis possam ser divulgados sem violar a privacidade das pessoas citadas, é possível implementar uma solução de anonimização baseada em IA. Ao utilizar modelos genéricos dos serviços de linguagem do Azure, conseguimos cobrir aproximadamente metade das classes previstas na LGPD, mas essas já abrangem a maior parte das classes determinísticas da legislação.

Abaixo, a arquitetura sugerida é detalhada de forma segmentada:

Azure Document Intelligence

O Azure Document Intelligence compõe a primeira camada do processamento, responsável por extrair texto, estrutura e coordenadas dos elementos presentes nos documentos — como tabelas, formulários, assinaturas e marcações visuais. Essa leitura estrutural permite compreender não apenas o que está escrito, mas onde cada informação se encontra.

A escolha por esse serviço se deve à sua capacidade de fornecer OCR avançado, interpretar layouts complexos e identificar elementos adicionais, como códigos de barras e QR Codes, que muitas vezes carregam metadados sensíveis. Esse mapeamento preciso é essencial para aplicar anonimização diretamente nas regiões corretas, preservando a integridade visual do documento.

Azure Language Service — PII e Classificação

Nesta segunda etapa, o Azure Language Service é utilizado para identificar automaticamente informações pessoalmente identificáveis (PII), como nomes, endereços, dados de contato e números de documentos. O modelo analisa o conteúdo com foco semântico, classificando entidades conforme categorias previstas na LGPD.

A motivação para empregá-lo está em sua capacidade de fornecer uma base abrangente e pronta para uso, permitindo detectar rapidamente grande parte dos dados sensíveis encontrados em documentos reais. Isso reduz a necessidade de regras manuais e acelera o processo de anonimização.

Azure Language Service — Modelos Personalizados (Custom NER)

Embora os modelos genéricos atendam a boa parte dos cenários, documentos reais costumam conter entidades específicas do domínio — expressões próprias da instituição, cargos incomuns, nomes de sistemas internos, termos de contexto ou siglas não previstas pelo modelo padrão.

Para suprir essas lacunas, são usados modelos personalizados de Reconhecimento de Entidades Nomeadas (NER). Eles permitem treinar novas categorias sensíveis e adaptar o processamento à realidade da organização. A motivação principal é reduzir falsos positivos/negativos e garantir maior precisão nos casos de uso mais complexos.

Azure Computer Vision

Quando documentos incluem imagens, fotografias ou capturas de telas, a anonimização precisa ir além do texto. O Azure Computer Vision é utilizado para detectar rostos e outras características visuais que possam identificar indivíduos.

Sua inclusão no processamento permite aplicar desfocagem ou mascaramento diretamente nos elementos encontrados, garantindo proteção também em conteúdo multimídia. Isso se torna especialmente relevante em documentos digitalizados que podem conter retratos, crachás, assinaturas digitalizadas ou imagens que exponham a identidade de terceiros.

Orchestrator Python — Lógica de Anonimização Baseada em Coordenadas

A última camada da solução é desenvolvida em Python, responsável por orquestrar os serviços de IA e aplicar a anonimização final no documento. Com base nas coordenadas extraídas pelo Document Intelligence e nas entidades classificadas pelo Language Service, o componente Redaction realiza o mascaramento diretamente sobre a área correspondente.

A escolha pelo Python se justifica pela sua flexibilidade, ampla disponibilidade de bibliotecas para manipulação de PDFs e imagens, e facilidade para integrar diferentes serviços do Azure em um único fluxo. Além disso, permite criar filtros adicionais — como evitar mascarar nomes de organizações ou estruturas fixas — garantindo precisão e consistência no resultado final.

Recomendações

Veja o repositório de uma demonstração simplificada com arquivos fictícios: Repo

Se você deseja implantar essa solução, pode utilizar o código disponível no repositório e adaptá-lo aos seus filtros e regras específicas. A estratégia recomendada é empacotar a aplicação em contêineres para facilitar a escalabilidade e a integração com diferentes ambientes.

Além disso, é possível consumir os serviços do Azure diretamente via APIs, garantindo flexibilidade na arquitetura e integração com outras aplicações. Todas essas informações, incluindo exemplos e orientações detalhadas, estão disponíveis na documentação oficial dos serviços Azure.

Essa abordagem integrada garante que documentos públicos possam ser compartilhados de forma segura, respeitando a legislação e protegendo a privacidade das pessoas. A evolução para modelos personalizados representa um salto importante, permitindo identificar e anonimizar dados que hoje passam despercebidos pelos modelos padrão, elevando o nível de conformidade e confiança no tratamento de dados sensíveis.

Agradecimentos

Agradeço especialmente ao Gilberto Santos, meu colega Cloud Solution Architect Linkedin, pela generosidade em compartilhar sua expertise sobre os serviços do Azure e pelo apoio essencial no desenvolvimento desta arquitetura.

Também registro meu agradecimento ao Alexandre Teoi, Cloud Solution Architect Linkedin, pela revisão criteriosa e pelas contribuições valiosas para o aprimoramento deste artigo.

Protegendo Máquinas no Azure VMware Solution com Azure Firewall

LeandroBarbosa — Fri, 17 Oct 2025 20:49:10 GMT

O Azure VMware Solution oferece três opções principais de conectividade outbound para a Internet.

A primeira é o Managed SNAT, opção padrão e totalmente gerenciada pela plataforma, em que o próprio AVS realiza a tradução de endereços (SNAT) para permitir o acesso à Internet. Essa abordagem é simples e não requer configuração adicional, porém não oferece controle sobre os endereços IP públicos utilizados.

A segunda opção é o uso de Public IPs no NSX-T Edge, onde o administrador atribui endereços públicos diretamente ao edge do ambiente AVS. Com isso, o tráfego de saída das máquinas virtuais utiliza esses IPs específicos, permitindo maior controle, ideal para cenários em que é necessário manter IPs fixos ou previamente autorizados em listas de acesso externas.

Por fim, há a opção de rotear o tráfego via rede Azure (ou Azure Virtual WAN), em que uma rota padrão é anunciada por meio do ExpressRoute, direcionando o tráfego de saída para uma rede Azure que contém NVAs, Azure Firewall ou proxies. Essa abordagem oferece o maior nível de controle e segurança, pois permite aplicar inspeção, políticas e NAT centralizados, de forma integrada à arquitetura de rede do cliente.

Neste artigo será demonstrado em um ambiente de laboratório como utilizar o Virtual Wan com Azure Firewall para inspeção do tráfego de saída das Vms em um segmento do AVS

A arquitetura do laboratório.

Virtual Wan com Azure Firewall
ER Gateway conectado ao Express Route do Azure VMware Solution

Os passos necessários são:

Configuração da opção de Internet Connectivity do AVS
Habilitar a propagação da Rota no Vwan
Configuração do Routing Intent

Configuração do Azure VMware Solution.

Acesse o Private Cloud no portal do Azure e certifique que a opção abaixo esteja selecionada.

Fazendo um "dump" das rotas no T0 do NSX, é possível verificar que não temos a rota default sendo propagada.

Portanto não temos conectividade para internet a partir da máquina VM1 que está no AVS.

Habilitando a propagação da Rota default no Virtual Wan

Devemos agora habilitar a propagação da rota default pelo Virtual Wan , e para isso é necessário editar a conexão do Express Route do AVS, conectado ao Hub do Vwan .

Habilite a propagação da Rota default

Routing Intent

O Routing Intent no Azure Virtual WAN é um recurso que simplifica e automatiza o roteamento de tráfego dentro do hub do Virtual WAN. Ele define como o tráfego entre redes (VNets, branches, e Internet) deve ser direcionado, sem necessidade de configurar manualmente tabelas de rotas complexas

Observação: Em geral, no Brasil, caso já exista um Express Route On-premises, o Routing Intent já deve estar ativado para permitir o tráfego na comunicação com o Express Route do AVS, devido a não disponibilidade na região do Brasil do Express Route Global Reach

Nas configurações do HUB, habilite o Routing Intent.

Fazendo um novo "dump"das rotas BGP no NSX, agora é possível observar a rota default sendo propagada.

Testando a partir da VM no AVS

Conforme esperado é o mesmo IP público do meu Firewall no Vwan

Nos Logs do Azure Firewall, comprovamos que o tráfego da VM (10.145.0.10) realmente está passando pelo Azure Firewall

Referências: https://learn.microsoft.com/en-us/azure/azure-vmware/disable-internet-access

Alta Disponibilidade e Resiliência com App Gateway e Múltiplos APIMs: Uma Arquitetura Estratégica

wdossantos — Tue, 09 Sep 2025 18:54:23 GMT

Resiliência como Pilar do Azure Well-Architected Framework

A resiliência é um dos pilares fundamentais do WAF e desempenha papel crítico na construção de arquiteturas modernas em nuvem. Este artigo explora o design de alta disponibilidade (HA) utilizando a oferta Premium Tier do Azure API Management (APIM) em cenários multi-região ou mesmo intra-região, com foco na aplicação de Availability Zones — uma prática recomendada no pilar de Confiabilidade.

A configuração Premium permite que as regiões primária e secundária compartilhem a mesma instância de APIM. No entanto, dependendo dos requisitos de negócio e tolerância a falhas, pode ser estratégico operar com duas instâncias separadas, garantindo continuidade de serviço mesmo diante de falhas regionais ou em uma das instâncias. Essa abordagem está alinhada ao modelo de DR Ativo-Ativo, promovendo tolerância a falhas, escalabilidade horizontal e resiliência operacional, conforme descrito no modelo de maturidade de confiabilidade.

A imagem acima representa os componentes do APIM nas regiões primária e secundária. Em cenários com instâncias separadas, esses componentes também estariam presentes em cada região. Já em uma configuração com Availability Zones, os elementos podem escalar dentro da mesma região, conforme a demanda — prática que também se conecta ao pilar de excelência operacional , ao permitir automação e monitoramento contínuo.

O fluxo de comunicação entre a API e os serviços de backend pode ocorrer por rotas diretas ou por meio de balanceadores de carga, dependendo do caso de uso. Essa arquitetura inspirou uma solução personalizada para um de nossos clientes, que buscava alta disponibilidade com baixa latência, mesmo em cenários de falha regional.

Configuração do APIM como gateway de saída para o cluster de aplicações

Press enter or click to view image in full size

Em alguns casos, por questões de compliance, não é possível operar fora de um regions específica . Ainda assim, essa arquitetura já proporciona ganhos significativos mesmo dentro da mesma região, como maior resiliência, escalabilidade e eficiência operacional.

Visão Geral da Arquitetura

Componentes principais:

Usuário: Inicia a requisição.
WAF: Protege contra ameaças e ataques na borda.
AKS: Gerencia APIs e aplicações containerizadas.
App Gateway (AppGW): Roteia o tráfego para os APIMs.
APIM001 e APIM002: Instâncias do Azure API Management, com IPs distintos e potencialmente em regiões diferentes.
Sistemas legados (kubernets / VMS): Integração com sistemas on-premises.

Essa arquitetura é interessante, pois, neste caso de uso, o APIM atua como ponto de saída do cluster de aplicações — exatamente o caminho crítico que queremos proteger

Com duas instâncias de APIM atrás do AppGW, é possível:

Realizar manutenções planejadas em uma instância sem impactar os usuários.
Redirecionar o tráfego automaticamente para a instância saudável.
Garantir zero downtime, mesmo durante atualizações críticas.

Essa abordagem é especialmente útil em ambientes com alta exigência de SLA, como bancos, governo e telecom.

Testes Blue-Green com Segurança e Controle

A arquitetura permite implementar estratégias Blue-Green com facilidade:

Uma instância do APIM pode representar o ambiente “Blue” (produção atual).
A outra instância representa o ambiente “Green” (nova versão).
O AppGW pode direcionar parte do tráfego para o ambiente Green para testes controlados.
Após validação, o tráfego pode ser totalmente migrado para o Green, promovendo a nova versão com segurança.

Isso reduz riscos de regressão e permite deploys mais confiáveis

Redução de Riscos em Caminhos Críticos

Ao distribuir o tráfego entre dois APIMs:

Reduz-se o risco de ponto único de falha.
A arquitetura se torna mais resiliente a falhas regionais ou de serviço.
Em caso de falha de uma instância, o AppGW garante continuidade do serviço.

Essa redundância é essencial para caminhos críticos de negócio, como autenticação, transações financeiras ou integrações com sistemas legados.

Outros Benefícios Estratégicos

✅ Disaster Recovery Ativo-Ativo

As duas instâncias do APIM funcionam simultaneamente em modo ativo-ativo.
Em caso de falha em uma das instâncias, o tráfego é automaticamente redirecionado.
Reduz significativamente o RTO e assegura a continuidade dos serviços..

✅ Mitigação de Esgotamento de IPs

O uso de múltiplas instâncias permite distribuir o consumo de IPs.
Evita gargalos de rede e problemas de limitação de recursos.

✅ Escalabilidade Regional

A arquitetura possibilita escalabilidade horizontal simplificada.
Suporta o crescimento de demanda em diferentes regiões de forma eficiente.

Como configurar o APPGW para uma POC de balanceamento entre dois APIMs

O Azure Application Gateway é um balanceador de carga de camada 7 (HTTP/HTTPS) que permite gerenciar o tráfego de aplicações web com inteligência, segurança e escalabilidade. Ele opera com base em um conjunto de configurações como Listeners, Routing Rules, Backend Targets entre outras.

Além disso, o Application Gateway oferece recursos avançados como WAF (Web Application Firewall), SSL offloading, redirecionamento baseado em caminho e afinidade de sessão, tornando-o ideal para cenários que exigem alta disponibilidade e proteção contra ameaças web.

Press enter or click to view image in full size

📦 Descrição de cada componente do diagrama

Listener (porta 80): Detecta conexões de entrada na porta especificada (ex: 80 para HTTP). É o ponto inicial onde o tráfego chega ao gateway.
Routing Rule: Define como o tráfego será roteado com base em critérios como URL, cabeçalhos ou métodos. É o cérebro da decisão de encaminhamento.
Backend Targets: Especifica os destinos finais para o tráfego, como VMs, instâncias de App Service ou containers. 🔁 Relação com Backend Pools: 1 para N — uma regra pode apontar para vários destinos.
Backend Setting: Configurações aplicadas ao tráfego, como tempo de timeout, protocolo (HTTP/HTTPS), e afinidade de sessão. 🔁 Relação com Health Probes: 1 para 1 — cada configuração tem uma sonda associada.
Backend Pools: Agrupamento lógico dos destinos (targets). Permite distribuir carga entre múltiplas instâncias. 🔁 Relação com Backend Targets: 1 para N — um pool pode conter vários destinos.
Health Probes (path:/status-0123456789abcdef)
Verifica a saúde dos destinos usando um caminho específico. Se um destino estiver inativo, ele é automaticamente removido do balanceador.

Vamos apresentar algumas telas de configuração e destacar pontos de atenção no Application Gateway (AppGW).

Um detalhe importante que acabei não mencionando: à frente do Listener existe uma configuração de Frontend IP, que define se o IP do AppGW será público ou privado. Para facilitar os testes iniciais, recomendo começar com o Frontend IP público,alem disso mantenha o Listener configurado na porta 80. Isso evita complicações com certificados SSL durante os testes.

Observe a imagem abaixo: o Frontend IP está corretamente vinculado ao Listener1, como indicado. Essa associação é essencial para garantir que o tráfego seja direcionado corretamente, conforme a configuração do IP público ou privado definida no Frontend.

Press enter or click to view image in full size

O Listener1, configurado na porta 80, está associado à Rule1, que define como o tráfego será roteado para o backend correspondente.

Press enter or click to view image in full size

A Rule1 está associada às configurações de Backend Settings, que definem como o tráfego será encaminhado para os recursos de backend — incluindo o pool de servidores, o protocolo, a porta e os critérios de saúde.

Press enter or click to view image in full size

As Backend Settings do Application Gateway incluem configurações importantes, como “Pick host name from backend target” e a associação a um Custom Probe.

Por padrão, o AppGW encaminha ao backend o mesmo cabeçalho HTTP Host recebido do cliente. No entanto, se o serviço ou aplicação no backend exigir um valor específico para o cabeçalho Host, é possível sobrescrevê-lo utilizando essa configuração. Com isso, o Application Gateway passa a usar o host do backend para resolver o balanceamento e validar o probe de integridade, garantindo compatibilidade com serviços que dependem de hostname específico para funcionar corretamente.

Press enter or click to view image in full size

Perceba que o Health Probe também está vinculado às Backend Settings, e utiliza a configuração “Pick host name from backend settings”.

Essa associação é fundamental para garantir que o probe de integridade seja executado corretamente, especialmente em cenários onde o backend exige um cabeçalho Host específico. Ao ativar essa opção, o Application Gateway passa a usar o hostname do backend tanto para o roteamento quanto para a validação do probe, assegurando compatibilidade com serviços que dependem dessa configuração.

Press enter or click to view image in full size

Esse endereço /status-0123456789abcdef é o endereço de sondagem do apim (helth cehck) do APIM

Voltando à Rule1, podemos observar que ela também define o Backend Target, que neste caso aponta para o serviço de backend do APIM (Azure API Management).

Essa configuração é essencial para garantir que o tráfego roteado pelo Application Gateway seja direcionado corretamente ao endpoint do APIM, respeitando as regras de roteamento, cabeçalhos e probes definidos nas Backend Settings.

Press enter or click to view image in full size

Nos Backend Pools, temos o pool de backend do APIM, que contém duas instâncias do serviço Azure API Management. Essa configuração permite distribuir o tráfego entre as instâncias, garantindo alta disponibilidade e escalabilidade para os serviços expostos via AppGW.

Press enter or click to view image in full size

Do lado do APIM

Para observar o processo de balanceamento entre instâncias do APIM (por exemplo, APIM A e APIM B), podemos criar uma API de mock que responda de forma simples, identificando qual instância está respondendo.

Principais Objetos do APIM

Políticas: São regras aplicadas às requisições HTTP, permitindo manipulações como transformação de payloads, controle de acesso, limitação de chamadas (rate limiting), entre outras.
API: Representa um conjunto de operações agrupadas sob um único endpoint. Cada API pode conter múltiplas operações.
Operações: São as ações HTTP específicas, como os verbos GET, POST, PUT, DELETE, etc. Cada operação define o comportamento de uma rota dentro da API.

Como criar um mock no Azure API Management (APIM)

Adicionar uma nova API

Acesse o menu lateral e clique em “Add API”.
Selecione a opção para criar uma API manualmente.
Na caixa de diálogo exibida, preencha os dados necessários (nome, URL base, etc.).

eu criei uma APIA, com sufixo apim

Press enter or click to view image in full size

Definir o response da operação

Clique em “add operation” e preencha o verbo como get a url como /moq
Após criar a operação desejada, clique na aba “Responses”.
Clique em “Add response” e selecione o código 200.
Em Content type, escolha application/json.
No campo Sample, insira um JSON de exemplo para identificar a instância, como:

JSON

{
"name": "APIMA"
}

Press enter or click to view image in full size

Adicionar a política de mock

Vá para a aba “Design” da operação.
Na seção Inbound processing, clique em “Add policy”.
Selecione a política “Mock response”.

Verificação

Após salvar, o pipeline da requisição exibirá uma tarja amarela, indicando que o mock está ativo.

Press enter or click to view image in full size

Repita esse processo para a instância dois. Agora já podemos testar o balanceamento de carga pelo Application Gateway

Press enter or click to view image in full size

Sincronização das Instâncias com o API OPS

Conforme mencionado no início deste artigo, a arquitetura “by the book” foi projetada para utilizar o recurso nativo de multi-região do Azure API Management (APIM), o que elimina a necessidade de esforços adicionais para sincronizar configurações entre instâncias.

No entanto, ao optarmos por manter duas instâncias separadas na mesma região, com o objetivo de obter os benefícios citados anteriormente, passamos a ter o desafio de manter ambas sincronizadas — ou seja, com as mesmas APIs, endpoints e políticas.

Para atender a essa necessidade de sincronização, utilizaremos o API Ops, que automatiza o processo de publicação e atualização das configurações entre as instâncias, garantindo consistência e reduzindo o risco de divergências operacionais.

Press enter or click to view image in full size

Resumo do Fluxo de API Ops para Sincronização com o APIM

Press enter or click to view image in full size

Operadores de API executam o pipeline de extração para sincronizar o repositório Git com a instância do API Management, populando o repositório com os objetos no formato necessário.
Se houver alterações detectadas na instância do APIM, é criado um Pull Request (PR) para revisão. Após aprovação, os operadores fazem o merge das mudanças no repositório.
Desenvolvedores de API clonam o repositório, criam uma branch e definem as APIs usando especificações OpenAPI ou ferramentas de sua preferência.
Quando um desenvolvedor envia alterações para o repositório, um novo PR é gerado para revisão.
O PR pode ser aprovado automaticamente ou revisado manualmente, conforme o nível de controle exigido.
Após a aprovação e o merge, o pipeline de publicação implanta as alterações na instância do API Management.
Os operadores também podem criar ou modificar políticas, diagnósticos, produtos e outros objetos relevantes, e então comitar essas alterações.
Após o merge, o pipeline publica as mudanças usando o processo de definição de APIs.

Conclusão

A adoção de uma arquitetura com App Gateway à frente de múltiplos APIMs, integrada com Akamai WAF, Azure Functions, Key Vault e sistemas legados, oferece uma solução robusta, segura e altamente disponível. Essa abordagem não apenas melhora a experiência do usuário, mas também reduz riscos operacionais e facilita a evolução contínua da plataforma.

Referencias

AKS - Problemas de desempenho do NGINX Ingress Controller Gerenciado

ClaudioGodoy — Fri, 05 Sep 2025 13:44:38 GMT

O NGINX ingress controller gerenciado é um complemento de roteamento que permite direcionar tráfego HTTP e HTTPS para aplicações executando em um cluster Azure Kubernetes Service (AKS).

Em problemas relacionados à performance, o sistema de roteamento pode ser a causa raiz. Este artigo fornece um guia passo a passo para solucionar problemas de performance do NGINX ingress controller.

Pré-requisitos

Antes de começar, certifique-se de ter as seguintes ferramentas instaladas:

Kubernetes CLI (kubectl): Use o Azure CLI para instalar executando o comando az aks install-cli.

Sintomas Comuns

Sintoma	Descrição
Erros de Gateway HTTP	Códigos de erro como 502, 504 podem indicar um problema de exaustão do NGINX.
Alta Diferença no Tempo de Resposta	Diferença significativa entre o tempo de resposta do seu serviço e o tempo de resposta fim a fim. Existe uma latência comum adicionada pelo NGINX, mas quando é muito grande, pode indicar exaustão do NGINX.

Passo 1: Verifique o Comportamento do HPA

A razão mais comum para problemas de performance no NGINX é exaustão de CPU. Durante picos de carga no sistema, uma boa abordagem é observar o comportamento do HPA. Por padrão, o plugin de roteamento cria um namespace chamado app-routing-system.

Obtenha o nome do HPA:
```
 kubectl get hpa -n app-routing-system
```

Observe o comportamento do HPA:

 kubectl get hpa <HPA_NAME> -n app-routing-system -w

Avalie o resultado:

 $ kubectl get hpa <HPA_NAME> -n app-routing-system -w

 NAME    REFERENCE          TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
 nginx   Deployment/nginx   cpu: 83%/70%   1         2         1          77m
 nginx   Deployment/nginx   cpu: 83%/70%   1         2         2          77m
 nginx   Deployment/nginx   cpu: 106%/70%        1         2         2          79m
 nginx   Deployment/nginx   cpu: 133%/70%        1         2         2          80m

A coluna TARGETS mostra o limite de CPU onde o HPA irá acionar o aumento de replicas. Você deve interpretar esse comportamento. Existem algumas possibilidades:

O HPA atingiu o número máximo de pods.
Não há nodes disponíveis para agendar os pods.

Passo 2: Procure por Pods em Estado Pending

Se no passo anterior você viu que o NGINX HPA não atingiu o número máximo de pods, o kube-scheduler pode estar tendo dificuldades para encontrar nodes disponíveis para agendar os pods do NGINX.

Obtenha Pods em Pending:

 kubectl get pod --field-selector=status.phase=Pending -n app-routing-system

Se houver pods em Pending, o cluster provavelmente está enfrentando um problema de exaustão de recursos. Nesse caso, consulte Solucionar erros do agendador de pods no Azure Kubernetes Service.

Passo 3: Verifique se Existem Limites Aplicados ao Deployment do NGINX

Qualquer configuração incorreta nos limites ou requests de recursos do NGINX pode fazer com que o HPA escale mais pods do que o necessário.

Descreva o Deployment do NGINX:

 kubectl describe deploy nginx -n app-routing-system

Verifique Requests e Limits:

 $ kubectl describe deploy nginx -n app-routing-system
 Name:                   nginx
 ....
 Selector:               app=nginx
 ....
 Pod Template:
 ....
 Containers:
 controller:
     ...
     Limits:
     ...
     Requests:
     ...

Solução

Por padrão, a versão atual do NGINX ingress controller não define limites para os pods do NGINX e define requests 500m de CPU, que é usado pelo HPA. Não é recomendado alterar esses valores diretamente na definição do deployment.

Se o seu HPA está atingindo o número máximo de pods e os requests e limits do deployment permanecem inalterados, você deve configurar o custom resource definition (CRD) chamado NginxIngressController.

Opções de Configuração

As opções de configuração abaixo impactam diretamente o comportamento do HPA:

Propriedade	Tipo	Descrição	Obrigatório	Padrão
`scaling`	objeto	Configuração para escalonamento do controller. Contém propriedades aninhadas.	Não	-
`maxReplicas`	inteiro	Limite superior de réplicas.	Não	100
`minReplicas`	inteiro	Limite inferior de réplicas.	Não	2
`threshold`	string	Limite de escalonamento definindo quão agressivo será o scaling. Opções: `rapid`, `steady`, `balanced`.	Não	balanced

Como Aplicar a Configuração

Siga os passos abaixo para aplicar a configuração:

Edite o CRD NginxIngressController:

 kubectl edit nginxingresscontroller -n app-routing-system

Adicione ou modifique a configuração de scaling:

 spec:
   scaling:
     maxReplicas: 10
     minReplicas: 2
     threshold: "balanced"

Salve e saia do editor para aplicar as alterações.
Verifique as alterações:
```
 kubectl get hpa -n app-routing-system
```

O HPA será atualizado automaticamente com base na nova configuração, e o NGINX ingress controller irá escalar conforme os parâmetros especificados.

Recursos adicionais

Zonas de Disponibilidade no Azure: Entendendo a Diferença entre Zonas Lógicas e Físicas

fabiodasilva — Tue, 26 Aug 2025 13:17:42 GMT

O que é o mapeamento de zonas do Azure (Zona Lógica vs Zona Física)

No Azure, as Zonas de Disponibilidade (AZs) são agrupamentos de datacenters fisicamente separados dentros de uma mesma região. Cada zona possui infraestrutura independente - energia, refrigeração e rede - garantindo alta disponibilidade e resiliência.

Porém, há uma distinção entre:

Tipo de Zona	Definição
Zona Lógica	Identificador exibido no portal do Azure (AZ1, AZ2, AZ3).
Zona Física	Grupo real de datacenters. O mapeamento entre lógica e física varia por assinatura

O mapeamento entre zonas lógicas e físicas não é fixo. Isso significa que:

AZ1 na assinatura A pode ser fisicamente igual à AZ3 na assinatura B.
Sem verificação, você pode estar executando produção e DR na mesma infraestrutura física, anulando os benefícios da separação.

Esse comportamento é intencional e inspirado no modelo da AWS, que também não garante consistência entre zonas lógicas em diferentes contas.

Qual o objetivo desse design?
A motivação por trás desse mapeamento dinâmico é:

Distribuir a carga de consumo de forma mais eficiente entre os datacenters.
Evitar hotspots e garantir resiliência operacional.
Permitir flexibilidade de alocação conforme a capacidade física disponível.

Esse modelo ajuda a balancear o uso da infraestrutura global, sem expor diretamente a topologia física aos clientes — o que também reforça a segurança e abstração da plataforma.

Essa distinção é essencial: a zona lógica AZ1 em uma assinatura pode, na prática, ser a mesma zona física que a AZ3 em outra. Sem uma verificação adequada, o cliente pode acabar executando cargas de produção e de DR (Disaster Recovery) na mesma infraestrutura física, o que anula os benefícios esperados da separação entre zonas.

Exemplo prático de risco

Vamos considerar o seguinte cenário de um cliente:

Produção: AZ1 e AZ2 em uma assinatura A
DR: AZ3 em outra assinatura B, na mesma região

O cliente acredita estar distribuindo suas cargas entre três zonas distintas. No entanto, ao verificar o mapeamento real, encontra a seguinte saída:

[

{ "logicalZone": "1", "physicalZone": "brazilsouth-az3" },

{ "logicalZone": "2", "physicalZone": "brazilsouth-az1" },

{ "logicalZone": "3", "physicalZone": "brazilsouth-az2" }

]

Neste exemplo, a AZ3 lógica está mapeada para a AZ2 física, que já está sendo usada na produção. Ou seja, não há separação física real.

Como verificar o mapeamento de zonas?

Para evitar esse problema, é essencial verificar o mapeamento entre zonas lógicas e físicas em cada assinatura. Use o seguinte comando via Azure CLI:

az rest --method get \

--uri "/subscriptions/<subscription-id>/locations?api-version=2022-12-01" \

--query "value[?name=='<region-name>'].{displayName: displayName,name: name,availabilityZoneMappings: availabilityZoneMappings }" \

-o json

Substitua <subscription-id> e <region-name> (ex: brazilsouth) conforme necessário.

Veja abaixo um exemplo de saída obtida no meu ambiente de laboratório, onde tenho duas assinaturas. Vou executar o mapeamento de zonas entre elas para a região Brazil South.

Na primeira subscription 1 temos o seguinte mapeamento.

Zona lógica: 1 – Zona Física: brazilsouth-az1
Zona lógica: 2 – Zona Física: brazilsouth-az2
Zona lógica: 3 – Zona Física: brazilsouth-az3

Na segunda subscription 2 temos o seguinte mapeamento.

Zona lógica: 1 – Zona Física: brazilsouth-az3
Zona lógica: 2 – Zona Física: brazilsouth-az1
Zona lógica: 3 – Zona Física: brazilsouth-az2

Resumindo: Se minha estratégia de DR envolve o uso das zonas lógicas 1 e 2 na subscription 1, pois elas estão mapeadas fisicamente para as zonas AZ1 e AZ2, então, na subscription 2 destinada ao DR, devo utilizar a zona lógica 1 — já que, nessa assinatura, ela está mapeada fisicamente para a AZ3.

Boas práticas

Sempre verifique o mapeamento entre zonas lógicas e físicas antes de definir sua estratégia de DR.
Evite assumir que AZ1, AZ2 e AZ3 representam zonas físicas distintas entre diferentes assinaturas.
Considere utilizar regiões diferentes para DR quando a separação física for um requisito crítico.
Documente e compartilhe o mapeamento com sua equipe de arquitetura e operações para garantir alinhamento e evitar riscos.

Referência oficial

Para mais detalhes, consulte a documentação oficial da Microsoft:

https://learn.microsoft.com/en-us/azure/availability-zones/az-overview

Comparing AWS and Azure regions and zones - Azure Architecture Center | Microsoft Learn

Anatomia de um serviço ASP.NET Core

ClaudioGodoy — Mon, 30 Jun 2025 00:39:17 GMT

O ecossistema do .NET é uma plataforma de desenvolvimento de software criada pela Microsoft. Ele inclui ferramentas, bibliotecas e frameworks para a criação de aplicações desktop, web, mobile, serviços e muito mais. Desde sua unificação, o .NET Core e o .NET Framework passaram a ser conhecidos apenas como .NET.

O .NET SDK (Software Development Kit) fornece as ferramentas necessárias para criar, compilar, depurar e publicar aplicações .NET. Ele inclui o compilador C#), bibliotecas de classes como ASP.NET Core e Entity Framework Core, além de utilitários como o MSBuild.

O ambiente de execução .NET (Common Language Runtime ou CLR) gerencia a execução de programas .NET, oferecendo serviços como gerenciamento de memória, coleta de lixo e controle de exceções.

Tipos de Aplicações .NET

Web API: Aplicações que fornecem serviços e endpoints RESTful para interação com clientes.
Razor com SSR (Server-Side Rendering): Ideal para aplicações que precisam de SEO e renderização eficiente.
Console Application: Útil para tarefas automatizadas e scripts.
MAUI (Multi-platform App UI): Permite o desenvolvimento de aplicativos multiplataforma.
Libraries (.NET Standard/Core Libraries): Conjuntos de código reutilizável para funcionalidades específicas.

ASP.NET Core WebAPI

Uma WebAPI segue o estilo arquitetural REST (Representational State Transfer), utilizando o protocolo HTTP para comunicação.

Protocolo HTTP: Define métodos como GET, POST, PUT e DELETE para manipulação de recursos.
REST API: Utiliza URIs para identificar recursos e métodos HTTP para operações CRUD.
Modelo de Richardson: Estabelece níveis de maturidade em APIs REST.

O foco principal do artigo está na WebAPI, devido à sua relevância na criação de serviços modernos.

Demo

Para criar uma webapi, com o dotnet sdk instalado, rode o comando:

dotnet new webapi -n MinhaApi

Após executar o comando, será gerada uma estrutura básica de projeto contendo:

Controllers: Arquivos para definir os endpoints da API.
Program.cs: Configuração inicial da aplicação.
appsettings.json: Arquivo de configuração.

Você pode iniciar o servidor com:

cd MinhaApi

dotnet run

Ciclo de vida de uma requisição HTTP em aplicações ASP.NET Core

Server

Uma aplicação ASP.NET Core é executada com uma implementação de servidor HTTP in-process. Esse servidor escuta por requisições HTTP e as disponibiliza para a aplicação através do HttpContext.

As responsabilidades do servidor incluem:

Escutar em uma porta específica para receber solicitações HTTP.
Processar as requisições e encaminhá-las para os middlewares configurados.

Middlewares

Os middlewares são componentes que processam requisições e respostas. Eles podem:

Autenticar usuários.
Registrar logs.
Manipular erros.

Exemplo de configuração de middleware:

app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    endpoints.MapControllers();
});

Controllers

Os controllers são responsáveis por definir os endpoints da API. Um exemplo básico:

[ApiController]
[Route("api/[controller]")]
public class MinhaController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok("Hello World");
    }
}

Resumo

O ciclo de vida de uma requisição HTTP envolve o servidor, middlewares e controllers, garantindo que cada etapa seja processada de forma eficiente e escalável.

Conclusão

O ASP.NET Core é uma plataforma poderosa e flexível que permite o desenvolvimento de aplicações modernas, robustas e escaláveis. Desde sua arquitetura modular com middlewares até a configuração do pipeline de requisições, ele fornece ferramentas essenciais para criar soluções otimizadas e adaptadas a diferentes necessidades, seja para web, APIs RESTful ou sistemas distribuídos.

Ao longo deste artigo, exploramos desde os fundamentos do .NET e a ampla gama de tipos de aplicativos que podem ser criados, até os detalhes do ciclo de vida de uma requisição HTTP e a importância dos servidores Kestrel e HTTP.sys. Com uma compreensão clara do pipeline de requisições e dos middlewares, é possível projetar sistemas que não apenas atendem aos requisitos técnicos, mas também oferecem excelente desempenho e uma experiência de usuário consistente.

Dominar o ecossistema do ASP.NET Core é essencial para desenvolvedores que desejam se destacar no desenvolvimento de serviços e aplicações web de alto desempenho.

Participe da 2ª edição do GitHub Copilot Global Bootcamp

cynthiazanoni — Fri, 06 Jun 2025 14:19:57 GMT

O GitHub Copilot Global Bootcamp começou em fevereiro como uma jornada totalmente virtual de aprendizado — e foi um sucesso. Mais de 60 mil desenvolvedores participaram da primeira edição, em vários idiomas e regiões. Agora, estamos empolgados em lançar a segunda edição — maior e melhor — com workshops virtuais e presenciais, organizados por comunidades de tecnologia ao redor do mundo.

Essa nova edição chega logo após os anúncios do Microsoft Build 2025, onde as equipes do GitHub e do Visual Studio Code revelaram novidades empolgantes:

A extensão GitHub Copilot Chat será open source, reforçando a transparência e a colaboração.
A IA está sendo profundamente integrada ao Visual Studio Code, que agora está evoluindo para um editor de IA de código aberto.
Novas APIs e ferramentas estão tornando mais fácil do que nunca construir com IA e LLMs.

Este bootcamp é a sua oportunidade de explorar essas novas ferramentas, entender como usar o GitHub Copilot de forma eficaz e fazer parte da crescente conversa global sobre IA no desenvolvimento de software.

👩‍💻 Quem pode participar?

Seja você um(a) desenvolvedor(a) iniciante, estudante ou profissional experiente em tecnologia, este bootcamp foi feito para você. Você aprenderá casos de uso práticos do GitHub Copilot e como aumentar sua produtividade usando IA — em um formato acessível e prático.

Participe da edição virtual

Não importa onde você esteja, é possível participar online e aprender com a gente:

Português (Brasil – UTC -3)

24 de junho, 19h: Boas práticas para dominar o GitHub Copilot Chat
25 de junho, 19h: Integrações práticas com MCP Servers no VS Code e GitHub Copilot

Aprenda na sua cidade!

Estamos em parceria com comunidades locais de desenvolvedores para levar workshops presenciais a diversas cidades ao redor do mundo.

Sessões presenciais confirmadas no Brasil:

Data	Cidade	Inscrições
17 de Junho	Brasília, Brasil	Registre-se agora!
17 de Junho	Pato de Minas, Brasil	Registre-se agora!
21 de Junho	Mogi das Cruzes, Brasil	Registre-se agora!
26 de Junho	Recife, Brasil	Registre-se agora!
27 de Junho	Rio de Janeiro, Brasil	Registre-se agora!

O Microsoft Applied Skills é um programa de credenciamento criado para validar sua capacidade de realizar tarefas técnicas específicas do mundo real. Diferente das certificações tradicionais que costumam abranger cargos amplos, o Applied Skills foca em habilidades práticas e cenários reais, diretamente aplicáveis a desafios de negócios.

E a melhor parte? É totalmente gratuito!
Você demonstra suas habilidades por meio de avaliações interativas, baseadas em tarefas, em um ambiente simulado — sem perguntas de múltipla escolha, apenas trabalho real.

Uma das adições mais recentes é o Applied Skill do GitHub Copilot, que comprova sua habilidade de aproveitar a IA para aumentar a produtividade no desenvolvimento de software e melhorar a qualidade do código:

Acelere o desenvolvimento de aplicativos usando o GitHub Copilot.

Crie seu Primeiro Agente de IA com JavaScript e Azure AI Agent Service!

Glaucia_Lemos — Wed, 07 May 2025 17:37:50 GMT

Introdução: A Era dos Agentes de IA em JavaScript

Durante o AI Agents Hackathon, uma das sessões mais aguardadas foi apresentada por Wassim Chegham, que é Senior AI Developer Advocate em JavaScript na Microsoft. O tema? "Como Criar seu Primeiro Agente de IA com JavaScript e Azure AI Agent Service?" - uma ferramenta poderosa e pensada para desenvolvedores modernos que desejam criar aplicações AI-first com segurança, escabilidade e produtividade.

E, nesse artigo, vamos explorar os principais pontos abordados na sessão, com um foco especial em como você pode criar seu próprio agente de IA utilizando JavaScript e o Azure AI Agent Service.

A proposta do vídeo é clara: mostrar o passo a passo de como qualquer pessoa pode criar agentes de IA com JavaScript e TypeScript, utilizando Azure AI Foundry, e explicar todos os conceitos essenciais para dominar esse novo paradigma de desenvolvimento.

Se você perdeu a sessão, não se preocupe! Você pode assistir a gravação:

O que são Agentes de IA?

Wassim inicia a sessão com um panorama histórico: desde os chatbots tradicionais até os agentes inteligentes e autônomos que conhecemos hoje. Ele destacou:

Agentes baseados em LLMs (Large Language Models) que entendem a linguagem natural.
Agentes com ferramentas (tools) que executam ações no mundo real, como chamadas de API, buscas, execução de código etc.
Sistemas multiagentes, que coordenam vários agentes para resolver tarefas complexas.

O diferencial do Azure AI Agent Service é simplificar tudo isso, oferecendo uma plataforma gerenciada que cuida da orquestração, segurança, rastreamento e execução dos agentes.

Arquitetura de Soluções com Azure AI Agent Service

Durante a sessão, Wassim apresentou uma visão clara da arquitetura típica de uma aplicação de agente de IA desenvolvida com JavaScript. Ele explicou que, embora seja possível ter uma interface gráfica (FrontEnd) usando frameworks como Angular ou React, isso não é obrigatório - a aplicação pode muito bem funcionar num terminal, como foi o caso das demonstrações feitas ao vivo.

No BackEnd, o foco recai sobre o uso de Node.js, que pode ser combinado com frameworks como Express.js ou Fastify para expor APIs que comunicam com os agentes. Essa camada de API atua como ponte entre o usuário e a lógica do agente, coordenando mensagens, execuções e chamadas de ferramentas.

O próprio agente é criado e gerenciado com o SDK azure/ai-projects, que fornece uma API simples e direta para registrar agentes, definir instruções, anexar ferramentas e controlar execuções. Wassim destacou o quanto essa abordagem reduz a complexidade em comparação a outros frameworks de agentes, que exigem configuração manual de estado, orquestração e controle de contexto.

Além disso, há uma camada de ferramentas integradas ao serviço que ampliam significamente as capacidades do agente. São elas:

Code Interpreter: para execução de código Python em sandbox
Function Calling: para chamadas de funções definidas pelo usuário
Azure AI Search: para buscas vetoriais e RAG (Retrieval-Augmented Generation)
Bing Search: para grounding com dados em tempo real

Todas essas ferramentas são disponibilizadas de forma plug-and-play pela infraestrutura do Azure AI Agent Service.

Toda essa arquitetura é gerenciada por uma instância do Azure AI Foundry, que centraliza o controle de modelos, ferramentas, conexões e dados, proporcionando uma base robusta, segura e escalável para criar aplicações AI-first. Wassim fez questão de frisar que o agente é o verdadeiro "cérebro" da aplicação - recebendo instruções, raciocionando sobre elas e coordenando a execução de tarefas com auxílio de ferramentas externas, tudo isso com o poucos comandos em JavaScript.

Criando seu primeiro agente: Hands-on com JavaScript

Durante a demonstração prática, Wassim conduz os participantes por todas as etapas necessárias para criar um agente de IA funcional com JavaScript, utilizando o Azure AI Agent Service. Ele começa destacando que todo o código utilizado está disponível publicamente num repositório no GitHub, o que permite que qualquer pessoa possa clonar, rodar e adaptar os exemplos para seus próprios projetos.

> Link do repositório: Azure AI Agent Service - Demonstration

A primeira etapa envolve a instalação dos pacotes essenciais. O principal deles é o SDK azure/ai-projects (pacote npm - aqui), responsável por toda a interação com o serviço de agentes. Também é necessário instalar o azure/identity, que permite autenticar de forma segura com as credenciais da Azure sem precisar lidar com chaves ou tokens diretamente — utilizando, por exemplo, o DefaultAzureCredential.

Após configurar o ambiente com as dependências, Wassim mostra como criar uma instância do cliente de agente a partir de uma string de conexão obtida no portal do Azure Foundry. Essa string é armazenada em um arquivo .env, e permite que o código se conecte de forma segura ao serviço para criar e gerenciar agentes.

Com o cliente em mãos, o próximo passo é criar o agente propriamente dito. Para isso, é necessário definir o nome, o modelo de linguagem a ser usado (como o GPT-4) e fornecer instruções claras sobre o comportamento desejado para o agente — seja para realizar cálculos, responder perguntas, interpretar dados ou interagir com ferramentas externas.

Na sequência, Wassim introduz o conceito de thread, que funciona como um espaço de conversa entre o agente e o usuário. É nesse thread que as mensagens são armazenadas, as execuções são iniciadas e o histórico de interações é mantido. Ele mostra como criar um thread, enviar uma mensagem e iniciar uma run, ou seja, uma execução do agente a partir da mensagem fornecida.

A sessão então avança para demonstrar o uso de ferramentas. No primeiro exemplo, o agente resolve uma equação simples apenas com seu conhecimento interno, sem recorrer a ferramentas externas — um exemplo clássico para mostrar como o modelo pode raciocinar com base nas instruções fornecidas. Em seguida, Wassim mostra como ativar uma chamada de função personalizada: o agente acessa uma função que retorna o uso da CPU da máquina local, demonstrando a capacidade de executar ações no ambiente do usuário.

Outro exemplo impressionante é o uso do Code Interpreter, uma ferramenta que permite executar código Python remotamente e com segurança. Wassim fornece um arquivo CSV contendo dados de vendas de carros, e o agente não só processa os dados, como também gera visualizações gráficas em tempo real.

Além disso, ele demonstra como o agente pode utilizar o Bing Grounding para buscar informações atualizadas diretamente da internet, como cotações do mercado de ações. E, por fim, mostra a integração com o Azure AI Search, onde um índice vetorial previamente carregado com informações sobre planos de saúde é consultado para responder perguntas específicas, com direito a citações precisas da fonte utilizada — um ótimo exemplo do padrão RAG (Retrieval-Augmented Generation) em ação.

Esses exemplos mostram que, mesmo com poucos comandos em JavaScript, é possível criar agentes sofisticados, capazes de interagir com dados, ferramentas e usuários de maneira fluida, segura e produtiva.

Entendendo a mecânica interna: Como um agente funciona?

Wassim explica os conceitos fundamentais do ciclo de vida de um agente:

Agent: configurado com modelo e instruções.
Thread: representa a conversa (contexto).
Run: execução de uma tarefa.
Run Steps: etapas da execução.
Tools: definidas com schemas e acionadas conforme necessário.
Events: eventos emitidos durante a execução (streaming, tool-call, resposta, erro, etc).

Além disso, ele demonstra um projeto pessoal: uma ferramenta de tracing visual para acompanhar em tempo real cada etapa do agente, o que facilita o entendimento e o debug.

Um pouco sobre as tecnologias utilizadas no projeto

Para quem está curioso sobre as tecnologias utilizadas no projeto, Wassim fez questão de destacar algumas delas:

📦 SDK utilizado
- azure/ai-projects@2.0.0-beta.4
- azure/identity para autenticação com credenciais seguras.
🔧 Ferramentas integradas
- Function Calling: executa funções com base na entrada do LLM.
- Code Interpreter: executa código Python remotamente com segurança.
- Azure AI Search: busca vetorial e full-text com RAG.
- Bing Search Grounding: informações em tempo real da web.
- File Search (em breve): busca em arquivos carregados.
⚙️ Segurança e compliance
- Autenticação sem chaves (keyless)
- Private Networking (VNet)
- Content Filtering
- Tracing e logs para evitar alucinações

Conclusão: O Futuro dos Agentes de IA com JavaScript

A sessão de Wassim Chegham no AI Agents Hackathon foi uma verdadeira aula sobre como criar agentes de IA com JavaScript e Azure AI Agent Service. Ele não só apresentou os conceitos fundamentais, mas também mostrou na prática como é fácil e rápido desenvolver aplicações inteligentes utilizando essa nova abordagem.

Novamente se você perdeu a sessão, não se preocupe! Você pode assistir a gravação aqui.

E, claro , não deixe de conferir o repositório no GitHub com todos os exemplos e códigos utilizados durante a apresentação: Azure AI Agent Service - Demonstration.

E, no final, Wassim deixou uma mensagem clara: o futuro dos agentes de IA é promissor, e com as ferramentas certas, qualquer desenvolvedor pode criar soluções inovadoras e impactantes. Então, não perca tempo! Comece a explorar o Azure AI Agent Service e crie seu próprio agente de IA hoje mesmo!

Links úteis

Azure AI Agent Service: Documentação oficial do serviço de agentes de IA da Azure.
Azure AI Foundry: Plataforma para criar e gerenciar agentes de IA.
Azure AI Agent Service - Demonstration: Repositório GitHub com exemplos e códigos utilizados na sessão.
AI Agents Hackathon: Evento que reuniu desenvolvedores para explorar o potencial dos agentes de IA.
Wassim Chegham: LinkedIn do apresentador da sessão.
Azure AI Foundry - Getting Started: Guia para começar a usar o Azure AI Foundry.
Azure AI Agent Service - Quickstart: Tutorial rápido para criar seu primeiro agente de IA.
Azure AI Agent Service - Tools: Documentação sobre as ferramentas disponíveis no serviço de agentes de IA.
Azure AI Agent Service - Function Calling: Documentação sobre chamadas de função no serviço de agentes de IA.
Azure AI Agent Service - Code Interpreter: Documentação sobre o interpretador de código no serviço de agentes de IA.
Azure AI Agent Service - Azure AI Search: Documentação sobre o Azure AI Search no serviço de agentes de IA.
Azure AI Agent Service - Bing Search: Documentação sobre o Bing Search no serviço de agentes de IA.

Conectando o Azure Vmware Solution (AVS) com VPN Site to Site em topologia Hub Spoke.

LeandroBarbosa — Mon, 05 May 2025 14:46:04 GMT

A conexão de VPN entre AVS e o ambiente On-premises na maioria das vezes é realizada através do Virtual WAN, conforme descrito em: https://learn.microsoft.com/en-us/azure/azure-vmware/configure-site-to-site-vpn-gateway.

Contudo, caso necessário utilizar em uma topologia Hub-Spoke, existem componentes adicionais que devem ser considerados para permitir o trânsito entre o ExpressRoute do AVS e o VPN Gateway, bem como a propagação das rotas para o ambiente On-premises, assim como é feito por padrão com o Virtual WAN.

Nesta topologia, o Azure Route Server deve ser integrado para habilitar esse trânsito (propagação de rotas)

O objetivo deste artigo é demonstrar em um ambiente de laboratório como conectar um ambiente On-premises com o Azure VMware Solution (AVS) através de uma VPN Site-to-Site em topologia Hub-Spoke.

Arquitetura do Laboratório com topologia Hub-Spoke.

Componentes Azure.

Vnet 10.90.0.0/16 com 3 Subnets.
- Gateway Subnet - 10.90.0.0/24
- RouteServerSubnet - 10.90.1.0/24
- VmSubnet : 10.90.2.0/24
Virtual Network Gateway - VPN
Virtual Network Gateway - Express Route
Azure Route Server
Azure Vm Linux Ubuntu

Componentes On-premises

Firewall VPN PfSense - 192.168.90.0/24 , 192.168.200.0/22 , 192.168.92.0/24

Componetes Azure Vmware Solution

VMware SDDC
Circuito Express Route

*Este laboratório presume que os componentes como o Azure Vmware Solution e ambiente On-premises com Pfsense ou qualquer outro equipamento esteja presente.

1. Deploy componentes Azure

# 1. Variáveis - Altere conforme necessário RESOURCE_GROUP="rg-avs-lab" LOCATION="eastus2" VNET_NAME="vnet-avs-lab" VNET_ADDRESS_PREFIX="10.90.0.0/16" SUBNET_GATEWAY_PREFIX="10.90.0.0/24" SUBNET_ROUTE_SERVER_PREFIX="10.90.1.0/24" SUBNET_GATEWAY_NAME="GatewaySubnet" SUBNET_ROUTE_SERVER_NAME="RouteServerSubnet" EXPRESSROUTE_GW_NAME="er-avs-lab" VPN_GW_NAME="vpn-avs-lab" VPN_GW_IP1_NAME="vpn-gw-ip1" VPN_GW_IP2_NAME="vpn-gw-ip2" VPN_GW_ASN=65515 EXPRESSROUTE_IP_NAME="er-ip" LOCAL_NETWORK_GATEWAY_NAME="local-gw-avs-lab" BGP_PEER_IP="192.168.90.1" ASN_LOCAL=65503 ROUTE_SERVER_NAME="rserver-avs-lab" # Variáveis para subnet e VM SUBNET_VM_NAME="subnet-vm" SUBNET_VM_PREFIX="10.90.5.0/24" VM_NAME="vm-ubuntu" VM_ADMIN_USERNAME='azureuser' VM_ADMIN_PASSWORD='P@ssword123!' # Use um método seguro em produção VM_NIC_NAME="vm-ubuntu-nic" VM_IMAGE="Canonical:0001-com-ubuntu-server-focal:20_04-lts:latest" VM_SIZE="Standard_B2ms" # 2. Criar grupo de recursos az group create --name $RESOURCE_GROUP --location $LOCATION # 3. Criar VNet e subnets az network vnet create \ --resource-group $RESOURCE_GROUP \ --location $LOCATION \ --name $VNET_NAME \ --address-prefixes $VNET_ADDRESS_PREFIX \ --subnet-name $SUBNET_GATEWAY_NAME \ --subnet-prefix $SUBNET_GATEWAY_PREFIX az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_ROUTE_SERVER_NAME \ --address-prefix $SUBNET_ROUTE_SERVER_PREFIX # Criar subnet para a VM az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_VM_NAME \ --address-prefix $SUBNET_VM_PREFIX # 4. Criar IP público para ExpressRoute az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_IP_NAME \ --sku Standard \ --allocation-method Static # 5. Criar Gateway ExpressRoute az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $EXPRESSROUTE_IP_NAME \ --gateway-type ExpressRoute \ --sku Standard # 6. Criar IPs públicos para VPN Gateway ativo-ativo az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP1_NAME \ --sku Standard \ --allocation-method Static az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP2_NAME \ --sku Standard \ --allocation-method Static # 7. Criar VPN Gateway az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $VPN_GW_IP1_NAME $VPN_GW_IP2_NAME \ --gateway-type Vpn \ --vpn-type RouteBased \ --sku VpnGw1 # Após a criação, configurar ativo-ativo e BGP az network vnet-gateway update \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --set activeActive=true enableBgp=true bgpSettings.asn=$VPN_GW_ASN # 8. Criar Local Network Gateway com BGP e ASN az network local-gateway create \ --resource-group $RESOURCE_GROUP \ --name $LOCAL_NETWORK_GATEWAY_NAME \ --gateway-ip-address $BGP_PEER_IP \ --local-address-prefixes "192.168.90.0/24" \ --asn $ASN_LOCAL \ --bgp-peering-address $BGP_PEER_IP \ --location $LOCATION # 9. Criar conexão VPN entre o Gateway de VPN e o Local Network Gateway az network vpn-connection create \ --resource-group $RESOURCE_GROUP \ --name vpn-s2s-connection \ --vnet-gateway1 $VPN_GW_NAME \ --local-gateway2 $LOCAL_NETWORK_GATEWAY_NAME \ --shared-key 'teste@123' \ --enable-bgp # 10. Criar NIC para a VM az network nic create \ --resource-group $RESOURCE_GROUP \ --name $VM_NIC_NAME \ --vnet-name $VNET_NAME \ --subnet $SUBNET_VM_NAME # 12. Criar VM com Ubuntu az vm create \ --resource-group $RESOURCE_GROUP \ --name $VM_NAME \ --nics $VM_NIC_NAME \ --image $VM_IMAGE \ --admin-username $VM_ADMIN_USERNAME \ --admin-password $VM_ADMIN_PASSWORD \ --size $VM_SIZE \ --location $LOCATION

2. Conectando o Express Route do AVS no VPN Gateway da Hub.

No Virtual Network Gateway de ER , adicione uma conexão

Defina o connection type como ExpressRoute

No AVS, copie o authorization key e o ExpressRoute ID

Para este cenário será utilizado o modelo de resiliência standard, o Virtual network gateway, informe um nome para conexão, insira a "authorization key" e "ExpressRoute ID" (per cirtuit URI) copiados nos passos acima e execute o deploy.

Verificando que a conexão foi estabelecida com sucesso.

Verificando as rotas na Vm de teste.

Ao verificar as rotas do Pfsense ( onprem) , é possível observar que não temos as rotas do AVS, somente da Vnet do Azure.

Para habilitar o trânsito e troca de rotas entre o Express Route do AVS e o VPN gateway precisamos inserir o Azure Route Server.

3. Deploy do Azure Route Server.

#Criar Azure Route Server #Cria Public IP para o Route Server az network public-ip create --resource-group $RESOURCE_GROUP --name routeserver-pip --sku Standard --allocation-method Static # Identifica o ID da Subnet do Route Server SUBNET_ID=$(az network vnet subnet list --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --query "[?name=='$SUBNET_ROUTE_SERVER_NAME'].id" --output tsv) # Cria o Route Server az network routeserver create \ --resource-group $RESOURCE_GROUP \ --name $ROUTE_SERVER_NAME \ --hosted-subnet $SUBNET_ID \ --location $LOCATION \ --public-ip-address routeserver-pip

Após criado habilitamos a opção Branch-to-Branch

Podemos verificar que agora as rotas do AVS (172.30.0.0/22), agora foram propagadas para o Pfsense.

Validando acesso ao Vcenter do AVS.

Referências:

https://learn.microsoft.com/en-us/azure/route-server/overview

https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke

Migração de Aplicações Full Framework para Azure AKS e .NET Core

wdossantos — Mon, 28 Apr 2025 12:18:09 GMT

Criando e Abrindo um projeto 4.7.2

Vou criar o projeto no Visual Studio 2015, usando a versão FULL Framework .NET 4.7 escolhi o template de uma aplicação ASP.NET Web Application. Este é um projeto pequeno, desses que já nascem prontos, vai servir bem para testar as ferramentas de migração.

Depois de criado o projeto, e é importante habilitar essa versão .NET Core no Visual Studio 2022, pois precisaremos abrir o projeto nessa IDE para usar as extensões. Caso você tenha algum projeto pronto em uma versão mais antiga do dotnet então basta usá-lo

Depois de ter o projeto que vamos migrar, precisei instar o dotnet-appcat conforme essa doc Azure Migrate application and code assessment for .NET — Azure Migrate | Microsoft Learn

A documentação pende a instalando dessa extensão no visual studio Azure Migrate application and code assessment — Visual Studio Marketplace depois disso podemos abri o projeto pelo Visual Studio 2022 e já e vamos encontrar a opção re-plataform to Azure clicando com botão direito no projeto ou na solution.

Se escolhermos clicar na solution o item re-plataform to Azure disponibilizara a opção new report

Então vamos escolher para qual o tipo de computação a aplicação vai ser migrada

E como escolhemos a solution, agora vamos selecionar os projetos que queremos analisar

Um relatório com as issues será apresentado

entramos na issue e podemos ver a opção de perguntar para o copilot

Resposta do copilot para um issue especifica

E é isso basta ir resolvendo as issues, com essa ferramenta você pode verificar o código-fonte, configurações e binários da sua aplicação para encontrar oportunidades de migração para o Azure. Ele vai ajudar a identificar problemas ao mover sua aplicação para o Azure e melhora o desempenho, escalabilidade e segurança, sugerindo soluções modernas e nativas da nuvem.

NET Upgrade Assistant

Agora vamos pensar na migração do código, antigamente eu utilizava um cara chamado Portability Analyzer O .NET Portability Analyzer — .NET — .NET | Microsoft Learn, mas ele foi descontinuado e no lugar agora temos o Assistente de Atualização do .NET

Vou escolher um projeto por vez, clicando com o botão direito sobre o projeto e selecionando a opção 'update'. Esse método, em vez de gerar um relatório com as issues, tenta uma conversão direta de código. Na maioria das vezes, ele apenas faz o retarget, mas mesmo assim ajuda

No caso de um projeto WEB, a melhor opção é criar um novo projeto, pois ele vai criar uma espécie de proxy para permitir a migração paralela dos controllers

Selecionar o framework para 8

O assistente vai criar o projeto .net core, mas apenas uma casca, sem ter migrado ó código de fato

A partir disso, precisamos voltar ao projeto original onde começamos a migração e clicar novamente em 'update' usando o botão direito sobre esse projeto. Então, será possível migrar controller por controller. Cada controller migrada leva consigo suas dependência

Escolher a solution

Também podemos escolher a solution que contém vários projetos. Nesse caso, vou clicar na solution e não no projeto. Veja que agora, em vez de converter, ele me dá a opção de criar um relatório.

e então ele analisa projeto por projeto e gera as issues para serem corrigidas

aqui também consegui pedir ajuda do copilot paras as issues, e assim fica muito mais prático do que o Portability Analyzer

O Assistente de Atualização do .NET ajuda a atualizar projetos para versões mais recentes do .NET e analisa seu código para detectar e corrigir possíveis incompatibilidades. Um foco da ferramenta é ajudar a migrar um projeto do .NET Framework, .NET Core ou .NET para a versão mais recente do .NET. Você usa a extensão ou a ferramenta para atualizar projetos inteiros do .NET ou algum aspecto do projeto, como a migração de um arquivo de configuração de um tipo mais antigo para um tipo mais recente.

Podemos utilizar a CLI

upgrade-assistant --help

para iniciar o assistente use o comando

upgrade-assistant upgrade

Script para fazer vários projetos

upgrade-assistant upgrade# Defina o diretório raiz $rootDir = "..." $destDir = "..." # Obtenha todos os arquivos .csproj no diretório raiz e subdiretórios $csprojFiles = Get-ChildItem -Path $rootDir -Recurse -Filter *.csproj # Execute o comando upgrade-assistant para cada arquivo .csproj foreach ($file in $csprojFiles) { Write-Host "Executando upgrade-assistant para $($file.FullName)" Start-Process -FilePath "upgrade-assistant" -ArgumentList "upgrade $($file.FullName) --operation Inplace --targetFramework net8.0 --destination ${destDir} " -Wait }

Referência

Destaques do VS Code Live: Agent Mode Day

cynthiazanoni — Tue, 22 Apr 2025 19:04:13 GMT

🎙️ Palestrantes: Olivia McVicker, Cassidy Williams, Burke Holland, Harald Kirschner, Toby Padilla, Rob Lourens, Tim Rogers, James Montemagno, Don Jayamanne, Brigit Murtaugh, Chris Harrison.

O que é o Agent Mode?

O Agent Mode no VS Code representa um avanço além da tradicional sugestão de código por IA. Em vez de apenas sugerir trechos de código, o Agent Mode permite que a IA:

Escreva, edite e itere sobre o código
Execute comandos no terminal de forma autônoma
Corrija seus próprios erros durante o fluxo de trabalho
Interaja com ferramentas externas, APIs e serviços

Isso cria um parceiro de codificação mais dinâmico e “agente”, capaz de automatizar tarefas complexas, reduzir intervenções manuais e manter o desenvolvedor no fluxo. O Agent Mode está disponível diretamente no VS Code e se integra perfeitamente ao GitHub Copilot, tornando recursos avançados de IA acessíveis a desenvolvedores de todos os níveis.

1. Model Context Protocol (MCP)

O MCP é um protocolo aberto que padroniza como aplicações fornecem contexto para Modelos de Linguagem de Grande Escala (LLMs). Ele serve como uma ponte, permitindo que agentes de IA no VS Code se conectem de forma segura a um vasto ecossistema de ferramentas, APIs e recursos internos — muito além do que está disponível nativamente.

Principais pontos sobre o MCP:

Abordagem de ecossistema: permite conectar Copilot e outros agentes a tudo que for necessário — documentação interna, bancos de dados, ferramentas de design como Figma, etc.
Aberto e extensível: qualquer pessoa pode criar e compartilhar novas integrações, com milhares de servidores MCP já disponíveis.
Encadeamento de ferramentas: servidores MCP podem ser combinados, permitindo que a IA automatize fluxos de trabalho que envolvem múltiplas ferramentas.
Seguro e em evolução: o protocolo está evoluindo para suportar autenticação mais segura e facilitar a descoberta e instalação de integrações.

2. Next Edit Suggestions (NES)

O Next Edit Suggestions (NES) é um recurso projetado para aprimorar a experiência de edição, oferecendo recomendações contextuais para mudanças no código. O NES auxilia desenvolvedores sugerindo edições relevantes com base no contexto atual, apoiando tarefas como refatoração, correção de bugs e adição de funcionalidades. Ele permite aceitar, desfazer ou iterar rapidamente sobre mudanças sugeridas pela IA, mantendo o controle total sobre o código.

3. Bring Your Own Key (BYOK): Integração de Modelos de IA Personalizados

O BYOK permite que usuários conectem suas próprias chaves de API para modelos de IA personalizados, incluindo OpenAI, Anthropic ou até modelos locais. Com o BYOK, desenvolvedores podem escolher entre vários modelos, integrar soluções locais ou em nuvem por motivos de privacidade, custo ou desempenho, e adaptar a experiência da IA às suas necessidades específicas.

4. O Futuro Agente

Uma prévia do “Project Padawan” mostrou que fluxos de trabalho agentes poderão rodar de forma assíncrona na nuvem. Será possível delegar tarefas ao Copilot (como resolver issues do GitHub), que criará pull requests, executará testes e iterará sobre feedbacks de forma autônoma, enquanto o desenvolvedor foca em outras atividades.

GitHub Copilot Skills Challenge

Quer aprender e experimentar o Agent Mode do GitHub Copilot enquanto conquista um Selo Digital? Participe do GitHub Copilot Skills Challenge — uma experiência prática de aprendizado no Microsoft Learn, onde você construirá um aplicativo Python usando o Agent Mode por meio de um tutorial guiado. Complete o desafio até 30 de abril de 2025 para ganhar seu selo!

Confira as regras oficiais: https://aka.ms/csc/terms
Inscreva-se no Desafio: https://aka.ms/csc/githubcopilot
Solicite seu selo em: https://aka.ms/getyourbadge

Como começar

Ative o Agent Mode — disponível nas versões estável e insiders do VS Code — para experimentar esses recursos avançados de IA. Explore integrações MCP navegando pela lista de servidores ou criando o seu próprio com os SDKs disponíveis.

Quer ver essas funcionalidades em ação? Assista ao stream completo para demonstrações ao vivo, dicas de especialistas e marque a data para o próximo episódio da nossa série VS Code Live: https://aka.ms/VSCode/Live

Happy coding!

Modo Agente disponível para todos os usuários do VS Code e com suporte a MCP

cynthiazanoni — Mon, 07 Apr 2025 21:17:34 GMT

O Modo Agente está sendo lançado para todos os usuários do VS Code!

O agente atua como um programador autônomo que realiza tarefas de codificação em várias etapas sob seu comando, como analisar sua base de código, propor edições de arquivos e executar comandos no terminal. Ele responde a erros de compilação e lint, monitora a saída do terminal e corrige automaticamente em um loop até que a tarefa seja concluída.

O agente também pode usar ferramentas contribuídas, permitindo que ele interaja com servidores MCP externos ou extensões do VS Code para realizar uma ampla variedade de tarefas.

Disponível para todos os usuários

Abra a visualização de Chat, faça login no GitHub, configure chat.agent.enabled nas suas configurações e selecione Agente no menu suspenso do modo de Chat. Se você não vir a configuração, certifique-se de recarregar o VS Code após atualizar para a versão mais recente. Nas próximas semanas, estamos lançando isso por padrão para todos - nenhuma configuração será necessária.

O modo Agente é ótimo para cenários onde:

Sua tarefa envolve várias etapas. O agente edita o código, executa comandos no terminal, monitora erros e itera para resolver quaisquer problemas que surgirem.
Você não tem certeza sobre o escopo das mudanças. O agente determina automaticamente os arquivos e o contexto relevantes.
Sua tarefa requer interação com aplicativos ou dados externos. O agente se integra com servidores MCP e extensões do VS Code.

Por outro lado, use o modo de edição quando a tarefa tiver um escopo bem definido, você quiser uma resposta rápida ou quiser um controle mais preciso sobre o número de solicitações ao LLM.

Criamos uma experiência de chat unificada, combinando as visualizações de Chat e Edições, que traz benefícios como histórico de sessões, mover o chat para uma janela separada e simplificação da visualização do Conjunto de Trabalho. Tudo isso agora também está disponível no modo Agente.

Continuamos a receber um feedback fantástico dos usuários (por favor, continuem enviando!), o que inspirou muitas das melhorias que fizemos. Mais notavelmente:

A ação de desfazer agora reverte as mudanças até a última chamada da ferramenta de edição de arquivos.
Suporte para múltiplas sessões de agente no mesmo workspace (melhor quando as sessões de edição não modificam os mesmos arquivos).
O agente agora pode criar e editar notebooks.
A capacidade de aprovar automaticamente chamadas de ferramentas (aprovação automática de terminal chegando em abril).
Uma série de melhorias na qualidade de vida e correções de bugs.

Tanto as experiências de perguntar quanto de editar estão evoluindo para uma arquitetura que, como o agente, utiliza ferramentas. Estamos fazendo essa mudança para unificar os modos de perguntar/editar/agente para serem todos agenticos, com o objetivo de suavizar a experiência geral do usuário. Isso permite que o modo de edição use a ferramenta de edição de arquivos para melhorar a velocidade, e os modos de edição e pergunta usem #codebase, uma busca agentica na base de código. Consequentemente, modelos de linguagem sem suporte para chamadas de ferramentas não estarão mais disponíveis no modo de edição.

Extensível: Servidores MCP e Extensões do VS Code

Assim como as extensões do VS Code permitem que você personalize seus fluxos de trabalho específicos, a extensibilidade do agente permite que você adapte o agente às suas necessidades. Com a extensibilidade, o agente pode realizar ações no navegador (depuração web com IA), conectar-se aos seus aplicativos de chat e de anotações, interagir com seus bancos de dados, obter contexto do seu sistema de design, obter problemas e contexto de repositório do GitHub e integrar-se com suas plataformas de nuvem. O poder do modo agente está na diversidade de ferramentas disponíveis e na flexibilidade de adicionar e remover ferramentas conforme necessário. Estamos lançando a extensibilidade em preview e disponível para todos os usuários.

O modo agente pode usar as seguintes ferramentas:

Ferramentas integradas contribuídas pelo VS Code (azul no diagrama), que permitem ao agente pesquisar no workspace, aplicar mudanças de código, executar comandos no terminal, capturar erros de compilação ou linting do editor, buscar conteúdo de sites (#fetch para acionar manualmente), e mais.
Ferramentas contribuídas por servidores MCP (verde no diagrama).
Ferramentas contribuídas por extensões do VS Code (verde no diagrama).

Quando a equipe do VS Code inventou o Protocolo de Servidor de Linguagem (LSP) em 2016, nosso objetivo era padronizar como os servidores de linguagem se comunicam com as ferramentas de desenvolvimento. Estamos orgulhosos de que o LSP se tornou um padrão amplamente adotado e cumpriu nossa visão. Recentemente, as ideias por trás do LSP inspiraram um novo protocolo: o Protocolo de Contexto de Modelo (MCP), que padroniza como as aplicações fornecem contexto para LLMs. Com o modo agente no VS Code usando ferramentas contribuídas por servidores MCP, agora completamos o ciclo de volta ao VS Code.

É sobre controle do desenvolvedor

Nem toda tarefa precisa de todas as ferramentas que você pode ter adicionado ao modo agente, e como em qualquer fluxo de trabalho de IA, ser específico leva a melhores resultados. Recomendamos usar a interface de ferramentas para gerenciar e habilitar as ferramentas necessárias para cada cenário ou referenciar explicitamente as ferramentas em seu prompt digitando #.

Para lhe dar total controle, cada invocação de ferramenta é exibida de forma transparente na interface e requer sua aprovação (exceto para ferramentas integradas de leitura). Você pode permitir uma ferramenta específica para a sessão atual, workspace ou todas as invocações futuras. Se você quiser minimizar interrupções permitindo sempre que o agente use todas as ferramentas, enquanto ainda mantém a segurança, considere usar a extensão Dev Containers. Isso isola todas as mudanças feitas pelo agente dentro do ambiente do contêiner até certo ponto (por exemplo, o agente ainda pode enviar mudanças para o remoto se você permitir).

Comece agora

Para personalizar o agente para seus fluxos de trabalho, selecione o ícone de "Ferramentas" na entrada do chat e siga o fluxo Adicionar Mais Ferramentas.... Alternativamente, leia nossa documentação do servidor MCP, que explica o formato de configuração, como adicionar um servidor MCP ou como importar servidores MCP de um aplicativo cliente MCP existente, como o Claude Desktop. O VS Code suporta entrada/saída padrão local (stdio) e eventos enviados pelo servidor (sse) para transporte de servidor MCP.

O repositório oficial de servidores do MCP é um ótimo ponto de partida para servidores oficiais e contribuídos pela comunidade que mostram a versatilidade do MCP. Para instalar extensões que contribuem com ferramentas, abra a visualização de Extensões e pesquise usando a tag @tag:language-model-tools.

Como desenvolvedor, você pode estender o agente criando um servidor MCP, ou se você é um autor de extensão, pode contribuir com ferramentas para sua extensão do VS Code. Consulte estes documentos para orientações e melhores práticas sobre como escrever ferramentas.

O que vem a seguir

O modo Agente está melhorando a cada dia, e para estar entre os primeiros a se beneficiar, considere instalar o VS Code Insiders. Usar o VS Code Insiders e fornecer feedback em nosso repositório é a melhor maneira de nos ajudar a melhorar o produto. Em seguida, planejamos trabalhar em:

Suporte para modos personalizados com conjuntos de ferramentas e instruções personalizadas
Uma experiência de aplicação de código mais rápida
Expandir o suporte MCP de ferramentas para prompts, recursos e as atualizações mais recentes das especificações
Transmissão de edições limitada a blocos de código alterados para melhorar a velocidade
Pontos de verificação para voltar facilmente a uma etapa específica na sua sessão de modo agente
Melhorias gerais de desempenho e qualidade de serviço

Certifique-se de estar na versão mais recente do VS Code Stable, configure chat.agent.enabled nas suas configurações e selecione Agente no menu suspenso do modo. Experimente hoje e nos diga o que você acha! Você pode encontrar a documentação aqui.

Aprenda IA Generativa com JavaScript: Curso Gratuito e Interativo! 💡🤖

Glaucia_Lemos — Wed, 02 Apr 2025 00:27:37 GMT

No vídeo mais recente do meu Canal do YouTube, o time de Advocacia de JavaScript + A.I da Microsoft apresenta uma iniciativa inovadora para desenvolvedores que querem dar os primeiros passos com Inteligência Artificial: o curso gratuito Generative AI with JavaScript. Combinando aprendizado técnico com uma experiência gamificada, o curso é uma excelente porta de entrada para quem deseja explorar IA Generativa usando JavaScript/TypeScript.

Vamos falar um pouco mais sobre o curso e como ele pode ajudar você a se tornar um desenvolvedor mais habilidoso e atualizado com as últimas tendências em tecnologia.

Sobre o Curso: Generative AI with JavaScript

Gravei um vídeo onde explico os principais conceitos abordados no curso, incluindo técnicas de IA Generativa, exemplos práticos e dicas para maximizar seu aprendizado. Se você não assistiu, deixo o link abaixo em português, com legendas em inglês.

O vídeo começa com uma introdução ao repositório do curso, hospedado na organização oficial da Microsoft no GitHub.

O curso propõe uma abordagem única, utilizando o conceito de viagens no tempo, onde você interage com personagens históricos como Leonardo da Vinci, Ada Lovelace, Montezuma e muitos outros, enquanto aprende os fundamentos de IA.

Essa narrativa envolvente é suportada por conteúdo técnico sólido. Cada lição contém material didático em formato de leitura, desafios práticos com exercícios e quizzes, além de um aplicativo complementar onde você pode conversar com os personagens históricos usando modelos de linguagem (LLMs). A combinação de storytelling e tecnologia torna o processo de aprendizado imersivo e acessível.

A experiencia do Curso

Durante o vídeo, eu fiz uma tour completa pelo repositório, destacando que o curso ainda está em inglês (agora já está disponível em português!!).

O curso está estruturado em cinco lições iniciais, com a promessa de atualizações frequentes, acompanhando a evolução acelerada do campo de IA Generativa. Hoje falamos de RAG (Retrieval Augmented Generation), amanhã já estamos explorando Model Context Protocol e agentes inteligentes. Por isso, o repositório deve ser visto como um projeto vivo e em constante expansão.

Para começar a estudar o curso, você pode tanto clonar o repositório localmente quanto usar o GitHub Codespaces, uma alternativa recomendada no vídeo. Com 60 horas gratuitas por mês, o Codespaces permite iniciar o ambiente de desenvolvimento completo direto do navegador, sem necessidade de instalações locais. Essa praticidade democratiza o acesso ao conteúdo, especialmente para quem tem recursos limitados.

Uma vez dentro do Codespaces, você encontrará um ambiente pré-configurado com todas as dependências necessárias para executar os exemplos e desafios do curso. O repositório contém um arquivo README.md com instruções detalhadas sobre como configurar o ambiente, além de links para o aplicativo complementar e outros recursos úteis.

Na primeira lição, por exemplo, os alunos aprendem sobre os fundamentos da IA Generativa e os LLMs, explorando suas aplicações e limitações no contexto de desenvolvimento com JavaScript. Além do conteúdo textual, há um vídeo introdutório e slides complementares, oferecendo múltiplas formas de aprendizado.

Um Curso com Personagens Históricos!

Um dos pontos altos do curso é o Characters App, uma aplicação interativa que simula conversas com figuras históricas utilizando LLMs. O vídeo mostra como rodar essa aplicação diretamente no Codespaces, bastando navegar até a pasta correta, executar os comandos npm install e npm run start, e abrir a porta 3000 no navegador integrado.

Ao iniciar o app, os usuários podem escolher personagens como Dinocrates de Alexandria, Leonardo da Vinci, Ludovico Sforza, Montezuma e Ada Lovelace. Cada um responde com sua personalidade e contexto histórico, permitindo ao aluno experimentar diferentes estilos de interação com IA.

A experiência é enriquecida com suporte a voz, dando ainda mais vida aos personagens e estimulando uma forma lúdica de compreender os conceitos de IA. É uma abordagem que combina aprendizado técnico com imersão cultural e histórica.

Aprendizado Guiado com Exercícios

Outro aspecto importante do curso é que ele não se limita a conceitos teóricos. Cada lição vem acompanhada de exercícios práticos, que desafiam o aluno a aplicar o que foi aprendido. O vídeo mostra onde localizar esses desafios e como encontrar as soluções propostas, o que ajuda tanto quem está começando quanto quem quer revisar seus conhecimentos.

A ideia é que você realmente se envolva com o conteúdo. Ao invés de apenas consumir o que está pronto, você é incentivado a tentar resolver os problemas por conta própria antes de consultar a solução. Essa abordagem ativa favorece a retenção do conhecimento.

Além disso, há dicas úteis para configurar o ambiente, usar o GitHub Copilot e aproveitar as requisições gratuitas de modelos como Claude, Gemini e GPT-4o. O vídeo reforça que, hoje em dia, há múltiplas opções para quem deseja aprender e experimentar com IA sem precisar gastar dinheiro, entre elas o uso do GitHub Models!

Conclusão

Fica o convite! Explore o curso com calma, interaja com os personagens, faça os exercícios e acompanhe todas as atualizações direto no repositório do curso. Assim, você estará sempre à frente no aprendizado de IA Generativa com JavaScript/TypeScript

Se você ainda não explorou o curso, essa é a hora. Dê um fork no repositório, experimente o curso direto no Codespaces, converse com Da Vinci ou Ada Lovelace, e comece a construir seu próprio conhecimento em IA Generativa com JavaScript.

Você está há um passo de se tornar expert em IA Generativa com JAvaScript - comece agora mesmo com um simples git clone!

Use IA de Graça com GitHub Models e TypeScript! 💸💸💸

Glaucia_Lemos — Tue, 01 Apr 2025 23:56:06 GMT

A Inteligência Artificial está se tornando cada vez mais acessível para desenvolvedores. Porém, um dos maiores desafios ainda é o custo das APIs de modelos avançados, como GPT-4o e tantos outros. Felizmente, o GitHub Models veio para mudar esse cenário! Agora, você pode experimentar IA de graça, sem precisar de uma chave de API paga ou baixar modelos pesados em suas máquinas locais.

Neste artigo, vamos explicar em detalhes o que é o GitHub Models e como utilizar gratuitamente com TypeScript em um projeto prático. Escolhemos como exemplo o projeto Microblog AI Remix, um projeto open source de microblog com funcionalidades de IA.

Iremos abordar a estrutura desse projeto e demonstrar passo a passo como integrar com o GitHub Models, substituindo a necessidade de fazer uso de LLMs pagos, incluindo comparações de código antes e depois das modificações. Também veremos como configurar e executar o projeto localmente, e discutiremos as vantagens e limitações do GitHub Models para prototipagem de projetos em IA.

Pode ter certeza que, ao final deste artigo, você terá uma compreensão sólida do GitHub Models e como utilizá-lo em seus próprios projetos e começar a explorar o mundo da IA de forma acessível e gratuita.

Vamos lá!

O que é o GitHub Models?

O GitHub Models é uma iniciativa do GitHub que disponibiliza uma coleção de modelos de IA prontos para uso, integrados à plataforma. Pense no GitHub Models como um Marketplace de Modelos de IA: onde os desenvolvedores podem descobrir modelos de linguagem grande (LLMs) de diferentes provedores, testar suas capacidades em um playground interativo e incorporar em suas aplicações de forma simplificada.

Há modelos de diversas origens e portes - por exemplo, o OpenAI GPT-4o, modelos Open Source como o Meta Llama 3.1, o Phi-3 da Microsoft, o Mistral Large 2, entre outros. Todos podem ser acessados gratuitamente para fins de experimentação.

Uma das grandes vantagens do GitHub Models é permitir o uso gratuito desses modelos durante a fase de prototipagem. Ou seja, você pode testar e construir um proof of concept (POC) sem custos, utilizando a infraestrutura fornecida pelo GitHub. Na prática, existem duas maneiras de interagir com os modelos:

Playground (interface web): nesse playground, você pode testar os modelos diretamente no navegador do GitHub. Nele, você pode fazer perguntas e obter respostas em tempo real com diferentes modelos, ajustar parâmetros (temperatura, número máximo de tokens e etc.) e até comparar lado a lado a saída de dois modelos diferentes.

Via API/SDK: agora, caso você necessite integrar algum modelo em um projeto, o GitHub Models também disponibiliza uma API REST e SDKs para diversas linguagens, como Python, JavaScript/TypeScript, Java, C#, e REST. Cada modelo possui um endpoint de inferência público. Você pode fazer chamadas HTTP para esses endpoints ou usar SDKs (como o SDK do Azure OpenAI ou o próprio SDK do GitHub Models) em diversas linguagens.

A autenticação é feita de forma simples com um token de acesso pessoal do GitHub (PAT), sem necessidade de chaves de API separadas. Basta gerar um PAT na sua conta do GitHub (sem escopos especiais, usando a opção Beta disponível), e usá-lo nas requisições. Em outras palavras, seu token do GitHub funciona como a credencial para chamar o modelo, dentro dos limites gratuitos de uso.

Vantagens e Limitações

Mas, tudo que é gratuito tem suas limitações, certo? Então, vamos explicar as limitações do GitHub Models.

Atualmente, há restrições de chamadas por minuto e por dia, quantidade de tokens por requisição e número de requisições simultâneas. Por exemplo, modelos de categoria low (menores) permitem algo em torno de 15 requisições por minuto e 150 por dia, enquanto modelos high (como o GPT-4o) possuem limites um pouco mais baixos por serem mais pesados

Mas, e se curtiu o modelo e desejar colocar em produção? Bom, nesse caso, o GitHub Models sugere a migração para um endpoint pago do Azure – e o interessante é que basta trocar o token do GitHub por uma chave do Azure que o resto do código continuará funcionando, sem necessidade de alterações adicionais!

Resumindo: o GitHub Models é uma maneira prática de encontrar e experimentar modelos de IA de ponta gratuitamente. Com ele, desenvolvedores podem incorporar funcionalidades de IA em projetos TypeScript (ou de outras linguagens) usando apenas uma conta GitHub. A seguir, conheceremos o exemplo do Microblog AI Remix e, depois, veremos na prática como usar o GitHub Models nesse projeto.

Microblog AI Remix com GitHub Models

O Microblog AI Remix (ou simplesmente Microblog AI) é um projeto de exemplo que combina um aplicativo web de microblog com recursos de Inteligência Artificial. Ele foi criado para demonstrar como construir aplicações web modernas e escaláveis utilizando a stack da Microsoft Azure juntamente com técnicas de Server-Side Rendering (SSR) e IA generativa. Em alto nível, o Microblog AI permite que usuários criem e visualizem pequenos posts de blog (microblogs), contando com a ajuda de um modelo de IA avançado para gerar conteúdo a partir de sugestões do usuário.

Aproveito para pedir a testarem o projeto, dando um fork e contribuindo com melhorias. O projeto é open source e pode ser testado no GitHub Codespaces. Deixa a sua estrela ⭐️ e contribua com melhorias!

Originalmente o projeto utiliza o Azure OpenAI como provedor de IA, mas vamos substituí-lo pelo GitHub Models para proporcionar uma alternativa gratuita e acessível.

Passo a Passo para Configurar o Microblog AI

Eu gravei um vídeo mostrando o passo a passo em como migrar o projeto para o GitHub Models. O vídeo está disponível no meu canal do YouTube (em português) e você pode assisti-lo aqui:

Antes de tudo precisamos clonar o projeto e configurar as dependências. Siga os passos abaixo:

Clone o repositório oficial do Microblog AI Remix:

git clone https://github.com/Azure-Samples/microblog-ai-remix.git cd microblog-ai-remix

2. Instale as dependências do projeto:

npm install cd server npm install

3. Crie um arquivo .env na raiz do projeto e adicione as seguintes variáveis de ambiente:

GITHUB_MODELS_ENDPOINT=https://models.inference.ai.azure.com GITHUB_MODELS_TOKEN=SEU_TOKEN

Esse token você pode gerar na sua conta do GitHub em Settings > Developer Settings > Personal Access Tokens > Generate new token (beta).

4. No diretório /server, crie o arquivo local.settings.json com o seguinte conteúdo:

{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "UseDevelopmentStorage=true", "FUNCTIONS_WORKER_RUNTIME": "node", "GITHUB_MODELS_ENDPOINT": "https://models.inference.ai.azure.com", "GITHUB_MODELS_TOKEN": "SEU_TOKEN" }, "Host": { "LocalHttpPort": 7071, "CORS": "*", "CORSCredential": true } }

5. Agora, vá até o arquivo: app/services/openaiService.ts e faça as seguintes alterações:

Importação do Cliente OpenAI: substitua a importação do AzureOpenAI para OpenAI:

import { OpenAI } from "openai";

Renomeação da Classe e Cliente: Substituição da importação do AzureOpenAIService foi renomeada para GitHubModelsService. E, a instância do cliente AzureOpenAI foi renomeada para OpenAI. Adição de um modelName padrão (gpt-4o) para ser usado nas requisições de criação de completions. Porém aqui poderia ser quaisquer outro modelName de sua escolha, como o Llama 3.1 ou o Mistral 7B.

class GitHubModelsService { private client: OpenAI; private readonly toneGuidelines: ToneGuidelines; private readonly modelName: string = "gpt-4o"; (...)

Configuração do Cliente: As variáveis de ambiente específicas do Azure (AZURE_OPENAI_API_KEY, AZURE_OPENAI_ENDPOINT, etc.) foram substituídas por variáveis de ambiente do GitHub (GITHUB_TOKEN e GITHUB_MODELS_ENDPOINT).

this.client = new OpenAI({ baseURL: process.env.GITHUB_MODELS_ENDPOINT || "https://models.inference.ai.azure.com", apiKey: process.env.GITHUB_TOKEN, });

Exportação da Instância da Classe: A instância exportada da classe foi renomeada de azureOpenAIService para GitHubModelsService.

export const azureOpenAIService = new GitHubModelsService();

E pronto! Agora você já pode executar o projeto localmente e testar as funcionalidades de IA com o GitHub Models. Se desejar saber mais detalhes do que foi alterado deixei disponível uma branch chamada feat/github-models-usage com todas as alterações feitas. Você pode comparar com a branch main para ver o que foi modificado.

6. Por fim, para executar o projeto, basta rodar o seguinte comando na raiz do projeto:

npm run build:all npm run dev

Agora, você pode acessar a aplicação na URL: http://localhost:5173/ e começar a criar seus microblogs com a ajuda do GitHub Models!

Conclusão

O GitHub Models é uma excelente alternativa para quem quer experimentar IA sem custos. Ele permite testar modelos avançados como GPT-4o sem precisar pagar por APIs ou configurar infraestrutura complexa. No caso do Microblog AI Remix, conseguimos substituir a API paga do Azure OpenAI pelo GitHub Models com mínimas alterações no código, tornando a aplicação acessível para qualquer desenvolvedor.

Claro que, novamente, caso você queira colocar em produção, o GitHub Models sugere a migração para um endpoint pago do Azure. Mas, para fins de prototipagem e aprendizado, ele é uma ferramenta poderosa e gratuita.

Se você gostou deste artigo, não esqueça de testar o Microblog AI Remix e dar uma ⭐ no repositório! Queremos saber sua opinião sobre essa abordagem e como você pretende utilizar IA nos seus projetos.

Agora é sua vez: clone o repositório, teste as mudanças e explore o GitHub Models gratuitamente. Bora codar com IA sem gastar nada! 💸💸💸

Novidades no Visual Studio Code 1.98

cynthiazanoni — Tue, 18 Mar 2025 15:49:21 GMT

A versão 1.98 do Visual Studio Code está no ar e traz uma série de novidades que vão aprimorar ainda mais a sua experiência de desenvolvimento. Entre os destaques principais, estão recursos que integram de forma ainda mais profunda a inteligência artificial do GitHub Copilot, como o Modo Agente (prévia), o Copilot Edits para notebooks, e o inédito Copilot Vision, que permite interagir com imagens diretamente nas conversas de chat.

Se quiser conferir as atualizações completas, acesse a página de Atualizações no site oficial.

Insiders: Quer testar as novidades o quanto antes? Baixe a versão Insiders e explore os recursos mais recentes assim que estiverem disponíveis!

Copilot Agent Mode (Preview)

O Copilot Agent Mode (preview), transforma a interação com o código: ele busca automaticamente contexto no projeto, sugere comandos no terminal e edita arquivos de forma autônoma. Com isso, tarefas inteiras podem ser automatizadas!

Destaques:

Comandos de terminal visíveis inline, podendo ser editados antes da execução.
Ações de desfazer/refazer específicas para edições realizadas pelo agente.
Integração com tarefas de compilação automáticas (configurável).

Copilot Edits em Notebooks (Preview)

A partir de agora, é possível editar notebooks diretamente com o Copilot, facilitando fluxos de trabalho para cientistas de dados e profissionais que utilizam documentação técnica.

Criação, modificação e exclusão de células.
Suporte completo para diferentes tipos de células.

Interface Renovada nas Edições do Copilot

A interface de Edições foi redesenhada para melhorar a experiência de revisão de arquivos modificados. Os arquivos aparecem como anexos comuns e a lista de arquivos alterados fica logo acima do chat.

Terminal IntelliSense (Preview)

Uma verdadeira revolução para quem gosta de trabalhar no terminal: IntelliSense agora funciona direto no terminal do VS Code!

Principais benefícios:

Sugestões inteligentes para bash, zsh, fish e PowerShell.
Completions para comandos git, npm, brew, ssh e muito mais.
Integração com branches do Git, CDPATH e aliases personalizados.

Autocomplete para git checkout:

Ative o Terminal IntelliSense:

"terminal.integrated.suggest.enabled": true

Next Edit Suggestions (Preview)

O Copilot agora oferece sugestões de próximas edições, tornando o fluxo de trabalho ainda mais fluido. Com o modo colapsado, você foca apenas no que interessa:

Sugestões aparecem discretamente na margem.
Ative-as apenas quando quiser navegar até elas.

Menu de ativação do modo colapsado:

Configuração

github.copilot.nextEditSuggestions.enabled

Copilot Vision (Preview)

Nós estamos rapidamente implementando suporte de visão de ponta a ponta nesta versão do Copilot Chat. Isso permite que você anexe imagens e interaja com imagens em solicitações de chat.

Por exemplo, se você encontrar um erro durante a depuração, anexe uma captura de tela do VS Code e peça ao Copilot para ajudá-lo a resolver o problema. Você também pode anexar um mockup de UI e deixar o Copilot fornecer algum HTML e CSS para implementar o mockup.

Você pode anexar imagens de várias maneiras:

Arraste e solte imagens do seu sistema operacional ou da visualização Explorer
Cole uma imagem da sua área de transferência
Anexe uma captura de tela da janela do VS Code (selecione o botão de clipe de papel 📎 > Captura de Tela da Janela)

Um aviso é mostrado se o modelo selecionado atualmente não tiver a capacidade de lidar com o tipo de arquivo. O único modelo suportado no momento será GPT 4o, mas o suporte para anexos de imagem com Claude 3.5 Sonnet e Gemini 2.0 Flash será lançado em breve também. Atualmente, os tipos de imagem suportados são JPEG/JPG, PNG, GIF e WEBP.

Disponibilidade geral de instruções personalizadas

Instruções personalizadas permitem que você adapte o GitHub Copilot para fornecer respostas de chat e sugestões de código de acordo com a forma como você e sua equipe trabalham. Descreva seus requisitos específicos em formato Markdown em um arquivo .github/copilot-instructions.md no seu espaço de trabalho.

Neste marco, estamos disponibilizando instruções personalizadas com .github/copilot-instructions.md de forma geral. Certifique-se de que a configuração do VS Code está habilitada para que o Copilot possa utilizar essas instruções ao gerar respostas.

github.copilot.chat.codeGeneration.useInstructionFiles

Saiba mais sobre instruções personalizadas no Copilot.

Melhorias no descarte de alterações não rastreadas

Ao longo dos anos, recebemos vários relatórios sobre perda de dados porque descartar um arquivo não rastreado excluía permanentemente o arquivo, mesmo que o VS Code mostrasse um diálogo modal deixando claro que o arquivo seria excluído permanentemente.

A partir desta atualização, descartar um arquivo não rastreado moverá o arquivo para a Lixeira quando possível, para que o arquivo possa ser facilmente recuperado. Você pode ativar ou desativar essa funcionalidade acessando as configurações do VS Code e buscando por git.discardUntrackedChangesToTrash.

Hook de commit para diagnósticos (Experimental)

Introduzimos um novo hook de commit que solicita que você resolva quaisquer diagnósticos não resolvidos para os arquivos alterados. Este é atualmente um recurso experimental que pode ser habilitado usando a configuração git.diagnosticsCommitHook.Enabled.

Por padrão, o hook de commit solicita quaisquer diagnósticos de nível de erro, mas as fontes e níveis de diagnóstico podem ser personalizados usando a configuração git.diagnosticsCommitHook.Sources. Experimente e nos dê seu feedback.

Acessibilidade no Copilot Edits

Nós tornamos as Edições do Copilot muito mais acessíveis.

Agora há sinais sonoros para arquivos com modificações e para regiões alteradas (inserções, modificações e exclusões).
O visualizador de diff acessível agora está disponível para arquivos modificados. Assim como nos editores de diff, selecione kb(chatEditor.action.showAccessibleDiffView) para ativá-lo.

activeEditorState variável de título da janela

Nós temos uma nova variável setting(window.title) chamada activeEditorState para indicar informações do editor, como estado modificado, o número de problemas e quando um arquivo tem Edições (Edits) do Copilot pendentes para usuários de leitores de tela. Quando no modo otimizado para leitores de tela, isso é anexado por padrão e pode ser desativado com accessibility.windowTitleOptimized:false.

Barra de título customizada no Linux

A tão pedida barra de título customizada no Linux já está habilitada por padrão!

A barra de título customizada agora está habilitada por padrão no Linux. A barra de título customizada dá acesso a controles de layout, ao menu do Copilot e muito mais.

Você sempre pode reverter para as decorações de título nativas, seja a partir do menu de contexto da barra de título customizada ou configurando setting(window.titleBarStyle) para native.

Estamos felizes com o feedback contínuo sobre essa experiência e já estamos trabalhando para melhorá-la ainda mais em futuros releases com base nos feedbacks da comunidade.

Modelos de IA

Adicionamos mais modelos para escolher ao usar o Copilot. Os seguintes modelos estão agora disponíveis no seletor de modelo no Visual Studio Code e no chat do github.com:

GPT 4.5 (Prévia): O modelo mais recente da OpenAI, GPT-4.5, agora está disponível no Chat do GitHub Copilot para usuários do Copilot Enterprise. O GPT-4.5 é um modelo de linguagem grande projetado com capacidades avançadas em intuição, estilo de escrita e conhecimento amplo. Saiba mais sobre a disponibilidade do modelo GPT-4.5 no post do blog do GitHub.
Claude 3.7 Sonnet (Prévia): Claude 3.7 Sonnet agora está disponível para todos os clientes em planos pagos do Copilot. Este novo modelo Sonnet suporta tanto modos de pensamento quanto de não pensamento no Copilot. Nos testes iniciais, vimos melhorias particularmente fortes em cenários de agente. Saiba mais sobre a disponibilidade do modelo Claude 3.7 Sonnet no post do blog do GitHub.

Conclusão

A versão 1.98 do Visual Studio Code marca um avanço significativo na integração de inteligência artificial ao ambiente de desenvolvimento, com recursos que aumentam a produtividade e oferecem mais controle para desenvolvedores individuais e equipes. As melhorias em Copilot Agent Mode, edições em notebooks, IntelliSense no terminal e personalização de sugestões refletem um esforço contínuo da equipe do VS Code em fornecer uma experiência de desenvolvimento moderna, eficiente e acessível.

Se você deseja explorar todas essas funcionalidades, a atualização para a versão mais recente já está disponível. Além disso, os recursos em prévia podem ser testados por meio da versão VS Code Insiders.

Para mais informações e download, acesse:
➡️ Notas de versão do VS Code 1.98
➡️ VS Code Insiders

Caso tenha feedback ou sugestões sobre os novos recursos, participe das discussões na comunidade do GitHub do VS Code.

Use IA de Graça com GitHub Models e TypeScript! 💸💸💸

Glaucia_Lemos — Fri, 07 Mar 2025 02:21:44 GMT

Vamos lá!

O que é o GitHub Models?

Playground (interface web): nesse playground, você pode testar os modelos diretamente no navegador do GitHub. Nele, você pode fazer perguntas e obter respostas em tempo real com diferentes modelos, ajustar parâmetros (temperatura, número máximo de tokens e etc.) e até comparar lado a lado a saída de dois modelos diferentes.

Via API/SDK: agora, caso você necessite integrar algum modelo em um projeto, o GitHub Models também disponibiliza uma API REST e SDKs para diversas linguagens, como Python, JavaScript/TypeScript, Java, C#, e REST. Cada modelo possui um endpoint de inferência público. Você pode fazer chamadas HTTP para esses endpoints ou usar SDKs (como o SDK do Azure OpenAI ou o próprio SDK do GitHub Models) em diversas linguagens.

Vantagens e Limitações

Mas, tudo que é gratuito tem suas limitações, certo? Então, vamos explicar as limitações do GitHub Models.

Microblog AI Remix com GitHub Models

Originalmente o projeto utiliza o Azure OpenAI como provedor de IA, mas vamos substituí-lo pelo GitHub Models para proporcionar uma alternativa gratuita e acessível.

Passo a Passo para Configurar o Microblog AI

Eu gravei um vídeo mostrando o passo a passo em como migrar o projeto para o GitHub Models. O vídeo está disponível no meu canal do YouTube (em português) e você pode assisti-lo aqui:

Antes de tudo precisamos clonar o projeto e configurar as dependências. Siga os passos abaixo:

Clone o repositório oficial do Microblog AI Remix:

git clone https://github.com/Azure-Samples/microblog-ai-remix.git cd microblog-ai-remix

2. Instale as dependências do projeto:

npm install cd server npm install

3. Crie um arquivo .env na raiz do projeto e adicione as seguintes variáveis de ambiente:

GITHUB_MODELS_ENDPOINT=https://models.inference.ai.azure.com GITHUB_MODELS_TOKEN=SEU_TOKEN

Esse token você pode gerar na sua conta do GitHub em Settings > Developer Settings > Personal Access Tokens > Generate new token (beta).

4. No diretório /server, crie o arquivo local.settings.json com o seguinte conteúdo:

5. Agora, vá até o arquivo: app/services/openaiService.ts e faça as seguintes alterações:

Importação do Cliente OpenAI: substitua a importação do AzureOpenAI para OpenAI:

import { OpenAI } from "openai";

Renomeação da Classe e Cliente: Substituição da importação do AzureOpenAIService foi renomeada para GitHubModelsService. E, a instância do cliente AzureOpenAI foi renomeada para OpenAI. Adição de um modelName padrão (gpt-4o) para ser usado nas requisições de criação de completions. Porém aqui poderia ser quaisquer outro modelName de sua escolha, como o Llama 3.1 ou o Mistral 7B.

class GitHubModelsService { private client: OpenAI; private readonly toneGuidelines: ToneGuidelines; private readonly modelName: string = "gpt-4o"; (...)

Configuração do Cliente: As variáveis de ambiente específicas do Azure (AZURE_OPENAI_API_KEY, AZURE_OPENAI_ENDPOINT, etc.) foram substituídas por variáveis de ambiente do GitHub (GITHUB_TOKEN e GITHUB_MODELS_ENDPOINT).

this.client = new OpenAI({ baseURL: process.env.GITHUB_MODELS_ENDPOINT || "https://models.inference.ai.azure.com", apiKey: process.env.GITHUB_TOKEN, });

Exportação da Instância da Classe: A instância exportada da classe foi renomeada de azureOpenAIService para GitHubModelsService.

export const azureOpenAIService = new GitHubModelsService();

6. Por fim, para executar o projeto, basta rodar o seguinte comando na raiz do projeto:

npm run build:all npm run dev

Agora, você pode acessar a aplicação na URL: http://localhost:5173/ e começar a criar seus microblogs com a ajuda do GitHub Models!

Conclusão

Agora é sua vez: clone o repositório, teste as mudanças e explore o GitHub Models gratuitamente. Bora codar com IA sem gastar nada! 💸💸💸