Deixe-me começar do início. Em minha função como engenheiro de nuvem AWS em um de meus clientes anteriores, foi usada uma arquitetura orientada a eventos, onde terceiros enviavam constantemente muitos eventos para nosso ambiente AWS por meio do EventBridge. Para cada terceiro, fornecemos um barramento de eventos com várias regras do EventBridge.

O desafio aqui foi acompanhar a estrutura do evento – como ele foi organizado. Os eventos eram atualizados com frequência, gerando muitas reuniões para esclarecer as coisas.

No final de 2019, grande parte do nosso problema foi resolvida graças ao EventBridge Schema Discovery. Ao habilitar isso nos barramentos de eventos, os esquemas foram gerados automaticamente com base nos eventos recebidos. Isso nos permitiu gerar vinculações de código a partir desses esquemas, o que foi de grande ajuda em nosso ambiente orientado a objetos.

Abaixo você pode ver um exemplo muito básico de evento de terceiros.

{
  "version": "0",
  "id": "ef21d5fc-a5ba-e2c6-fc4b-a8807455c64d",
  "detail-type": "orderType",
  "source": "com.company.A",
  "account": "xxx",
  "time": "2024-08-22T08:04:26Z",
  "region": "eu-west-1",
  "resources": [],
  "detail": {
    "orderId": 123456789,
    "customer": {
      "customerId": "C001",
      "name": "John Doe"
    },
    "orderDate": "2024-08-22"
  }
}

AWS descobriu um esquema para estes tipos de eventos:

Usando o AWS Toolkit for Visual Studio Code, poderíamos facilmente representar nossos eventos como objetos fortemente tipados em nosso código.

Abaixo está um exemplo muito básico de como usamos as vinculações de código.

Saída:

123456789
C001

Isso melhorou nossa forma de trabalhar, mas ainda encontramos um problema. De tempos em tempos, terceiros adicionavam novos atributos aos seus eventos. O EventBridge descobriria essas mudanças, mas os desenvolvedores muitas vezes se esqueciam de atualizar as ligações de código para o novo esquema. Embora nossa implementação fosse robusta o suficiente para evitar quebras quando novos atributos eram adicionados, ela resultou em novos dados que não estávamos utilizando. Tivemos que contar com os desenvolvedores para se lembrarem de atualizar suas vinculações de código ocasionalmente, e não havia um processo claro para gerenciar isso.

Às vezes, uma vinculação de código não era atualizada há meses e, ocasionalmente, dois desenvolvedores o atualizavam simultaneamente, causando conflitos ou trabalho duplicado.

Para lidar melhor com isso, decidimos criar uma solução que cria automaticamente um ticket Jira sempre que um terceiro atualiza seu evento e um novo esquema é descoberto.

A solução está disponível no CloudFormation no meu GitHub. Verifique o README.

A primeira etapa foi criar uma regra EventBridge em nosso barramento padrão que seria acionada sempre que um novo esquema ou atualização de versão do esquema fosse descoberto. Esse evento foi então enviado para uma fila SQS para servir como entrada para um EventBridge Pipe. Aqui, poderíamos adicionar filtragem adicional (opcional neste exemplo) e enriquecer nosso evento usando uma função Lambda.

Para enriquecimento, usamos oscribe_schema usando boto3.

data = event[0]["input"]["detail"]

try:
    response = client.describe_schema(
        RegistryName=data["RegistryName"],
        SchemaName=data["SchemaName"],
        SchemaVersion=data["Version"],
    )
except ClientError as e:
    raise e

return_data = {
    "SchemaName": response["SchemaName"],
    "SchemaVersion": response["SchemaVersion"],
    "SchemaArn": response["SchemaArn"],
    "Content": json.loads(response["Content"]),
}

Depois de enriquecer nossos dados, os enviamos para um fluxo de trabalho Step Function. Esse fluxo de trabalho, por sua vez, acionou a automação SSM AWS-CreateJiraIssue fornecida pela AWS, que criou automaticamente um ticket Jira.

O ticket incluía detalhes como o nome do esquema, a nova versão do esquema e o ARN do esquema. (Conteúdo adicional do evento também pode ser adicionado, se necessário.)

 ----------------        --------        -------------------------        ----------------        ------------------------- 
| EventBridge    | ---> | SQS    | ---> | EventBridge Pipe        | ---> | Step Function  | ---> | SSM Automation Document |
| Rule           |      |        |      | (Filtering & Enrichment)|      |                |      |                         |
 ----------------        --------        -------------------------        ----------------        ------------------------- 

Vamos demonstrar esta solução. Aqui você vê um evento atualizado, baseado no original. O status do atributo é novo.

{
  "version": "0",
  "id": "dffbd38b-9258-d028-21f3-da0ba3c9e314",
  "detail-type": "orderType",
  "source": "com.company.A",
  "account": "xxx",
  "time": "2024-08-22T08:04:26Z",
  "region": "eu-west-1",
  "resources": [],
  "detail": {
    "orderId": 123456789,
    "status": "Completed",
    "customer": {
      "customerId": "C001",
      "name": "John Doe"
    },
    "orderDate": "2024-08-22"
  }
}

Um novo esquema será descoberto. Isso acionará toda a solução. Após o Lambda enriquecer nosso evento, esse evento atualizado será usado como entrada para nossa Step Function.

O evento de entrada de nossa Step Function é enriquecido e se parece com isto.

[
  {
    "statusCode": 200,
    "data": {
      "SchemaName": "com.company.A@OrderType",
      "SchemaVersion": "2",
      "SchemaArn": "arn:aws:schemas:eu-west-1:xxx:schema/discovered-schemas/com.company.A@OrderType",
      "Content": {
        "openapi": "3.0.0",
        "info": {
          "version": "1.0.0",
          "title": "OrderType"
        },
        "paths": {},
        "components": {
          "schemas": {
            "AWSEvent": {
              "type": "object",
              "required": [
                "detail-type",
                "resources",
                "detail",
                "id",
                "source",
                "time",
                "region",
                "version",
                "account"
              ],
              "x-amazon-events-detail-type": "orderType",
              "x-amazon-events-source": "com.company.A",
              "properties": {
                "detail": {
                  "$ref": "#/components/schemas/OrderType"
                },
                "account": {
                  "type": "string"
                },
                "detail-type": {
                  "type": "string"
                },
                "id": {
                  "type": "string"
                },
                "region": {
                  "type": "string"
                },
                "resources": {
                  "type": "array",
                  "items": {
                    "type": "object"
                  }
                },
                "source": {
                  "type": "string"
                },
                "time": {
                  "type": "string",
                  "format": "date-time"
                },
                "version": {
                  "type": "string"
                }
              }
            },
            "OrderType": {
              "type": "object",
              "required": [
                "orderId",
                "orderDate",
                "customer",
                "status"
              ],
              "properties": {
                "customer": {
                  "$ref": "#/components/schemas/Customer"
                },
                "orderDate": {
                  "type": "string",
                  "format": "date"
                },
                "orderId": {
                  "type": "number"
                },
                "status": {
                  "type": "string"
                }
              }
            },
            "Customer": {
              "type": "object",
              "required": [
                "customerId",
                "name"
              ],
              "properties": {
                "customerId": {
                  "type": "string"
                },
                "name": {
                  "type": "string"
                }
              }
            }
          }
        }
      }
    }
  }
]

O fluxo de trabalho da Step Function, por sua vez, acionará a automação do SSM e criará um Jira Ticket.

Por conveniência, mantive o conteúdo do ticket breve. Porém, como o Conteúdo também é enviado como entrada para a Step Function, ele também poderá ser incluído no ticket. Dessa forma, você pode mencionar diretamente os novos atributos ou alterações no esquema em seu ticket.

Esta solução também será acionada quando um evento completamente novo for descoberto, pois criará uma versão 1 do novo evento, fazendo com que a regra EventBridge seja acionada.

Desta forma, fomos informados sobre atualizações e pudemos agendá-las em nosso sprint. Isto leva a uma aceleração do nosso ciclo de desenvolvimento.

Estou ciente de que este é um caso bastante específico, mas soluções semelhantes podem ser criadas configurando regras do EventBridge para acionar os eventos desejados e, em seguida, usando enriquecimento e Step Functions em combinação com SSM para criar automações adicionais.