Os anos de 2022 e 2023 foram de grande aprendizado para as empresas com a busca por eficiência como objetivo principal nas nossas tomadas de decisões e se falarmos da área de TI isso não foi diferente. As Clouds públicas surgiram com a promessa de excelência operacional e otimização de custos mas com o passar dos anos aprendemos que a segunda promessa, de otimização de custos, é bem mais difícil de ser evidenciada nos cases reais, principalmente se levarmos em consideração empresas latino americanas, que costuman ter uma moeda mais fraca em relação ao Dólar.

Nesses anos vimos o mercado de TI, na busca por otimização de custos, disposto a utilizar outras opções para organizar seus parques tecnológicos, como hospedagens tradicionais ou até mesmo datacentes próprios. Um caso interessante de empresa brasileira que ganhou repercussão no Twitter foi da woovi que partiu para um datacenter próprio com o uso do Proxmox de virtualizador para gestão dos servidores.

Em uma mudança de contexto grande como essa a primeira pergunta que fazemos é “Como vamos executar as mesmas aplicações que executávamos na nossa cloud de estimação? Principalmente os container?”. Finalmente chegamos à motivação desse post! O orquestrador queridinho do mercado hoje é o Kubernetes de fato o considero o mais completo e poderoso dentre as opções. No entanto, na minha opnião ele só é considerável quando utilizamos uma plataforma gerenciada como o EKS da AWS. Apesar de não me considerar um especialista em Kubernetes vou arriscar minha opnião em dizer que particularmente considero complexo fazer a gestão do cluster por conta propria, sem um EKS por exemplo.

Outra aspecto importante são as caracteristicas das empresas que precisam de recursos de Computação como um todo, em sua maioria são empresas sem um grande time de engenharia, sem um time de plataforma e muitas vezes estão utilizando recursos a Cloud da mesma forma que utilizariam uma hospedagem tradicional, abrindo mão também do que citei como sendo a primeira promessa da Cloud que é excelência operacional.

Uma opção que temos disponível Docker Swarm que muitas vezes conversa melhor com a necessidade da empresa em questão. A seguir motivadores para adoção do Swarm no seu devido contexto.

Docker Swarm

1. Simplicidade

Em poucos minutos é possível configurar um cluster com redundância que vai te entregar funcionalidades similares ao que teríamos com Kubernetes, Balanceamento automático, deploys “Blue Green” e até mesmo rollbacks em caso de falhas nos deploys. Tudo que você precisa para utilizar o swarm é o bom e velho Docker que todo mundo da área de TI já conhece ou pelo menos deveria.

2. Developer like

O desenvolvedor muito provavelmente utiliza o Docker no seu ambiente local e está muito familiarizado com os comandos do Docker. Nesse tipo de aplicação muitas vezes a pessoa responsável por configurar os servidores e fazer o deploy da aplicação também é o desenvolvedor, isso é mais um motivador para utilização do Swarm visto que o desenvolvedor vai se sentir “em casa” ao operar o ambiente de produção. Para notarmos a similaridade entre um arquivo do docker-compose e um arquivo yml do Swarm:

version: "3.9"
services:
  app:
    image: repository/audit:latest
    environment:
      - TZ=America/Sao_Paulo
    healthcheck:
       test: ["CMD", "curl", "-f", "http://localhost/api/healthcheck"]
       interval: 10s
       timeout: 10s
       retries: 3
       start_period: 30s
    ports:
      - "93:80"
    deploy:
      mode: global
      placement:
        constraints:
          - "node.role==worker"
          - "engine.labels.convenia.service.name==audit"
      update_config:
        parallelism: 0
        delay: 10s
        order: start-first
      restart_policy:
        condition: any
        max_attempts: 3
      resources:
        limits:
          memory: 1500M

Esse é um arquivo de configuração real de uma aplicação da Convenia, a parte diferente desse arquivo que não é possível utilizar sem o modo Swarm ligado são as seções de “healthcheck” e “deploy” que configuram respectivamente, um endpoint de healthcheck, que será responsável por “reviver” a aplicação em caso de falha, e instruções de qual servidor deve ser utilizado pela aplicação bem como limites de recursos.

3. Independente de qualquer Cloud.

A dependência necessário para utilização do Swarm é o docker, o que torna ele perfeito para executar container em ambiente “On Premise” e datacenters próprios. É importante citar isso porque muitas aplicações hoje em dia são executadas em provedores que não são as grandes clouds. Isso é mais comum em aplicações voltadas para a operação de marketing da empresa, como landing pages de produtos ou mesmo websites institucionais. Geralmente são desenvolvidos por uma empresa de marketing digital que costumem ter alguma revenda de hospedagem para atender à esses casos.

Virtual Private Server(VPS)

Um questionamento que pode aparecer é em relação a aplicações únicas monolíticas sendo executadas em uma única VPS(Virtual Private Server). Podemos questionar se não faria mais sentido executar a aplicação com um arquivo docker-compose mesmo ou mesmo executar um docker run manualmente, nesse caso ainda faz sentido a utilização do Swarm? Sim, ao ligar o modo Swarm não ganhamos apenas capacidade de gerenciar diversas aplicações em um cluster, ganhamos também funcionalidades como deploys “Blue Green”, Rollback de deploys em caso de falhar, health cheks entre outros, por isso concluímos que faz sentido a utilização em um servidor único, pelo menos seria a minha escolha pessoal.

Faz sentido utilizar o swarm dentro da AWS?

Falando especificamente da AWS, se estamos buscando simplicidade faria mais sentido a utilização do ECS com Fargate que é de utilização bem simples e trás uma integração fina com todos os outros serviços da AWS, ainda precisamos notar que o fargate é uma plataforma serverless e com ele você não precisa ter a preocupação de manter o sistema operacional de uma instancia.

Ao utilizar o ECS pagamos um pouco mais por “unidade de computação” do que quando utilizamos uma instancia por exemplo. Outro agravante é que o ECS é muito direcionado a integrar com ferramentas que também são da AWS e geralmente tem um custo. Falando especificamente de observabilidade, a maneira padrão de utilizar outras ferramentas de observabilidade é “plugar” essas no CloudWatch, que é a ferramenta de observabilidade da AWS, e geralmente uma observabilidade completa com alta resolução fica caro. Com isso posso concluir que existe um caso de uso valido do Swarm dentro da AWS. Eu mesmo já fiz esse setup mais de uma vez sempre com o viés de custo na cabeça, do contrario vá de ECS ou mesmo de EKS!

OBS: Não quero passar a ideia para o leitor de que não é possível utilizar outras ferramentas integradas diretamente com o ECS, sempre é possível mas muitas vezes a maneira que temos de fazer isso não nos deixa confortáveis. Tomando como exemplo uma ferramente de observabilidade como o Zabbix, seria possível colocar o agent do zabbix, que é responsável por coletar as metricas, dentro do container mas isso confundiria os limites de atuação entre o time de desenvolvimento e o time de infraestrutura então particularmente não fico a vontade com essa solução.

Quando não utilizar o Swarm?

1. Cases complexos

Nesse texto tentei defender a utilização do Swarm em aplicações simples, em aplicações complexas de microserviços com inúmeras necessidades as limitações do Swarm como orquestrador vão ser rapidamente notadas então não aconselho nesses casos. Vá de Kubernetes!

2. Grande necessidade de plataformização

Com um número grande de times, que é o que acontece em empresas como Nubank, MercadoLivre, Itaú, se torna muito importante que cada time tenha a autonomia necessária para operar a sua aplicação. É possível escrever um livro completo sobre times de plataforma mas de forma geral uma das responsabilidades gerais do time de plataforma é disponibilizar o poder de processamento do datacenter para que os times de desenvolvimento tenham autonomia para operar suas aplicações de forma segura. Nessa questão não podemos contar com o Swarm pois ele mesmo não tem funcionalidades voltadas para esse fim, diferente do Kubernetes que permite um permissionamento granular através de serviceaccounts e namespaces, ao invés de plataformizar a nível de cloud é possível plataformizar à nivel de orquestrador entregando apenas acesso à api do Kubernetes através do Kubectl.

3. Experiência to time de engenharia como um todo

Na minha experiência é essencial a escolha da ferramenta correta para determinado problema no entanto no caso de precisarmos escolher entre duas boas ferramentas devemos fazer a opção pela qual o time de engenharia tem mais familiaridade. Não é segredo que o Swarm caiu em desuso nos ultimos anos e a escolha dele para uma determinada stack pode até desmotivar o time responsável por aquela determinada stack além de arriscar o aparecimento de configurações “não convencionais” em função de falta de experiência. Se o time manja de Kubernetes então é kubernetes!

Docker swarm: Conclusão

Achei importante trazer essa reflexão sobre o swarm porque atualmente existe uma atenção compreensível muito voltada ao Kubernetes. Geralmente os maiores e mais relevantes case do mercado inundam a comunidade com informações sobre suas stacks, o mesmo não acontece com cases simples que na maioria esmagadora das vezes passam despercebidos. Nesse contexto é natural que haja um montante de informações muito relacionado aos big cases que precisam tirar proveito das mais profundas funcionalidades do Kubernetes.

Como conclusão gostaria de deixar o Docker em modo Swarm como uma opção válida para cases simples.

OBS: Muitas vezes já vi comentários induzindo ao pensamento de que o swarm foi descontinuado. Como muito explicado no texto todo ele não é mais a opção de orquestração padrão do mercado mas está com um desenvolvimento ativo e tem um roadmap de melhorias em andamento.

LEIA TAMBÉM:

• Angular: rodando a aplicação no Docker