DEV Community: Yros Aguiar

Como minizamos timeouts intermitentes em transações ISO-8583 com ajustes em TCP e buffers no Python

Yros Aguiar — Wed, 04 Jun 2025 12:36:14 +0000

Durante a operação de um sistema de pagamentos de uma fintech brasileira baseado em transações via protocolo ISO8583 (Maquininhas e Transações fisicas), nossa equipe enfrentou um desafio crítico: timeouts intermitentes na comunicação com o adquirente, afetando a confiabilidade e latência das autorizações.

Após uma análise detalhada e aplicação de técnicas de debugging em redes e sockets, conseguimos minimizar o problema com ajustes precisos nas configurações de TCP e buffers do socket Python.

📍 O cenário

Nosso sistema, escrito em Python, se conectava diretamente ao adquirente utilizando uma implementação customizada do protocolo ISO 8583 sobre TCP/IP. Em determinados horários, notamos que as requisições apresentavam timeouts aparentemente aleatórios, mesmo quando o servidor remoto (adquirente) estava saudável e o payload estava correto.

Esses timeouts, além de prejudicar a taxa de sucesso das transações, também aumentavam a complexidade operacional e exigiam reprocessamentos.

O que é o protocolo ISO 8583?
ISO 8583 é um padrão internacional que define como sistemas de transações financeiras eletrônicas (como cartões de crédito, débito e terminais POS/ATM) devem se comunicar.

Criado originalmente para o setor bancário, ele especifica a estrutura das mensagens, os campos de dados, os tipos de transações (como venda, cancelamento, consulta de saldo) e como essas mensagens devem ser codificadas, transmitidas e interpretadas entre sistemas como adquirentes, emissores, gateways e redes de pagamento.

Principais características:
Usa o modelo cliente-servidor sobre TCP/IP ou outras camadas.

Cada mensagem contém um MTI (Message Type Identifier) que define seu propósito (ex: requisição de autorização).

Os dados são organizados em campos numerados chamados Data Elements (DE).

Pode ter bitmaps para indicar quais campos estão presentes.

É um protocolo binário ou ASCII estruturado, dependendo da implementação.

Exemplo de mensagens:
0100 – Requisição de autorização.

0110 – Resposta à autorização.

0200 – Transação financeira (ex: compra).

0420 – Estorno.

🔍 Como debugamos

Nosso processo de investigação seguiu as seguintes etapas:

Habilitamos logs de baixo nível no cliente ISO 8583, incluindo logs de envio, recebimento e tempo de resposta.
Utilizamos ferramentas como tcpdump, wireshark e netstat para observar o comportamento da conexão TCP.
Monitoramos filas de sistema, utilização de file descriptors e buffers de socket no sistema operacional.
Correlacionamos os horários de falha com picos de volume e throughput de rede.

Com isso, identificamos que:

O buffer de envio e recepção do socket estava sendo saturado em alguns momentos.
A latência aumentava ligeiramente antes dos timeouts.
Havia retransmissões TCP e atrasos no ACK durante a transmissão do pacote ISO.

🛠️ A solução: ajustes nos sockets

Realizamos os seguintes ajustes no cliente ISO 8583 Python:

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Aumentamos os buffers de envio e recepção
sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 65536)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 65536)

# Definimos TCP_NODELAY para evitar delays por Nagle
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

# Reduzimos o timeout para reações rápidas
sock.settimeout(5)  # Ajustável conforme SLA do adquirente

# Conectamos e seguimos com a transmissão
sock.connect((host, port))

🔗 Links úteis sobre ISO 8583:
Wikipedia (Inglês)
https://en.wikipedia.org/wiki/ISO_8583

ISO 8583 Message Structure
https://www.ibm.com/docs/en/devops-test-workbench/11.0.2?topic=schemas-iso-8583-overview-structure

ISO 8583 Emulator Server
https://github.com/yrosaguiar/iso8583-server

Repositório Python ISO8583 (PyISO8583)
https://pypi.org/project/pyiso8583/

Doc estrutura ISO8583
https://pyiso8583.readthedocs.io/en/latest/

🧠 De 3 meses para 20 minutos: GitOps multi-cluster com Oracle APEX e Kubernetes na Oracle Cloud

Yros Aguiar — Wed, 04 Jun 2025 12:08:44 +0000

Introdução

Um processo manual e demorado era o principal gargalo de um cliente que operava exclusivamente na Oracle Cloud. Para cada novo cliente final, era necessário provisionar um ambiente completo de forma manual: redes, bancos Oracle e MySQL, aplicação Oracle APEX e APIs PHP e sem migrations. Com uma equipe enxuta, esse processo levava até 3 meses, sendo mais de 30 dias apenas com infraestrutura. Ele não tinha github e as aplicações eram instaladas a partir de um ZIP (isso mesmo) um arquivo ZIP em cada servidor toda vez que criava um ambiente novo, fazia tudo na mão.

Neste artigo, conto como implementamos uma arquitetura GitOps multi-cluster com Terraform, Kubernetes, ArgoCD e Oracle Operator, que reduziu o provisionamento de novos ambientes para 20 minutos, mantendo segurança, versionamento, escalabilidade e total automação.

Cenário anterior

Infraestrutura provisionada manualmente.
Sem uso de Git, CI/CD ou pipelines.
Para cada cliente final:
- Instância separada de banco Oracle (com APEX)
- APIs PHP rodando em máquinas separadas
- Banco MySQL separado
Processos repetitivos, com alto risco de erro humano e sem rastreabilidade.
Time pequeno sobrecarregado, gerando atrasos e impossibilidade de escalar.

Arquitetura atual

🔷 Cluster HUB (Infraestrutura Central)

ArgoCD (para App of Apps)
Github for SCM and Workflows
Terraform para criação da infra OCI.
Grafana e Prometheus (observabilidade centralizada)
Bitwarden Vault (gestão de segredos)
Pritunl VPN (acesso seguro)
Ingress NGINX
Cert Manager
External DNS
External Secrets

🟢 Clusters UAT e PRD (Workloads por cliente)

Aplicações por cliente isoladas via namespace e/ou NodeGroups
Operadores e serviços compartilhados:
- Ingress NGINX
- Cert Manager
- Oracle Operator
- KEDA
- External DNS
- Prometheus
Cada namespace contém:
- Aplicação Oracle APEX
- APIs PHP
- MySQL (quando necessário)
- Configurações personalizadas via Kustomize
- Regras de RBAC, quotas e secrets isolados

Blueprint GitOps

GitHub é o source of truth.
Cada cliente é provisionado em um namespace dedicado no cluster UAT e PRD.
O ArgoCD, rodando no HUB, aplica os manifestos em cada cluster com base em blueprints.
O uso de Kustomize permite modificar variáveis específicas por cliente.
Todo provisionamento é feito via GitOps, com histórico e rollback garantidos.

Como funciona a entrega de um novo cliente?

Um novo cliente é fechado pelo time comercial.
Um novo namespace é criado via commit em repositório Git.
O ArgoCD sincroniza os blueprints no cluster correto (UAT ou PRD).
Oracle Operator cria o banco Oracle e configura o Oracle APEX automaticamente.
APIs PHP e banco MySQL são criados com Helm/Kustomize.
DNS, certificados SSL, segredos e regras de RBAC são aplicados.
Em 20 minutos o ambiente está pronto e funcionando.

Resultados

Métrica	Antes	Depois
Tempo de provisionamento	Até 3 meses	20 minutos
Escalabilidade	Limitada	Automática
Segurança e rastreabilidade	Inexistente	Total com GitOps
Erros operacionais	Frequentes	Quase nulos
Visibilidade e monitoramento	Manual	Grafana/Prometheus/KEDA
Custo humano por entrega	Elevado	Quase nulo

🎯 Vantagens
Reutilização de padrões: Um único modelo serve como base para múltiplos clientes.

Velocidade e previsibilidade: Tudo padronizado, validado e rastreável via Git.

Escalabilidade: Provisionar centenas de ambientes é questão de scripts e commits.

Segurança: RBAC, quotas e secrets configurados automaticamente.

Lições aprendidas

Kubernetes pode funcionar muito bem com Oracle APEX com o uso correto de operadores.
GitOps traz velocidade, previsibilidade e confiança no processo.
Multi-cluster com Hub-and-Spoke ajuda a separar responsabilidades e reduzir risco.
Ter um cluster HUB para ferramentas e clusters para workloads melhora a gestão de recursos.

Próximos passos

CI para APIs PHP com testes e deploys contínuos.
Portal de autoatendimento para novos ambientes.
Monitoramento por tenant com dashboards dinâmicos.

🔍 Diagrama da Arquitetura

GitOps Approach com Blueprints

📘 O que são Blueprints em GitOps?
No seu projeto, Blueprints são modelos declarativos versionados que definem a estrutura de provisionamento de um cliente dentro do Kubernetes. Eles são armazenados em Git e utilizados como fonte de verdade pelo ArgoCD para criar namespaces, bancos de dados, aplicações e serviços — tudo sob demanda, de forma padronizada.

🧱 O papel dos Blueprints na arquitetura
Cada Blueprint inclui:
Estrutura de namespace (com labels, quotas, RBAC)

Manifests para aplicações (Oracle APEX, APIs PHP)

Definição de PVCs e limites de recursos

Configuração de bancos de dados via Oracle Operator e MySQL

Secrets e ConfigMaps necessários

Integração com Cert Manager, External DNS, KEDA etc.

Exemplo de organização:

clientes/
├── cliente-xpto/
│ ├── namespace.yaml
│ ├── apex-db.yaml
│ ├── php-api-deployment.yaml
│ ├── mysql-db.yaml
│ ├── ingress.yaml
│ ├── kustomization.yaml

🔁 Fluxo GitOps com Blueprints

Time comercial fecha com um novo cliente.
Time de operações clona o blueprint base e adapta o nome do cliente.
Um commit é feito no Git com o novo blueprint sob gitops/clientes/xpto/uat ou gitops/clientes/xpto/prd (esses são os overlays) que apontam para uma base com os objetos do k8s gitops/clientes/base/

O ArgoCD (que vive no cluster HUB) detecta o novo caminho e aplica o conteúdo no cluster correto (UAT ou PRD).

Em poucos minutos, o namespace, banco, aplicação e todos os recursos estão provisionados.

🎯 Vantagens
Reutilização de padrões: Um único modelo serve como base para múltiplos clientes.

Velocidade e previsibilidade: Tudo padronizado, validado e rastreável via Git.

Escalabilidade: Provisionar centenas de ambientes é questão de scripts e commits.

Segurança: RBAC, quotas e secrets configurados automaticamente.

Recursos

Oracle DB Operator

O OracleDB Operator é um operador Kubernetes de código aberto criado para facilitar o provisionamento, gerenciamento e operação de bancos de dados Oracle dentro de clusters Kubernetes, seguindo os padrões do modelo Kubernetes Operator Pattern.

Ele abstrai a complexidade da instalação e administração do Oracle Database, permitindo que você crie e gerencie instâncias de banco de dados Oracle diretamente a partir de manifests YAML versionados, como parte de um fluxo GitOps com ferramentas como ArgoCD e Kustomize.

https://github.com/oracle/oracle-database-operator
https://blogs.oracle.com/coretec/post/oracle-database-now-containernative

✅ Principais Funcionalidades
Provisionamento automático de Oracle Database:

Versões suportadas: Oracle 12c, 19c, 21c (depende da imagem base utilizada).

Instalação com persistência via PVC.

Pode ser configurado com parâmetros de memória, CPU e configurações avançadas.

Criação de usuários e schemas

Possibilidade de definir usuários padrão, senhas e permissões no próprio YAML.

Suporte a Oracle APEX

Automatiza a instalação e configuração do APEX como aplicação web embutida.

Backup e restore

O operator inclue suporte para agendar backups automatizados via cron.

Monitoramento e liveness/readiness probes

Exposição de métricas via Prometheus

🧩 Recursos Customizados (CRDs)
O Operator cria alguns CRDs (Custom Resource Definitions) como por exemplo:

apiVersion: db.oracle.com/v1alpha1
kind: OracleDatabase
metadata:
  name: cliente-x-db
spec:
  edition: "enterprise"
  version: "19c"
  apex:
    enabled: true
    adminPassword: "SenhaSuperSegura"
  storage:
    size: 50Gi
  resources:
    requests:
      memory: "4Gi"
      cpu: "2"
    limits:
      memory: "8Gi"
      cpu: "4"

Esse YAML cria uma nova instância de Oracle DB com APEX habilitado, configurado automaticamente.

🔄 GitOps e ArgoCD
Integrar o OracleDB Operator com ArgoCD permite que:

A criação de novos bancos seja desencadeada por um commit Git.

A configuração dos bancos, APEX, usuários e permissões fiquem versionadas.

A infraestrutura de dados se beneficie de auditoria, rollback, CI/CD e reprodutibilidade.

🚀 Benefícios para Arquiteturas Multi-Tenant
Em arquiteturas como a sua (multi-tenant com namespaces por cliente), o OracleDB Operator permite:

Criar uma instância de banco para cada cliente isoladamente.

Controlar o ciclo de vida de cada banco via YAML.

Compartilhar o operador no cluster, mantendo instâncias separadas por namespace.

Reduzir drasticamente o tempo de entrega e o risco de erros humanos.

Blueprints Structure

gitops
├── applicationsets
│   ├── infrastructure
│   │   └── helm-addons
│   │       ├── airflow
│   │       ├── keda
│   │       ├── prometheus
│   │       ├── uptimerobot
│   │       └── vaultwarden
│   │           └── repo
│   ├── template
│   └── workloads
├── bootstrap
│   └── projects
└── kustomize
    ├── infrastructure
    │   ├── cert-manager
    │   │   ├── hub
    │   │   ├── prd
    │   │   └── uat
    │   ├── cluster-addons
    │   │   ├── prd
    │   │   └── uat
    │   ├── external-dns
    │   │   ├── hub
    │   │   ├── prd
    │   │   └── uat
    │   ├── grafana
    │   ├── imc
    │   ├── ingress-nginx
    │   ├── operators
    │   │   ├── mysql
    │   │   └── oracledb
    │   ├── prometheus
    │   └── rabbitmq
    └── workloads
        ├── base
        │   ├── apex
        │   ├── api-1
        │   ├── api-2
        │   └── xpto-scripts
        │       └── backup-cli
        └── environments
            ├── demo
            │   ├── prd
            │   └── uat
            ├── client-1
            │   ├── prd
            │   └── uat
            ├── client-2
            │   ├── prd
            │   └── uat
            ├── client-3
            │   ├── prd
            │   └── uat
            └── test
                └── uat

Customer environment Application Set Example

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: demo
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
    - list:
        elements:
          - cluster: xpto-uat
            url: "https://168.77.99.106:6443"
            values:
              project: xpto-uat
              environment: uat

          - cluster: xpto-prd
            url: "https://144.23.199.200:6443"
            values:
              project: xpto-prd
              environment: prd

  template:
    metadata:
      name: "xpto-demo-{{.values.environment}}"
    spec:
      project: "{{.values.project}}"
      sources:
        - path: gitops/kustomize/workloads/environments/demo/{{.values.environment}}
          repoURL: git@github.com:xpto/devops.git
          targetRevision: HEAD
      destination:
        server: "{{.url}}"
        namespace: demo
      syncPolicy:
        retry:
          backoff:
            duration: 5s
            factor: 2
            maxDuration: 3m0s
          limit: 2
        syncOptions:
          - ApplyOutOfSyncOnly=false
          - CreateNamespace=true

ArgoCD Prints

Se você curtiu esse conteúdo ou está pensando em migrar workloads para Kubernetes, me chama no LinkedIn 👋

Como migrei Azure Functions e Container Apps para Kubernetes (GKE) usando GitOps

Yros Aguiar — Wed, 04 Jun 2025 10:43:34 +0000

Recentemente, conduzi um projeto de migração que uniu eficiência, modernização e redução total de custos. A missão era clara: mover todas as Azure Functions e Container Apps de um cliente para Kubernetes, sem reescrever código, e usando apenas recursos gratuitos disponíveis via créditos GCP.

🎯 O desafio

O cliente rodava sua stack em Azure Functions Premium + Azure Container Apps. O custo médio mensal era de £6.000 e os créditos da Azure estavam acabando.

A stack era baseada em eventos de Storage Blob que disparavam o processamento de arquivos. Nossa meta:

Reduzir drasticamente os custos;
Manter o código das functions intacto;
Tornar a arquitetura multi-cloud e agnóstica;
Utilizar créditos disponíveis no GCP;
Manter a experiência serverless com escalabilidade automática.

🛠️ Solução

Optei por mover toda a stack para Kubernetes, utilizando o KEDA como motor de escalabilidade baseada em eventos — que, aliás, é usado internamente pela própria Microsoft para escalar Azure Functions.

Toda a infraestrutura foi provisionada com Terraform, e a estratégia de implantação seguiu uma abordagem GitOps baseada em Blueprints, com ArgoCD estruturado como App of Apps.

✅ Etapas do projeto

Containerização das Azure Functions Apenas criei Dockerfiles compatíveis com o runtime de Azure Functions. ➕ Nenhuma modificação no código-fonte.

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS installer-env

COPY . /src/dotnet-function-app
RUN cd /src/dotnet-function-app && \
mkdir -p /home/site/wwwroot && \
dotnet publish *.csproj --output /home/site/wwwroot

FROM mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true

ENV TZ=Europe/London
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

EXPOSE 80 10000 10001 10002

COPY --from=installer-env /home/site/wwwroot /home/site/wwwroot

Provisionamento

Terraform: Toda a parte de recursos de cloud — K8s clusters, VPC, Nat Gateways, etc, helm do ArgoCD e External secrets.

GitOps com ArgoCD App of Apps: External DNS, Metrics Server, Ingress nginx, ArgoCD, Prometheus, Grafana, Github Actions Controller, KEDA, Metabase, Cert Manager, Reloader, SonarQube

O Bootstrap do ambiente

No Ambiente HUB
O Terraform cria o rede, cluster, e componentes de Rede, instala o ArgoCD e external secrets,e cria a app of apps no ArgoCD, após isso todo o restante é configurado

Nos Ambientes de Workloads
O Terraform cria os componentes de Rede e o Cluster, quando é realizado o Sync no App of Apps do Workload, toda a estrutura é configurada no cluster.

Se utilizar Crossplane compositions ao inves de terraform o Bootstrap fica no GitOps e ArgoCD pra tudo dos workloads, inclusive os resources de cloud.

Passos

Ambiente inicial na Azure (AKS)

Para validação inicial:
- Subi cluster AKS;
- Implantei ArgoCD e criei um approach App of Apps;
- Configurei pipelines CI/CD no github
- Instalei e configure o KEDA integrado com Azure Storage Queue;
- Usei blueprint GitOps para controlar todos os manifests.
Migração para GCP (GKE)

Após validação, repliquei a infraestrutura no GKE, utilizando os créditos do GCP.

✅ Resultado: stack completa rodando sem custo mensal.
Triggers com KEDA

O KEDA escutava o Azure Blob Storage diretamente, usando ScaledObject com blobTrigger.
Manutenção do Azure Storage (baixo custo)

O Blob Storage permaneceu na Azure por questões de integração legada, mas gerando menos de £10 por mês.
GitOps com ArgoCD + App of Apps

A estrutura baseada em blueprints versionados em Git permitiu replicar ambientes de forma segura, auditável e reproduzível.
Escalabilidade inteligente

A combinação KEDA + GKE Cluster Autoscaler garantiu escalabilidade automática e econômica, mantendo o comportamento serverless.

Gitops Approach

Blueprints:

O que são GitOps Blueprints (e como usei em um projeto real)

Se você já trabalhou com GitOps, deve ter percebido que chega um momento em que começa a repetir estruturas e configurações entre ambientes (dev, prd, stg...).

É aí que entram os GitOps Blueprints: modelos reutilizáveis de infraestrutura e aplicações, versionados em Git, que te ajudam a padronizar e automatizar o provisionamento completo de clusters Kubernetes (ou similares).

🔧 O que é um GitOps Blueprint?

Um GitOps Blueprint é como um template de infraestrutura + aplicações que pode ser reaplicado em diferentes ambientes ou clusters com poucas mudanças.

Basicamente, você define:

Componentes base (KEDA, Prometheus, Grafana, etc);
Configurações parametrizáveis via Helm ou Kustomize;
Estrutura de ambientes (ex: DEV, PRD, QA);
E deixa tudo versionado no Git.

A automação fica por conta de ferramentas como:

ArgoCD
FluxCD
Terraform (opcional, para provisionamento de infra)

💡 Quando usar?

Você deve usar GitOps Blueprints quando:

✅ Precisa criar múltiplos ambientes com a mesma stack;

✅ Quer aplicar boas práticas de IaC e GitOps;

✅ Busca portabilidade entre clouds (Azure, GCP, AWS);

✅ Precisa versionar tudo que está sendo implantado no cluster;

✅ Trabalha com multi-tenant ou multi-cluster setups.

Utilizei applicationsets do ArgoCD podendo usar kustomize, helm ou manifestos raw na mesma aplicação argo, utilizando o approach multiple sources

Main App of Apps

Infrastructure app of Apps

Workloads App of Apps

📁 Estrutura de repositório GitOps Blueprints

terraform
 ├──hub (Terraform code para o HUB)
 └──workloads (Terraform code para os Workloads usando TF Workspaces)
gitops
 ├── applicationsets (argo applicationsets for infrastructure)
 │   ├── infrastructure-azure (applicationsets for Azure)
 │   ├── infrastructure-gcp (applicationsets for GCP)
 │   └── workloads (argo applicationsets for workloads)
 ├── helm-chart (generic template helm chart)
 │   └── templates
 │       └── tests
 └── kustomize
     └── infrastructure
         ├── cert-manager (cert manager overlays)
         │   |── gcp
         │   |   ├── dev
         │   |   ├── hub
         │   |   └── prd
         │   └── azure
         │       ├── dev
         │       ├── hub
         │       └── prd
         ├── external-dns (external DNS overlays)
         │   ├── azure
         │   │   ├── dev
         │   │   ├── hub
         │   │   └── prd
         │   └── gcp
         │       ├── dev
         │       ├── hub
         │       └── prd
         ├── ingress-nginx (Ingress nginx overlays)
         ├── metabase (metabase objects)
         ├── metrics-server (Metrics Server overlays)

ArgoCD applicationset usado para instalar o KEDA em multiplos ambientes

O uso do applicationset ajuda a manter a aplicação instalada em multiplos ambientes e cluster, um applicationset pode ser usado para instalar uma ou várias aplicações em multiplas clouds e workloads

https://argo-cd.readthedocs.io/en/latest/user-guide/application-set/

Scaled Object

https://keda.sh/docs/2.15/reference/scaledobject-spec/

💰 Resultado final

Aspecto	Antes (Azure)	Depois (Kubernetes + GKE)
Custo mensal	£6.000	$0 (via créditos GCP)
Reescrita de código	Sim	Não foi necessário
Escalabilidade	Azure Premium Plans	KEDA + GKE Autoscaler
Orquestração	N/A	GitOps com ArgoCD + Blueprints
Provisionamento	Manual/Portal	100% Terraform
Dependência de cloud	Total	Ambiente agnóstico
Estimativa pós-créditos	—	~$2.000/mês

🧠 Lições aprendidas

O KEDA é confiável, maduro e realmente pronto para produção.
Arquitetura cloud-native com GitOps e Terraform permite portabilidade real entre clouds.
Kubernetes não precisa ser caro: com estratégia e créditos certos, ele pode custar zero.
Muitos sistemas legados podem ser migrados sem reescrita de código — só mudando a forma como são executados.
Blueprints + ArgoCD oferecem governança e replicabilidade de ambientes em escala.
Se Usarmos um Crossplane o blueprints fica totalmente resiliente e o provisionamento fica muito rápido, ficando uma estrutura totalmente GitOps

Se você curtiu esse conteúdo ou está pensando em migrar workloads para Kubernetes, me chama no LinkedIn 👋