Forem: Odilon Jonathan Kröger

Primeiros passos com Kafka - Parte 2

Odilon Jonathan Kröger — Mon, 08 Mar 2021 00:15:48 +0000

Créditos da foto de capa: Margan Zajdowicz from FreeImages

E lá vamos nós para a continuação do papo sobre Kafka!

Hoje em dia é muito comum o uso do formato JSON quando estamos enviando ou recebendo dados em nossos serviços.
Embora não seja o mais comum, você também pode utilizar JSON quando for trabalhar com Kafka.
Dependendo do tipo de linguagem que você for utilizar para seus serviços, outros formatos mais indicados seriam Protocol Buffers ou Avro. Como Protocol Buffer possúi gerador de código para diversas linguagens e também passou recentemente a ser suportado pela plataforma da Confluent, eu indico que você considere o uso de Protocol Buffers em vez de Avro. Mas isso é papo para outra publicação.

Hoje vamos ver quais comandos podemos utilizar para enviar mensagens JSON no Kafka.
Eu gosto muito de poder mostrar um exemplo como estes em JSON, porque fica mais fácil para entender como as coisas funcionam e se você for em algum momento utilizar a plataforma da Confluent, fica mais fácil para realizar os testes iniciais.

Do que vamos precisar?

Conforme vimos na Parte 1, vamos precisar de pelo menos um nó do Kafka rodando.

Que tal utilizarmos como exemplo plantas?
Vamos iniciar criando um tópico.

docker-compose exec broker kafka-topics --create \
    --bootstrap-server broker:9092 \
    --topic plantas \
    --partitions 3 \
    --replication-factor 1

Imagine que estamos utilizando o Kafka para controle lotes de plantas que são vendidos.
Cada lote possui um código identificador, o valor do lote, de qual planta é composto o lote, e estufa onde está localizado o lote para a retirada.

Poderíamos pensar no seguinte modelo para as mensagens:

{
   "lote": "abc-123",
   "valor": 123.45,
   "planta": "abcde",
   "estufa": "estufa-a"
}

Enviando mensagens JSON para o Kafka

Agora que temos um contexto, vamos criar algumas mensagens nesse tópico.

Uma forma seria utilizando o comando kafka-console-producer como vimos na publicação anterior. Porém, não é exatamente prático quando queremos enviar algo no formato JSON.

Recentemente eu descobri o kafkacat.
Para utilizar o kafkacat podemos instalar a ferramenta, ou da forma que eu costumo utilizar, através de um container no Docker.
Abaixo temos um exemplo de como podemos utilizar esta ferramenta para enviar mensagens no formato JSON, sem precisar instalar o kafkacat.

docker run -i --rm --network cp-all-in-one_default edenhill/kafkacat:1.6.0 -P -b broker:29092 -t plantas \
<<EOF

{"lote":"abc-123","valor":1500.57,"planta":"orquidea phalaenopsis","estufa":"orq-1"}
{"lote":"efg-432","valor":430.00,"planta":"bromelia ruby","estufa":"brm-4"}
{"lote":"xyz-987","valor":235.00,"planta":"bromelia fasciata","estufa":"brm-1"}
EOF

Pronto! Não tem segredo!
Vou explicar um pouco sobre os parâmetros acima.
Repare que foi necessário passar o --network do Docker. Isso é necessário para que o container consiga acessar os demais containers que estão rodando no Docker, ou seja, aquele que subimos ao executar o docker-compose da primeira publicação.
Quando executamos o comando, passamos o argumento -P para informar que estamos produzindo mensagens. O -b é onde informamos em qual nó do Kafka vamos produzir as mensagens.
Já o -t serve para informarmos em qual tópico as mensagens serão escritas.
Em seguida, utilizo o bom e velho comando EOF que você pode executar em qualquer sistema Unix.

E para consumir essas mensagens?

Para conseguir consumir essas mensagens no terminal, você pode fazer exatamente como na publicação anterior, utilizando o comando kafka-console-consumer.
Por outro lado, se você estiver consumindo mensagens JSON em alguma aplicação, será necessário mapear corretamente o modelo da mensagem.

Mas você também pode usar o kafkacat para ler as mensagens:

docker run -i --rm --network cp-all-in-one_default edenhill/kafkacat:1.6.0 -G meu-grupo -b broker:29092 plantas

Aqui nós temos de diferente apenas o -G, que serve para informar qual é o nome do grupo consumidor.

Ah, mais uma coisa sobre o kafkacat

Se você quiser, pode enviar mensagens com uma chave utilizando esta ferramenta.
Pensando no mesmo exemplo de plantas, poderiamos apenas adicionar o parâmetro -K: e a chave antes de cada mensagem, como no comando abaixo.

docker run -i --rm --network cp-all-in-one_default edenhill/kafkacat:1.6.0 -P -b broker:29092 -t plantas -K: \
<<EOF

1:{"lote":"foo-466","valor":60.50,"planta":"cactus enxertado","estufa":"cac-1"}
2:{"lote":"bar-311","valor":430.00,"planta":"bromelia ruby","estufa":"brm-3"}
3:{"lote":"usd-560","valor":440.00,"planta":"bromelia lingulata","estufa":"brm-3"}
EOF

E é isso!

Bastante simples, não é mesmo?

Agora você já conhece a parte básica de como enviar e consumir mensagens de texto e também JSON no Kafka.

Espero que estas duas publicações tenham sido de alguma ajuda! Até a próxima!

Primeiros passos com Kafka - Parte 1

Odilon Jonathan Kröger — Sun, 28 Feb 2021 00:08:23 +0000

Imagem de capa feita por Kaitlyn Baker. Disponível na plataforma Unsplash.

Beleza?

Nesta publicação vou apresentar alguns comandos do Kafka.
Vou tentar apresentar os comandos da forma mais fácil, sem precisar ficar instalando a plataforma inteira - isso é possível graças ao Docker.

Então prepara o café ou chá, abre o editor de texto para fazer suas anotações e vamos nessa, publicar e consumir mensagens no Kafka.

O que vamos ver nesta publicação?

Como subir as imagens necessárias para ter um nó do Kafka rodando na sua máquina.
Como criar, alterar e deletar tópicos.
Como produzir mensagens nos tópicos.
Como podemos ler as mensagens que estão armazenadas em um tópico.

Ah, tem um detalhe! Os comandos que vou mostrar estou executando num terminal do Linux.

E o que não vamos ver nesta publicação?

Não vou entrar nos detalhes de funcionamento do Kafka.
Se você não conhece absolutamente nada de Kafka e chegou até esta publicação, sugiro fortemente que antes de qualquer coisa você leia o artigo Uma introdução ao Apache Kafka. Lá você vai encontrar todas as informações teóricas necessárias para entender como que o Kafka funciona.

Também não vou mostrar como instalar, nem os detalhes de funcionamento do Docker.
Sabendo o básico de Docker já é o suficiente para conseguir executar tudo oque será explicado abaixo.
De qualquer forma, para executar os comandos abaixo é esperado que você tenha funcionando na sua máquina o Docker e o docker-compose.

Como subir o Kafka na minha máquina?

Algumas pessoas curtem instalar tudo na máquina. Eu não sou uma dessas pessoas! :)
Minha sugestão é utilizar o Docker para subir o ambiente.
Para deixar a coisa ainda mais fácil, a Confluent disponibiliza arquivos docker-compose.yml com toda configuração necessária já pronta.

Primeiro vamos precisar baixar o repositório contendo esses arquivos: https://github.com/confluentinc/cp-all-in-one

Agora acesse a pasta cp-all-in-one/cp-all-in-one. Você verá que ali está o arquivo docker-compose.yml necessário para rodar o Kafka localmente.
Recomendo que você dê uma olhada no arquivo para entender quantas configurações teríamos que fazer na mão se não fosse por esta facilidade.

Se você quiser, pode comentar todos os serviços com excessão do zookeeper e do broker. Nestes exemplos serão os únicos dois serviços utilizados.

Nesse mesmo diretório do arquivo, vamos executar o comando necessário para subir todo o ambiente:

docker-compose up -d

Na primeira vez vai demorar um pouco, pois o Docker terá que baixar diversas imagens (cada uma daquelas que estão no docker-compose.yml).

Quando o comando acima estiver concluído, você pode seguir para os próximos passos.

Quero criar um tópico!!!

Como eu quero facilitar a coisa nessa publicação, eu não vou ficar entrando nos containers para executar os comandos. Como o docker-compose deixa que a gente execute através dele, vamos fazer uso dessa funcionalidade.
Repare que vamos sempre utilizar o kafka-topics nos comandos abaixo.

Execute o comando abaixo para criar o primeiro tópico. Vamos chamar ele de topico_teste.

docker-compose exec broker kafka-topics --create \
    --bootstrap-server broker:9092 \
    --topic topico_teste \
    --partitions 3 \
    --replication-factor 1

O que é isso aí tudo?
Estamos pendindo para o docker-compose executar dentro do container broker o comando kafka-topics e seus argumentos.
--create para dizer que queremos criar um tópico.
--bootstrap-server é onde informamos o endereço do Kafka onde queremos criar o tópico. Este endereço que utilizamos é baseado no arquivo docker-compose.yml.
--topic é onde informamos o nome do tópico.
--partitions serve para dizermos quantas partições o tópico vai ter.
--replication-factor é utilizado para dizer em quantos nós este tópico deverá ser replicado. Para o nosso exemplo é necessário deixar 1, senão não vai funcionar, pois só temos um nó rodando. Mas em um cluster "pra valer", com toda certeza você vai precisar replicar mais do que em apenas 1 nó.

Se você quiser, pode executar o comando abaixo listar todos os tópicos.

docker-compose exec broker kafka-topics --list \
    --bootstrap-server broker:9092

Para modificar um tópico:

docker-compose exec broker kafka-topics --alter \
    --bootstrap-server broker:9092 \
    --topic topico_teste \
    --partitions 10

Se você quiser saber detalhes de como está o seu tópico, é possível utilizar o comando --describe:

docker-compose exec broker kafka-topics  --describe \
    --bootstrap-server broker:9092 \
    --topic topico_teste

Vamos iniciar um consumidor.

Antes de começar a produzir mensagens, eu acho legal iniciar um consumidor para o tópico, assim podemos ver em tempo real a coisa funcionando!

Para iniciar um consumidor, vamos usar o kafka-console-consumer.
Basta executar o comando abaixo para iniciar o consumo de mensagens do seu tópico topico_teste.

docker-compose exec broker kafka-console-consumer \
    --bootstrap-server broker:9092 \
    --topic topico_teste

Agora quero mandar mensagens para este tópico!

Legal! Para deixar ainda mais legal a experiência, deixe o consumidor rodando em uma outra aba do terminal, ou outro terminal, ou qualquer coisa assim para poder ver a coisa acontecendo ao mesmo tempo.

Vamos agora utilizar o kafka-console-producer. O comando para iniciar o producer está logo abaixo. Quando você executar, ele ficara ativamente enviando tudo que você digitar para o tópico. Para parar o producer basta pressionar Ctrl+C.

docker-compose exec broker kafka-console-producer \
    --bootstrap-server broker:9092 \
    --topic topico_teste

E se eu quiser deletar o tópico?

Primeiro você precisa parar o seu consumidor e também o produtor de mensagens.
Em seguida, basta utilizar o kafka-topics passando por parâmetro --delete.

docker-compose exec broker kafka-topics  --delete \
    --bootstrap-server broker:9092 \
    --topic topico_teste

É isso aí!

Kafka é uma ferramenta bastante poderosa, cheia de funcionalidades e configurações para conseguir ser uma ferramenta eficaz em diversos cenários diferentes.
Mas isso não dignifica que precisa ser difícil!

A ferramenta tem evoluído nesse sentido e após você "brincar" algumas vezes produzindo e consumindo mensagens, acaba se tornando cada vez mais fácil o entendimento de como cada uma das coisas funciona no Kafka.

Para não deixar o texto gigante, vou fechar por aqui. Mas numa próxima vou mostrar como podemos enviar mensagens no formato JSON!!!

Até lá! \o

AWS Elastic Beanstalk + Go

Odilon Jonathan Kröger — Wed, 06 Jan 2021 01:44:04 +0000

Foto de capa: Gelgas Airlangga

Vamos lá para um pequeno tutorial ensinando o passo-a-passo de como subir uma aplicação Go no serviço Elastic Beanstalk da AWS.
Vou utilizar o AWS CLI porque acho legal para a pessoa que está iniciando saber exatamente todas as coisas que acontecem. Até porque se você em algum momento quiser utilizar Terraform, já tem uma boa idéia do que você vai precisar utilizar da AWS.

Antes de começarmos a ver código e comandos, quero pontuar aqui algumas coisas:

Estou escrevendo este tutorial considerando que você já tem uma conta na aws. Para resumir, aqui não estou ensinando a criar uma conta.
Também considero que você já tem instalado o AWS CLI. Se não tiver, basta seguir a documentação oficial em português que não tem mistério.
Por fim considero que você está ciente que a execução destes serviços na AWS podem resultar em custos. No meu caso, só para rodar os comandos desse tutorial para validar que está tudo funcionando me custou U$0.10 e eu terminei tudo logo em seguida para não gerar mais custos.

Hoje a trilha sonora é Anti-Flag - Turncoat.

Escrevendo a aplicação para usar de exemplo

O código do exemplo é uma coisa bastante simples, apenas 2 endpoints: um de health check e outro para hello world.
Vamos criar um arquivo chamado application.go e escrever o código abaixo.

package main

import (
    "fmt"
    "net/http"
)

func main() {
    fmt.Println("Hello World")
    http.HandleFunc("/hello-world", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello world!")
    })
    http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "OK")
    })
    _ = http.ListenAndServe(":5000", nil)
}

Caso você ainda não conheça muito de Go, o código dentro da função main está mapeando 2 endereços, no caso /hello-world e /health. As linhas com fmt.Fprintf são responsáveis pela mensagem que será exibida na tela.
Logo depois do mapeamento estamos dizendo que a aplicação vai ficar ouvindo a porta 5000.

Atençãããão!!! Tem alguns detalhes até aqui.

Por que o arquivo se chama `application.go` e não `maldicao.go`?

A documentação da AWS diz que existem algumas formas de fazer deploy da aplicação.
A que eu escolhi para este exemplo eu achei ser a mais simples de todas, que é dar o nome de application.go para o arquivo principal. Isso porque quando o Elastic Beanstalk for construir ("buildar") a aplicação, ele vai rodar por padrão esse comando aqui: go build -o bin/application application.go, ou seja, o Elastic Beanstalk já ta lá esperando encontrar esse arquivo com esse nome.

E a porta, por que é 5000 e não 8123?

Mesma situação que o nome do arquivo. Por padrão o Elastic Beanstalk inicia a aplicação na porta 5000.

Clique aqui caso queira ler a documentação oficial da AWS sobre isso que expliquei acima.
Aliás, eu recomendo pare para ler a documentação sempre que estiver estudando algo. Ás vezes a pessoa que está escrevendo o tutorial, tipo eu agora, acaba deixando algo passar, ou entendeu algo errado ou ainda o tutorial pode estar desatualizado, então crie o hábito de validar na documentação. Isso vai agregar um conhecimento legal para você! :)

Ah, antes de irmos para os comandos AWS CLI, também vamos precisar criar um arquivo chamado options.json. Ele é necessário para informar qual profile IAM nossa aplicação vai utilizar. Se você não sabe o que é IAM, não se preocupe, isto é assunto para outro tutorial.
Coloque isto dentro do arquivo:

[
  {
      "Namespace": "aws:autoscaling:launchconfiguration",
      "OptionName": "IamInstanceProfile",
      "Value": "aws-elasticbeanstalk-ec2-role"
  }
]

Utilizando Elastic Beanstalk

Beleza! Código feito, vamos para a parte tão aguardada: como fazer deploy desse código no Elastic Beanstalk.

Passo 1: gerar um .zip com o nosso código fonte. Este .zip será enviado para a AWS e pode ter o nome que você preferir.
No caso do meu exemplo eu só tenho dois arquivos para colocar no .zip: application.go e go.mod.

No terminal, navege até a raiz do projeto e execute:

zip -r application.zip .

Passo 2: criar um S3 Bucket para enviar o arquivo .zip. Você pode criar com o nome que você quiser, eu fiz uma mistura de nome legível + o final de um UUID que gerei no Google e ficou assim: beanstalk-app-660390121deb.
O comando para criar o Bucket:

aws s3api create-bucket --bucket beanstalk-app-660390121deb --create-bucket-configuration LocationConstraint=us-west-2

No caso --bucket serve para dizer qual é o nome desejado. Caso você esteja utilizando alguma região diferente de us-east-1, é necessário também adicionar o --create-bucket-configuration LocationConstraint=AQUI_A_SUA_REGIAO para indicar a região correta.

Passo 3: enviar o .zip para o Bucket.
Esse passo é muito fácil, só executar aí:

aws s3 cp application.zip s3://beanstalk-app-660390121deb/

Passo 4: chegou a hora de criar uma aplicação dentro do Elastic Beanstalk. Esse passo também é bastante simples:

aws elasticbeanstalk create-application --application-name minha-app-muito-legal --region us-west-2

Passo 5: criar uma versão da aplicação no Elastic Beanstalk, apontando para o arquivo .zip no S3 Bucket.
Na real, isso significa que você está falando que a v1 por exemplo, utiliza o arquivo minha_app_v1.zip por exemplo. Aí depois se você for mexer no seu código e quiser subir uma v2, você poderia subir no Bucket um arquivo minha_app_v2.zip e fazer esse "link" com este comando aqui gerando uma v2, só precisaria alterar aqui no comando o parâmetro passado em --version-label.
O comando para criar a versão v1:

aws elasticbeanstalk create-application-version --application-name minha-app-muito-legal --version-label v1 --source-bundle S3Bucket=beanstalk-app-660390121deb,S3Key=application.zip

Passo 6: chegou a hora de criar um environment no Elastic Beanstalk. O comando é:

aws elasticbeanstalk create-environment --application-name minha-app-muito-legal --environment-name staging --option-settings file://options.json --version-label v1 --solution-stack-name "64bit Amazon Linux 2 v3.1.4 running Go 1"

Explicando melhor: estamos passando por parâmetro o nome da aplicação que estamos ligando neste novo environment. No --application-name eu digo qual é a aplicação que eu quero rodar, no --environment-name eu posso colocar o nome que eu quiser para o meu ambiente, no caso chamei de staging. Agora o --solution-stack-name é que requer um pouco mais de atenção. Este é o nome da stack que será utilizada no ambiente e deve ter um valor conhecido pelo Elastic Beanstalk. Você pode encontrar todas as opções disponíveis nesta documentação. Basta clicar na linguagem que você tiver curiosidade que a doc vai mostrar as opções válidas.
Aqui também foi utilizado o arquivo options.json que criamos anteriormente e passamos no comando --version-label v1 para dizer que o ambiente vai utilizar aquela versão que criamos no Passo 5. Se você deu um nome diferente de v1, vai precisar alterar aqui também.

PRONTO! Agora você já tem a aplicação rodando no Elastic Beanstalk.
Para o deploy acontecer (ou terminar os serviços), ás vezes demora um pouco. Você pode conferir o status pelo terminal com o comando abaixo:

aws elasticbeanstalk describe-environments

Ou se preferir, basta acessar o serviço Elastic Beanstalk no Console da AWS.

Na imagem abaixo que mostra o Console da AWS, fica fácil de obter diversas informações.

Quando health mudar para OK, sabemos que acabou o deploy e podemos testar a aplicação.
Já na coluna URL temos o endereço da aplicação que vamos usar para testar.

Assim que a coluna health ficar OK (talvez seja necessário recarregar a página), você já pode testar. É só copiar a URL ali da tabela e adicionar no final /health ou /hello-world que são os 2 endpoints disponíveis na aplicação.

Se deu tudo certo, você vai ver algo parecido com a imagem a seguir:

Agora digamos que você queira adicionar um novo endpoint, ou remover. Vai precisar criar uma nova versão. Para isso você vai precisar repetir o Passo 1, criando um novo arquivo .zip, em seguida vai precisar executar o Passo 3 para enviar esse arquivo para o S3 Bucket. Em seguida vai precisar executar novamente o Passo 5 alterando o nome da versão no --version-label. E finalmente será necessário fazer a atualização da versão no environment com o comando abaixo, alterando --version-label para a versão desejada:

aws elasticbeanstalk update-environment --application-name minha-app-muito-legal --environment-name staging --version-label v2

NAO ESQUEÇA DE TERMINAR A APLICAÇÃO!

Para evitar custos desnecessários, nunca esqueça de parar suas aplicações na AWS.
No nosso caso podemos fazer isso da seguinte forma para remover o environment:

aws elasticbeanstalk terminate-environment --environment-name staging

Agora vamos remover a aplicação do Elastic Beanstalk:

aws elasticbeanstalk delete-application --application-name minha-app-muito-legal

E por fim para remover o S3 Bucket:

aws s3 rb s3://beanstalk-app-660390121deb --force

Nesse caso é necessário utilizar --force para remover o Bucket e deletar os arquivos existentes. Sem este parâmetro é necessário primeiro esvaziar o Bucket para depois remover ele.

Agora você já conhece todos comandos necessários para realizar o deploy utilizando AWS CLI.
Este foi um exemplo bastante simples. Agora você pode expandir conforme a necessidade, adicionando na aplicação um banco de dados ou fila SQS, por exemplo.

Outra possibilidade de continuação dos estudos seria transformar todos estes comandos em "receitinhas" no Terraform.

Espero que você tenha curtido essa experiência! Tudo de bom para você! :)

Processamento assíncrono utilizando Go e RabbitMQ. Parte 2

Odilon Jonathan Kröger — Sun, 28 Jun 2020 21:14:17 +0000

Foto de capa: Mika Baumeister no site Unsplash.

Chegou a hora de ver código!!!

O código fonte se encontra em um monorepo.

Dentro do repositório você pode encontrar o Dockerfile e também o Makefile para conseguir buildar e rodar o projeto. As informações necessárias de como rodar se encontram no README.

Apenas para deixar claro, a intensão deste projeto é apenas exemplificar uma forma de processamento assíncrono. O código não foi feito pensando na melhor forma de reutilização de código, nem considera as configurações pensando em ambiente produtivo.
A ideia é passar o conceito (publicação anterior) e um exemplo de como começar a brincar com processamento assíncrono em sua casa! :)

Exemplo de microsserviço Estoque

Nesta publicação vou abordar a explicação sobre o Estoque.
Para facilitar o entendimento, sugiro deixar aberto em uma aba ao lado ou em seu editor o código fonte que está aqui.

O exemplo está dividido de forma bastante simples. Um arquivo main.go na raiz e outro pacote rabbit.go dentro do diretório pkg.

Pacote rabbit.go 🐰

Este pacote é bastante simples. Nele fica a implementação que faz comunicação com a API do RabbitMQ.
A implementação é baseada nos exemplos contidos na documentação oficial do RabbitMQ.

func NewDefaultChannel() *amqp.Channel {
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "Failed to connect to RabbitMQ")
    ch, err := conn.Channel()
    failOnError(err, "Failed to open channel")
    return ch
}

Esta função inicia uma conexão com o RabbitMQ, utilizando o usuário guest, no host/port localhost:5272.
É feita a validação se retornou algum erro, em seguida é aberto um canal de comunicação com o RabbitMQ, chamando conn.Channel().
Após nova verificação para ver se houve falha, é retornado o canal de comunicação com o RabbitMQ.

As próximas funções são bastante simples. Elas são utilizadas no arquivo main.go para declarar exchange e queue.
Elas recebem por parâmetro informações como nome, tipo e argumentos de configuração.

func DeclareExchange(ch *amqp.Channel, n, t string, args amqp.Table) {
    err := ch.ExchangeDeclare(
        n,
        t,
        true,
        false,
        false,
        false,
        args,
    )
    failOnError(err, "Failed to declare exchange "+n)
}

func DeclareQueue(ch *amqp.Channel, n string, args amqp.Table) {
    _, err := ch.QueueDeclare(
        n,
        true, false,
        false,
        false,
        args,
    )
    failOnError(err, "Failed to declare queue "+n)
}

A próxima função é utilizada quando queremos criar a ligação entre uma exchange e uma queue.

func BindQueue(ch *amqp.Channel, e, q, k string) {
    err := ch.QueueBind(
        q,
        k,
        e,
        false,
        nil)
    failOnError(err, "Failed to bind "+e+" with "+q)
}

Nesta função recebemos o nome da exchange, o nome da queue a uma chave de roteamento k.
Essa chave de roteamento é que faz a exhange saber direcionar uma mensagem para a queue correta.
O RabbitMQ permite configurar de diversas formas essa ligação entre exhanges, queues e routingKeys.
Mais detalhes você pode encontrar na documentação de roteamento do RabbitMQ.

func Publish(ch *amqp.Channel, m []byte, e, k string) {
    err := ch.Publish(
        e,
        k,
        false,
        false,
        amqp.Publishing{
            ContentType: "application/json",
            Body:        m,
        })
    failOnError(err, "Failed to publish on exchange "+e)
}

Finalmente temos a função que envia uma mensagem para o RabbitMQ.
O parâmetro m é uma mensagem no formato JSON, e é o nome da exchange que receberá a mensagem e k é a chave de roteamento.

Agora vamos ver o arquivo main.go

A primeira coisa que vamos olhar é a declaração de constantes.

const (
    productionOrderExchange = "productionorder"
    deadLetterExchange      = "productionorder.dlx"
    createQueue             = "create.productionorder"
    deadLetterQueue         = "create.productionorder.dlx"
    routingKey              = "create"
)

Aqui temos declarados os nomes de todas exchanges, queues e routingKey utilizados no microsserviço.
Para deixar mais fácil de encotrar as coisas no Management do RabbitMQ, deixei dlx como sufixo para a exchange e queue de dead-letter.

type message struct {
    RefCode   uuid.UUID
    ColorCode uuid.UUID
    Quantity  int
}

Esta é a estrutura da mensagem enviada para o RabbitMQ. Temos um RefCode que é o código do pedido.
O atributo ColorCode é utilizado para identificação da cor que deve ser produzida e quantity é simplesmente a quantidade de esmaltes que deve ser produzida.

Entendendo a função main()

Antes de mais nada estou criando um canal de comunicação com o RabbitMQ, fazendo uso do pacote declarado em rabbit.go.

    ch := rabbit.NewDefaultChannel()
    defer ch.Close()

Em seguida eu trato da declaração das exchanges.

    exchangeArgs := make(amqp.Table)
    exchangeArgs["x-delayed-type"] = "direct"

    rabbit.DeclareExchange(ch, productionOrderExchange, "x-delayed-message", exchangeArgs)
    rabbit.DeclareExchange(ch, deadLetterExchange, "direct", nil)

Eu crio um mapa de argumentos em make(amqp.Table).
Para conseguir utilizar o plugin Delayed Message, é preciso adicionar o argumento x-delayed-type com o valor direct.
Seria basicamente como criar uma exchange do tipo direct, mas que saiba trabalhar com delay nas mensagens.

Depois eu declaro as duas exchanges necessárias para esse projeto. Uma contendo os argumentos para trabalhar com delay, outra para tratar as dead-letters.
Na deadLetterExchange eu não adiciono a configuração de delay, porque não quero esse comportamento sendo executado para a DLQ.

    queueArgs := make(amqp.Table)
    queueArgs["x-max-length"] = 3
    queueArgs["x-dead-letter-exchange"] = deadLetterExchange

    rabbit.DeclareQueue(ch, createQueue, queueArgs)
    rabbit.DeclareQueue(ch, deadLetterQueue, nil)

Agora eu crio os argumentos de configuração para fila. O argumento x-max-length configura qual o tamanho da fila. Nesse exemplo, caso a fila já tenha 3 mensagens aguardando processamento, novas mensagens recebidas são automaticamente direcionadas para a DLQ.
O argumento x-dead-letter-exchange é que informa qual é a exchange responsável pela DLQ.

Em seguida, eu faço a declaração das duas queues: a normal, com os argumentos de configuração, e a deadLetterQueue, que é a DLQ do projeto.

    rabbit.BindQueue(ch, productionOrderExchange, createQueue, routingKey)
    rabbit.BindQueue(ch, deadLetterExchange, deadLetterQueue, routingKey)

Este é o código responsável por criar a ligação entre as exchanges, queues e routingKey.

E finalmente, vamos para a publicação da mensagem.

    m := createMsgAsJSON()
    rabbit.Publish(ch, m, productionOrderExchange, routingKey)

Eu crio uma mensagem com a função createMsgAsJSON(), que cria dados aleatórios e retorna a estrutura message no formato JSON.
Essa mensagem então é enviada para o RabbitMQ. A função rabbit.Publish recebe a mensagem, a exchange que deve tratar a mensagem e também a routingKey.
Aqui neste exemplo estamos apenas tratando da criação de pedidos, mas poderíamos ter outras chaves de roteamento, como delete e update. Assim como o caso das exchanges e queues, o nome das chaves de roteamento é você que escolhe conforme sua necessidade. :)

Conclusão

A solução ficou maior do que utilizar uma simples requisição HTTP, mas acaba não sendo um bicho de sete cabeças.
Poder trabalhar com o Estoque, sem sofrer impacto negativo no caso da OrdemDeProducao estar fora do ar, é um grande ganho!

Ao rodar o Estoque, é possível ver na prática que podemos disparar N mensagens sem nos preocuparmos com a OrdemDeProducao.

Na próxima publicação da série vou comentar sobre a implementação da OrdemDeProducao. Até lá! o/

Processamento assíncrono utilizando Go e RabbitMQ. Parte 1

Odilon Jonathan Kröger — Mon, 15 Jun 2020 02:31:16 +0000

Crédito da imagem de capa: Joanna Kosinska no Unsplash

Algum tempo atrás compartilhei uns artigos falando sobre reprocessamento de mensagens.
Como é algo que acabo utilizando bastante, achei bacana criar um artigo cobrindo a ideia de como e, porque considerar o reprocessamento de mensagens na comunicação entre microsserviços.
Como acabou ficando bastante grande o texto, o conceito da solução será abordado neste texto e a implementação será analisada no próximo artigo.

Escolhi o RabbitMQ para este exemplo por ser um broker de mensageria bastante adotado no mercado, fácil de conseguir rodar localmente e também é uma ferramenta bastante completa.
De qualquer forma, não se prenda a linguagem ou ao broker de mensageria escolhido. Absorva o conceito!
Ao compreender como, quando e, porque utilizar uma determinada solução, você pode replicar com facilidade em praticamente qualquer linguagem de mercado e com algumas variações de ferramentas utilizadas. Por exemplo, poderia ser utilizado ZeroMQ, ActiveMQ, NATS ou até mesmo Kafka no lugar do RabbitMQ.
Embora eu explore algumas poucas features do RabbitMQ, não é intensão deste artigo mostrar o RabbitMQ no detalhe, nem ensinar como configurá-lo para ambiente de produção.

Entendendo o problema

Vamos imaginar um sistema que foi desenvolvido para uma fábrica de esmaltes que está investindo pesado em automação. Nossa tarefa é melhorar uma parte específica do sistema, entre o controle do estoque de esmaltes e a geração de novas ordens de produção.
O sistema é distribuído entre diversos microsserviços, mas para nossa tarefa, apenas nos interessam dois microsserviços: Estoque e OrdemDeProducao.

Quando o estoque de uma determinada cor da coleção vigente está abaixo de 30%, o microsserviço de Estoque automaticamente dispara uma mensagem para o microsserviço OrdemDeProducao, gerando uma ordem de produção para o esmalte em questão.
O serviço se comunica de forma síncrona utilizando requisições HTTP.
E o que acontece se no momento que o Estoque precisar gerar uma ordem de produção, e o microsserviço OrdemDeProducao estiver fora do ar? E se apresentar muita lentidão por algum motivo qualquer, retornando timeout para o microsserviço Estoque?

Resolvendo o impacto no lado do microsserviço Estoque

Algo que podemos observar é que esta funcionalidade de gerar uma ordem de produção, não precisa de um retorno imediato. O serviço Estoque apenas precisa gerar a ordem de produção, não faz diferença se isto vai acontecer agora, em 10 minutos ou 30 minutos.
Então podemos entender que esta comunicação não precisa ser síncrona! Podemos resolver esta comunicação utilizando uma fila de mensagens. Dessa forma, o serviço Estoque pode enviar quantas mensagens quiser para a fila, que conforme o serviço OrdemDeServico estiver disponível, ele irá consumir as mensagens da fila para processamento.
Vamos utilizar o RabbitMQ como broker de mensagens.

Pronto! Primeiro problema resolvido. Agora caso o microsserviço OrdemDeProducao esteja fora do ar ou com muita lentidão, não irá causar impacto para o microsserviço Estoque.
A imagem abaixo mostra que mesmo que o serviço OrdemDeProducao nao consiga processar nada, o Estoque pode continuar disparando mensagens sem qualquer problema.
Quando a OrdemDeProducao voltar a funcionar, as mensagens que estão na fila voltam a ser processadas.

Mas ainda temos outro problema!
Imagine que o serviço OrdemDeProducao está falhando, porque algum outro serviço está fora do ar. Digamos que seja o banco de dados que não está respondendo.
O que acontece com a mensagem que estamos tentando processar?

Poderíamos jogar novamente a mensagem na fila, para continuar tentando reprocessar!!!
Na verdade, não é bem assim.

Se jogarmos novamente a mensagem para a fila, imediatamente o serviço OrdemDeProducao irá consumir a mensagem e tentar processá-la. Em um cenário que temos muitas mensagens na fila, estaríamos apenas executando à toa repetida e rapidamente sem necessidade.

Aí que entra uma feature bacana do RabbitMQ, chamada Delayed Messages.
Caso o processamento da mensagem falhe, podemos jogá-la novamente na fila, mas informando que ela deve ser processada novamente apenas daqui a alguns minutos.
Dessa forma, antes de tentar reprocessar a mensagem, existe um tempo que podemos aguardar esperando que a falha seja resolvida.

Dead Letter Queue (DLQ)

O que acontece se ocorrer de muitas mensagens acumularem na fila?
As mensagens excedentes que forem chegando, podem ser diretamente desviadas para uma fila chamada dead-letter-queue (DLQ).

Inclusive, podemos fazer uso de mais outra feature, chamada Dead-Lettered Effects. Assim podemos melhorar ainda mais nosso processo de retentativas, adicionando uma quantidade máxima de retentativas no header da mensagem. Caso o número máximo de retentativas seja ultrapassado, podemos desviar a mensagem com falha para aí sim ocorrer a análise manual da situação.
Podemos por exemplo, definir que a quantidade máxima de retentativas será 3 vezes e após estas falhas, a mensagem será desviada para outra DLQ para armazenamento e disparar um alerta para a pessoa responsável analisar manualmente a situação.

Caso o problema tenha sido apenas indisponibilidade de algum serviço e a solução seja apenas reprocessar as mensagens, exite um plugin chamado Shovel que permite jogar todas mensagens de uma fila para outra.

Resumo da solução

A comunicação era síncrona (HTTP). Ao identificar que ela pode ser assíncrona, passamos a realizar a comunicação utilizando mensageria.
Em caso de falha no processamento da mensagem, ela será enviada novamente para a fila com um tempo de delay até a próxima retentativa.
Definimos uma quantidade máxima de retentativas. Caso seja atingida a quantidade máxima, a mensagem é desviada para uma DLQ, onde aguardará por tratamento manual.

A solução é bem mais complexa do que uma simples requisição HTTP, mas agora conseguimos garantir que mesmo que o serviço OrdemDeProducao esteja com algum problema, ele não irá impactar o Estoque.
O isolamento de um problema é algo bastante importante que deve ser lembrado ao desenhar uma solução.
Também estamos evitando a análise manual por qualquer tipo de falha, dando a oportunidade para o sistema se recuperar e dar vazão no processamento das mensagens sem intervenção humana.
Neste exemplo do artigo, a intervenção humana só é necessária em casos graves de falha onde a OrdemDeProducao não consegue de forma alguma voltar a processar as mensagens.

Ah, mais uma coisa! Embora o exemplo acima esteja mostrando microsserviços separados para Estoque e OrdemDeProducao, essa solução também pode ser adaptada para processamento assíncrono em projetos monolíticos.

No próxima parte eu irei mostrar a implementação da solução.

Socorro! Como posso organizar os pacotes em Go?

Odilon Jonathan Kröger — Sun, 23 Feb 2020 20:34:56 +0000

Hoje vou falar a respeito de algo que tive certa dificuldade quando comecei a mexer com Go, que é a organização de pacotes.
Para falar a verdade, esse assunto não tem uma resposta rígida. Por quê? Simples, se você navegar pelo GitHub, encontrará projetos Go com diferentes tipos de estruturação. Por exemplo, a biblioteca kafka-go da Segment utiliza uma estrutura completamente diferente da biblioteca confluent-kafka-go da Confluent.

O que a documentação oficial tem a dizer sobre pacotes?

Programas Go são organizados em pacotes. Um pacote é uma coleção de arquivos fonte dentro de um mesmo diretório e que são compilados em conjunto. Funções, tipos, variáveis e constantes definidos em um arquivo fonte são visíveis para todos outros arquivos fonte dentro de um mesmo pacote. (Tradução minha).

Vou resumir aqui um pouco a documentação oficial, sem entrar nos detalhes do uso de módulos. O código é bastante similar ao da documentação oficial, com pequenas alterações e alguma tradução.

Como podemos ver, existe o diretório raiz chamado estrutura-de-pacotes com dois arquivos dentro, ola_mundo.go e ola_mundo_test.go.
Até aqui nenhum mistério.
Se observar na imagem, estamos no package main.

Mas considerando que eu vou criar um pacote novo, chamado strutil, todo arquivo que existir dentro dele, é visível para ele mesmo, mas não para o pacote raíz. Em outras palavras, para utilizar o código que está dentro do arquivo strutil.go em outros pacotes, no meu caso o pacote raíz, é necessário importar o pacote no arquivo ola_mundo.go e ola_mundo_test.go, conforme a imagem abaixo.

Ah, um detalhe! Para que a função consiga ser exportada para outros pacotes como no caso acima, o nome da função precisa iniciar com letra maiúscula. Se eu tivesse utilizado o nome reverter() em vez de Reverter(), não seria possível utilizar a função dentro do arquivo ola_mundo.go.

No mundo Go é uma boa prática comentar as funções que podem ser exportadas, pois gerando o godoc, o comentário aparece na documentação.
Algumas pessoas podem dizer que um bom código não precisa de comentários, mas quando o código será exposto por uma documentação godoc para alguém fazer uso da nossa API por exemplo, simples comentários podem ajudar muito nosso cliente.
O artigo Style guideline for Go packages inclusive fala que é um bom exercício ficar de olho no godoc no início do projeto, para ler e validar se realmente faz sentido a separação de pacotes que está sendo utilizada.

Com a leitura acima, podemos entender que um pacote fica contido dentro de um diretório e caso eu necessite utilizar em outros pacotes, preciso importar o pacote com o código desejado.

Como eu devo nomear os pacotes?

Existe uma publicação feita pelo Sameer Ajmani, com detalhes sobre essa questão. Mas existem alguns pontos básicos que vou explicar aqui.

O nome de um pacote deve ser curto e fácil de entender, mas sem comprometer a sua "intenção". Por exemplo, se eu quero escrever um pacote com utilidades relacionadas ao banco de dados, meu pacote poderia se chamar dbutil. Alguém pode pensar em chamar de util, mas como o nome é genérico demais, acaba prejudicando o entendimento do que tudo pode existir dentro do pacote.
O uso de sublinhado _, hífen - ou letras maiúsculas é desencorajado. Por exemplo, posso chamar um pacote de validacaologin, mas eu não deveria chama-lo de validacaoLogin, validacao-login ou ainda validacao_login. Porém, como eu disse no início da publicação, diferentes empresas podem seguir seus próprios padrões, como pode ser observado no repositório do kubernetes. Eu percebi que é difícil encontrar repositórios com pacotes cujo nome contém mais de uma palavra. Acredito ser boa abordagem se esforçar para utilizar apenas uma palavra como nome de pacote.
Abreviação é permitida, mas eu particularmente prefiro utiliza-la com cuidado. Exemplos de pacotes com nome abreviado: cmd, fmt, bufio.
Pacotes dentro de diretórios diferentes podem ter o mesmo nome. Por exemplo, posso ter cobranca/lancamento e também investimento/lancamento. Mas atenção! Se esses pacotes forem importados com frequência no mesmo lugar, o ideal é que um deles seja renomeado se possível, evitando problemas de entendimento.
Os diretórios dos pacotes podem ser criados da melhor forma que você encontrar para organizar o código. Você pode criar um diretório onde colocará um determinado domínio, ou ainda um diretório onde ficará concentrado todo código relacionado à algum tipo de computação específica.
A Jaana Dogan-Dalgaard chama atenção para algo que nós que viemos de outras linguagens acabamos estranhando. O nome do pacote deveria ser no singular e não no plural.

Afinal, existe algum padrão adotado?

Como mencionei acima, é possível encontrar diversos tipos de estruturas pelo GitHub. Mas existe um repositório com a sugestão de um padrão bem genérico que você pode ter como base, chamado golang-standards/project-layout.
Esse layout não é oficial e dependendo do tamanho do seu projeto, utiliza-lo seria complicar demais as coisas. Comece sempre da forma mais simples possível e vá adicionando novos pacotes conforme a necessidade for surgindo.

Alguns pacotes que são encontrados com frequência em projetos Go e que são explicados no README deste repositório. De forma resumida:

cmd é o pacote onde você concetra os seus arquivos main.go.
internal é o pacote onde fica o código que você não quer expor para fora da aplicação ou biblioteca. Conforme vimos acima, é possível ter vários pacotes internal dentro de diferentes diretórios.
pkg é o pacote onde fica o código que pretendo expor para ser utilizado em outras aplicações. O código exposto aqui será utilizado por outras pessoas, portanto escolha com cuidado o código que ficará dentro deste pacote. Você pode encontrar aqui uma lista de repositórios que usa este padrão.
vendor é o pacote onde você pode adicionar suas dependências.
api é onde você pode colocar schemas de JSON, Swagger, etc.
configs é onde ficam arquivos comuns de configuração. Observe que o nome é no plural!
scripts é utilizado para concentrar os scripts utilizados pela aplicação. Existe um ótimo exemplo no repositório do Terraform.
deployments é utilizado para os arquivos docker-compose, de Terraform, etc.

Atenção para quem vem do Java como eu vim! É muito comum que a gente pense logo em criar um pacote chamado src, porém essa prática é desencorajada, conforme a documentação do layout que citei acima.

You really don't want your Go code or Go projects to look like Java :-)

Como posso amadurecer a estrutura do meu projeto? Posso usar DDD?

Existe uma palestra, da Kat Zień que mostra como estruturar um projeto, utilizado apenas um diretório e ir evoluindo conforme a necessidade até atingir uma estrutura baseada em DDD.
Vou deixar aqui para a palestra.

Concluindo...

No fim das contas, como Go é uma linguagem nova e bastante versátil, por mais que existam alguns padrões surgindo, dependendo do projeto faz mais sentido seguir um ou outro caminho. Pra mim essa é uma característica que amo em Go, a flexibilidade.
Quando for estruturar o projeto, siga as boas práticas de comentar pacotes e funções que serão expostas, validando no godoc se faz sentido. Converse com sua equipe e com pessoas de outros lugares, como no Slack do Gophers para entender como outros projetos estão sendo feitos e quais prós e contras foram encontrados.
Considere também aquilo que fica mais confortável para sua equipe. De nada adianta criar uma guerra interna por causa da nomenclatura de pacotes e não ter o projeto entregue!

Por favor, não esqueça de cobrir o seu código com testes. ; )

Todos artigos que utilizei para estudar e criar esta publicação foram citados acima com seus respectivos links.

Foto de de capa feita por Aleksandar Pasaric no Pexels.

Seu primeiro serviço Go na Google Cloud App Engine.

Odilon Jonathan Kröger — Tue, 18 Feb 2020 21:33:45 +0000

Você já pensou em subir um serviço na Google Cloud (GCP) mas não sabe por onde começar?
Então acompanhe essa publicação onde mostrarei como subir um serviço simples utilizando a GCP App Engine. É mais fácil o que parece! :)
Ah, sabe aquelas playlists de LoFi Hip Hop (tem no Youtube, Spotify, etc.)? É uma boa pedida para acompanhar a leitura. ;D

Primeiros passos

Antes de mais nada, e necessário criar uma conta na Google Cloud.
Você irá receber um valor de bônus para testar a plataforma. Não precisa se preocupar, esse exemplo não chega nem perto de causar algum gasto para você. Mas é importante SEMPRE que for parar de realizar testes, parar os serviços para evitar surpresas no futuro.

Feita a conta, agora vamos acessar o console da plataforma.
No canto direito, é possível ir em preferências e escolher o idioma que você prefere, seja português, inglês ou outro.

Beleza, agora no canto esquerdo, é possível selecionar um projeto ou criar um novo. Clique ali nessa opção, pois iremos criar um projeto novo! :D

Nesta nova tela, clique em novo projeto.

A tela a seguir é bastante intuitiva, como podemos ver abaixo. Eu coloquei no nome do projeto como sendo primeiro-servico-gcp.

Pronto! Agora que já temos um projeto criado na GCP, podemos seguir para os próximos passos. ^^

Criando o primeiro serviço

Vamos abrir o Menu de navegação no canto esquerdo superior. Basta acessar o menu e em seguida App Engine -> Painel.
Se tudo der certo, provavelmente você verá a tela abaixo.

Basta clicar em Criar aplicativo. No próximo passo você deve escolher a partir de qual região você quer que seu código fique rodando. Pode manter como US Central. Cada região tem uma tabela de preços e também uma gama diferente de serviços disponíveis, mas para nosso exemplo isso não faz diferença, então não precisa se preocupar com isso.

Após selecionar a região, chegou o momento de escolher qual linguagem vamos utilizar. Para esse exemplo a linguagem escolhida foi Go ❤️.
Para o campo Environment, pode deixar Padrão.

Mais uma etapa concluída! Agora falta pouco.

Utilizando Cloud Shell

Uma das formas de criar a aplicação e realizar o deploy, é criando o código com seu editor favorito (Atom, VS Code, Sublime, etc.), baixando a SDK da GCP e realizando o deploy pelo seu terminal.
Outra forma, é utilizar o próprio terminal, chamado de Cloud Shell que a GCP nos oferece. Essa é a forma que vamos utilizar hoje.
Caso você já queira baixar a SDK para utilizar no futuro, basta acessar o Quickstart e selecionar de acordo com o seu sistema operacional. Se vocês quiserem, posso escrever uma publicação falando sobre isso! :D

Bom, vamos voltar ao assunto de hoje!
No canto superior direito, conseguimos acessar o Cloud Shell que utilizaremos. Pense no Cloud Shell como sendo um terminal rodando na plataforma da Google Cloud, que já tem a SDK deles instalada e mais algumas outras coisinhas, como o Vim e nano.

Clicando nesse botão acima, você irá acessar o Cloud Shell, que aparecerá na parte inferior da tela. Se for da sua preferência, você pode expandir o Cloud Shell para cima, de forma que ocupe praticamente o browser inteiro. Eu gosto de utilizar o terminal assim, então fica assim a tela:

Se você quiser, pode rodar o comando go version, que verá a versão atual instalada no seu ambiente.

Quero código! Cadê?

Lá vamos nós! Código!!!
Primeiro vamos acessar o diretório gopath.
cd gopath
Em seguida, vamos criar o diretório do nosso serviço. Você pode, por exemplo, executar o comando abaixo.
mkdir meu_primeiro_servico && cd $_
Esse comando cria o diretório meu_primeiro_servico e logo em seguida usa o comando $_ para entrar no diretório recém criado.

A primeira coisa que vamos criar, é um arquivo de configuração, necessário para rodar o serviço. Vamos utilizar o editor nano para codificar, ou se você preferir o Vim, também pode ser utilizado.
Execute o comando abaixo para criar o arquivo app.yaml.
nano app.yaml
Agora com o editor aberto no arquivo, basta adicionar a linha: runtime: go113. Como na imagem abaixo.

Agora basta pressionar Ctrl+o e em seguida Enter para salvar o arquivo. Para sair do nano, pressione Ctrl+x.

E finalmente, vamos o código Go. É possível criar um projeto modularizado, mas para esta publicação, vou seguir o caminho mais simples. Crie o arquivo com o comando abaixo.
nano main.go

Dentro do arquivo, vamos iniciar informando que é o pacote main. Em seguida adicionamos os imports necessários:

import (
    "fmt"
    "log"
    "net/http"
    "os"
)

Vamos também criar a função main, conforme abaixo.

func main() {
    http.HandleFunc("/", imprimirOlaMundo)
    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
        log.Printf("Utilizando porta padrão %s", port)
    }

    if err := http.ListenAndServe(":"+port, nil); err != nil {
        log.Fatal(err)
    }

}

Esta função está utilizando o client HTTP nativo da linguagem Go. Nele estamos monitorando chamadas para o caminho raiz /. Também tem uma condição, para caso não tenha sido setada uma porta no ambiente, seja utilizada a porta 8080. Mas você não precisa se preocupar com isso agora.
Também foram adicionados alguns logs, apenas para informar qual porta está sendo utilizada.

Repare que no mapeamento do caminho /, estamos chamando a função imprimirOlaMundo. Bora lá implementar essa função!

func imprimirOlaMundo(w http.ResponseWriter, r *http.Request) {
    fmt.Fprint(w, "Olá mundo! Eu consegui!!! :D")
}

Essa função recebe por parâmetro o http.ResponseWriter e o ponteiro *http.Request. É o padrão do client HTTP que mencionei acima.
Dentro da função basta imprimir a mensagem desejada, que no nosso caso é um Olá mundo.

Seu arquivo deve estar parecido como o da imagem abaixo.

Para salvar o arquivo, novamente utilize Ctrl+o e em seguida Enter. Para sair pressione Ctrl+x.

Chegou a hora do deploy!

Agora que temos os arquivos app.yaml e main.go criados, vamos realizar o deploy do serviço. É muito simples! Basta executar o comando abaixo.
gcloud app deploy
Ele vai pedir para continuar, basta responder com y.
Pronto! Seu serviço já está disponível na nuvem!!! \o/
Provavelmente no seu Cloud Shell, você deve estar vendo algo similar ao que existe na imagem abaixo.

Note que os logs inclusive nos informam o endereço onde o serviço está disponível. Basta copiar o endereço e abrir em uma nova aba do seu browser para testar o seu serviço.

Meus parabéns!!! Você acabou de disponibilizar seu primeiro serviço utilizando App Engine da GCP!

Ah, agora você já pode fechar o Cloud Shell. O botão de fechar fica na parte superior do Cloud Shell, no canto direito.

E agora?

Se você quiser ver dados sobre suas chamadas do serviço, pode ir no Menu de navegação no canto superior esquerdo, App Engine -> Painel. Nessa tela existem dados como quantas chamadas foram realizadas e até mesmo o custo.

Como eu mencionei no início da publicação, após realizarmos nossos testes, é sempre bom desligar os serviços, apenas para evitar ficar no esquecimento e daqui um ano receber uma conta indesejada. Acredite, já vi isso acontecer mais de uma vez com colegas de trabalho.
Para desligar o serviço, vamos acessar o Menu de navegação no canto superior esquerdo e ir em IAM e Admin -> Configurações.

Em seguida, com o projeto que acabos de criar selecionado, basta clicar em encerrar e na tela que for abrir, para permitir o encerramento do projeto, preencher o campo com o nome do projeto e confirmar.

Prontinho! Agora não precisa se preocupar em receber uma conta por causa de algum serviço que ficou de pé.

Curtiu?

E aí, curtiu a experiência de criar um serviço na nuvem utilizando GCP? Achou complicado, achou fácil? Deixe seu comentário abaixo. :)