Go no Azure Functions (Preview): o que muda para times de engenharia no Brasil

A Microsoft anunciou o suporte nativo para Go no Azure Functions (preview), permitindo que times de engenharia criem funções serverless com a produtividade de Go e a escalabilidade do Flex Consumption. O modelo code-first elimina arquivos JSON de configuração, usa triggers padrão do ecossistema Azure e gera binários estáticos. Para empresas brasileiras que já adotaram Go, isso reduz complexidade operacional e custos com infraestrutura gerenciada, viabilizando desde APIs até pipelines de integração em alta vazão.

Por que o suporte nativo a Go é relevante para o Azure Functions?

Go se tornou a linguagem padrão para APIs cloud-native, serviços de plataforma, ferramentas de rede e workloads de integração com alta throughput. Até agora, times que padronizaram Go no Azure precisavam escolher entre:

• Usar Azure Functions via custom handlers, perdendo a experiência de desenvolvimento de primeira classe.
• Construir e operar sua própria infraestrutura de serving, scaling e eventos em containers ou VMs.

Com o suporte nativo, esses times ganham a produtividade de Go combinada com a alavancagem operacional do serverless: escalabilidade automática, faturamento pay-per-use, triggers integrados ao ecossistema Azure e observabilidade embutida — tudo sem sair do ecossistema Go.

O que está disponível no preview?

• Novo modelo de programação e SDK Go: abordagem code-first e idiomática para registrar functions e declarar triggers usando opções funcionais.
• Suporte a triggers populares: HTTP, Timer, Service Bus (filas e tópicos), Event Hubs, Event Grid, Cosmos DB e Blob Storage. Mais triggers virão.
• Pipeline de build nativo Go: go build produz um único binário estático que o host do Functions invoca diretamente. Sem function.json, sem shims de interop em tempo de execução.
• Observabilidade integrada: logging, métricas e distributed tracing via Application Insights.
• Tooling completo: desenvolvimento local com uma versão preview do Azure Functions Core Tools. Deploy via Core Tools, zip deploy ou GitHub Actions.
• Flex Consumption: escala elástica rápida, scale-to-zero, faturamento por segundo, integração com VNet e instâncias always-ready.

Como funciona o modelo de programação code-first?

O modelo Go é code-first: você registra funções e declara triggers em Go, com verificações em tempo de compilação e suporte completo da IDE. Nada de metadados JSON separados para manter em sincronia.

Aqui está uma função mínima com trigger HTTP:

Copiarpackage main

import (
	"fmt"
	"net/http"

	"github.com/azure/azure-functions-golang-worker/sdk"
	"github.com/azure/azure-functions-golang-worker/worker"
)

func main() {
	app := sdk.FunctionApp()

	app.HTTP("hello", hello,
		sdk.WithMethods("GET", "POST"),
		sdk.WithAuth("anonymous"),
	)

	worker.Start(app)
}

func hello(w http.ResponseWriter, r *http.Request) {
	name := r.URL.Query().Get("name")
	if name == "" {
		name = "world"
	}
	fmt.Fprintf(w, "Hello, %s!", name)
}

Observe que o handler HTTP é um http.HandlerFunc comum — a mesma assinatura usada com net/http ou qualquer framework web Go. Não há nada específico do Functions para aprender no nível do handler.

Como registrar outros triggers?

O mesmo padrão funciona para todos os triggers. Handlers não-HTTP recebem um context.Context mais um payload tipado:

Copiarimport (
    "context"
    "log"

    "github.com/azure/azure-functions-golang-worker/sdk"
    "github.com/azure/azure-functions-golang-worker/sdk/bindings"
)

// Timer: executa a cada 10 segundos
func onTimer(ctx context.Context, t bindings.TimerInfo) error {
    log.Printf("timer fired; past due=%v", t.IsPastDue)
    return nil
}
app.Timer("cleanup", onTimer,
    sdk.WithSchedule("*/10 * * * * *"),
)

// Service Bus queue
func onOrder(ctx context.Context, msg bindings.ServiceBusMessage) error {
    log.Printf("order %s: %s", msg.MessageId, string(msg.Body))
    return nil
}
app.ServiceBusQueue("processOrder", onOrder,
    sdk.WithQueueName("orders"),
    sdk.WithConnection("ServiceBusConnection"),
)

// Event Hubs
func onEvent(ctx context.Context, e bindings.EventHubMessage) error {
    log.Printf("event seq=%d body=%s", e.SequenceNumber, string(e.Body))
    return nil
}
app.EventHub("ingest", onEvent,
    sdk.WithEventHubName("telemetry"),
    sdk.WithConnection("EventHubConnection"),
)

// Cosmos DB change feed
func onChange(ctx context.Context, docs []bindings.CosmosDocument) error {
    for _, d := range docs {
        log.Printf("doc %s: %s", d.ID, string(d.Data))
    }
    return nil
}
app.CosmosDB("onChange", onChange,
    sdk.WithDatabase("ToDoList"),
    sdk.WithContainer("Items"),
    sdk.WithConnection("CosmosDBConnection"),
)

// Event Grid
func onGridEvent(ctx context.Context, e bindings.EventGridEvent) error {
    log.Printf("%s: %s", e.EventType, e.Subject)
    return nil
}
app.EventGrid("onEvent", onGridEvent)

Triggers de extensão: clientes reais do Azure SDK

Para triggers como Blob Storage, o SDK Go injeta um cliente do Azure SDK totalmente tipado diretamente no handler. Você opta pelo blank import, de modo que seu binário inclui apenas as extensões que você realmente usa:

Copiarimport (
    "context"
    "io"
    "log"

    "github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blob"
    "github.com/azure/azure-functions-golang-worker/sdk"
    _ "github.com/azure/azure-functions-golang-worker/triggers/blob" // registra a factory do cliente blob
    "github.com/azure/azure-functions-golang-worker/worker"
)

func onUpload(ctx context.Context, client *blob.Client) error {
    log.Printf("blob: %s", client.URL())
    resp, err := client.DownloadStream(ctx, nil)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    data, err := io.ReadAll(resp.Body)
    if err != nil {
        return err
    }
    log.Printf("size=%d", len(data))
    return nil
}

app.Blob("onUpload", onUpload,
    sdk.WithPath("uploads/{name}"),
    sdk.WithConnection("AzureWebJobsStorage"),
    sdk.WithSource("EventGrid"),
)

O handler recebe um *blob.Client do pacote github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blob, o mesmo cliente que você usaria em qualquer outra aplicação Go. Por ser um cliente SDK real, você pode usar DownloadStream para blobs de qualquer tamanho sem precisar armazenar o payload inteiro no worker. As dependências ficam isoladas por extensão; aplicações que não usam Blob nunca puxam azblob ou azidentity.

Qual é a estrutura do projeto?

Uma function app em Go é apenas um módulo Go normal acrescido dos arquivos de configuração padrão do Functions:

Copiarmy-function-app/
├── host.json
├── local.settings.json
├── go.mod
├── go.sum
└── main.go

Nada de function.json e nenhum metadado gerado. Os triggers são declarados em main.go. go build, go test e go mod tidy funcionam normalmente.

Como começar?

• Quickstart: Instale as ferramentas preview, crie sua primeira function app Go, execute localmente e faça deploy para o Flex Consumption. (Link: https://aka.ms/azure-functions-go-quickstart)

A Microsoft convida a comunidade Go para experimentar e dar feedback. O preview está disponível hoje no plano Flex Consumption.

Perguntas Frequentes

• O suporte nativo a Go substitui os custom handlers que existiam antes?
  Sim, para novos projetos. O novo SDK (azure-functions-golang-worker) oferece uma experiência code-first com triggers declarados em Go, sem a necessidade de custom handlers. Projetos existentes podem migrar gradualmente.

• Quais triggers estão disponíveis no preview?
  HTTP, Timer, Service Bus (filas e tópicos), Event Hubs, Event Grid, Cosmos DB e Blob Storage. Os triggers de extensão, como Blob, injetam clientes reais do Azure SDK no handler, permitindo operações como DownloadStream sem buffering.

• É obrigatório usar o plano Flex Consumption para rodar funções em Go?
  Sim, o preview está disponível apenas no plano Flex Consumption, que oferece escalabilidade elástica, scale-to-zero, faturamento por segundo, integração com VNet e instâncias always-ready.

• Como fica a observabilidade ao usar Go no Azure Functions?
  A integração com Application Insights continua disponível, incluindo logging, métricas e distributed tracing. A mesma experiência de observabilidade que você tem com outras linguagens no Functions.

• Posso usar bibliotecas Go existentes nos meus handlers?
  Sim, o handler HTTP é um http.HandlerFunc padrão do Go, o que significa que você pode usar qualquer biblioteca ou framework compatível com net/http. Para triggers não-HTTP, o SDK fornece payloads tipados, mas você pode chamar bibliotecas livremente.

---

Artigo originalmente publicado por AnthonyChu em Azure Updates - Latest from Azure Charts.