DEV Community: Rui Valim

Kubernetes vs Docker Swarm: What are the practical differences?

Rui Valim — Tue, 04 Mar 2025 02:54:22 +0000

Leia este artigo em português

If you've worked with containers, you know that orchestration is essential for managing applications at scale. The two names that always come up in this discussion are Kubernetes and Docker Swarm. Both are powerful tools, but each has its own way of doing things. But what are the practical differences?

1. Docker Swarm has a quicker start

If you're just starting out in the world of container orchestration, Docker Swarm might be the more user-friendly choice. It now comes integrated with the Docker Engine upon installation, and with just a few commands, you can create a cluster and manage your services.

For example, to start a cluster in Docker Swarm, simply run:

docker swarm init

And to add a service:

docker service create --name meu_servico --replicas 3 minha_imagem

Pretty simple, right? On the other hand, Kubernetes has a steeper learning curve, requiring the use of multiple YAML files. The initial setup can be intimidating and complex, especially if you're setting up a cluster from scratch (and without using ArgoCD). Tools like Minikube or kubeadm can help, but Kubernetes still requires a deeper understanding of concepts like Pods, Services, Deployments, and Namespaces.

2. Kubernetes to infinity and beyond

When it comes to scalability, Kubernetes is king. It was designed to handle massive workloads and highly distributed environments. Companies like Google, Spotify, and Airbnb use Kubernetes to manage thousands of containers in production.

Kubernetes already has robust support for auto-scaling out of the box. Other features that make Kubernetes more scalable include its powerful self-healing system and intelligent scheduling, which handle many complex tasks for us with ease.

Docker Swarm is more limited in these areas. It scales well for smaller or medium-sized projects, but it may not be the best choice for environments that require more complex orchestration or involve thousands of nodes.

3. Their ecosystems

Being older and extremely popular, the Kubernetes ecosystem is vast and constantly growing. There are tools for almost everything: monitoring (Prometheus, Grafana), secret management (HashiCorp Vault), CI/CD (ArgoCD, Jenkins), and much more. Additionally, Kubernetes is widely supported by cloud services like Azure, AWS, and GCP.

Docker Swarm is also quite popular, but it hasn't been as widely adopted by the community as Kubernetes, and as a result, it has fewer resources and tools available. It works well for simpler use cases, but it doesn't offer the same flexibility and variety of tools as Kubernetes. If you need something beyond the basics, you might find yourself missing some features.

4. But Rui, which one do you recommend?

After analyzing these points, we can come to a simple conclusion: Do you need to deploy a few services without much complexity and with some speed? Use Docker Swarm. In this case, Kubernetes would be overkill for your project, both in terms of complexity and cost. But if your environment will run distributed across multiple servers, requires nearly 100% uptime, needs various observability tools, and involves complex communication between your microservices? Use Kubernetes. Your environment will be much more robust and prepared for such intensive workloads.

5. Let's get our hands dirty

A small example of using both tools:

Docker Swarm:

Start the cluster:

   docker swarm init

Create a service:

   docker service create --name web --replicas 3 -p 80:80 nginx

Done! Your nginx is running with 3 replicas.

Kubernetes:

Create a Deployment:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-deployment
   spec:
     selector:
       matchLabels:
         app: web
     template:
       metadata:
         labels:
           app: web
       spec:
         containers:
         - name: nginx
           image: nginx
           ports:
           - containerPort: 80

Create a Service to expose the Deployment:

   apiVersion: v1
   kind: Service
   metadata:
     name: web-service
   spec:
     selector:
       app: web
     ports:
       - protocol: TCP
         port: 80
         targetPort: 80
     type: LoadBalancer

Create an HPA to configure AutoScaling:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: memory
        target:
          averageUtilization: 80
          type: Utilization

Apply the YAML files:

   kubectl apply -f deployment.yaml
   kubectl apply -f service.yaml
   kubectl apply -f hpa.yaml

As you can see, Docker Swarm is more straightforward, while Kubernetes requires a bit more configuration.

Conclusion

Both Kubernetes and Docker Swarm have their strengths and weaknesses. The right choice depends on your project's needs and your familiarity with the tools.

Have you used any of these tools? What was your experience? Share in the comments!

This article was entirely written by me, utilising AI only for text correction.

Kubernetes vs Docker Swarm: Qual a diferença na prática?

Rui Valim — Tue, 04 Mar 2025 02:51:13 +0000

Read this article in English

Se você já trabalhou com contêineres, sabe que a orquestração é essencial para gerenciar aplicações em escala. Os dois nomes que sempre aparecem nessa discussão são Kubernetes e Docker Swarm. Ambas são ferramentas poderosas, mas cada uma tem seu jeitinho de fazer as coisas. Mas afinal, qual é a diferença na prática?

1. Docker Swarm tem um início mais rápido

Se você está começando no mundo da orquestração de contêineres, o Docker Swarm pode ser a escolha mais amigável. Hoje ele já vem integrado ao Docker Engine junto a instalação, e com apenas alguns comandos, você pode criar um cluster e gerenciar seus serviços.

Por exemplo, para iniciar um cluster no Docker Swarm, basta rodar:

docker swarm init

E para adicionar um serviço:

docker service create --name meu_servico --replicas 3 minha_imagem

Bem simples, não é mesmo? Já o Kubernetes tem uma curva de aprendizado mais complicada, fazendo uso de vários arquivos YAML. A configuração inicial pode ser intimidadora e complexa, especialmente se você estiver montando um cluster do zero (E sem usar ArgoCD). Ferramentas como Minikube ou kubeadm ajudam, mas ainda assim, Kubernetes exige um entendimento mais profundo de conceitos como Pods, Services, Deployments e Namespaces.

2. Kubernetes ao infinito e além

Quando o assunto é escalabilidade, o Kubernetes é rei do pedaço. Ele foi projetado para lidar com cargas de trabalho massicas e ambientes altamente distribuídos. Empresas como Google, Spotify e Airbnb usam Kubernetes para gerenciar milhares de contêineres em produção.

Kubernetes já tem um suporte bem robusto para auto-scaling out of the box, outros pontos que tornam o Kubernetes mais escalável são coisas com o sistema poderoso de self-healing e intelligent scheduling, que resolvem muitas coisas complexas para nós com a maior facilidade do mundo.

O Docker Swarm é mais limitado nesses pontos. Ele escala bem para projetos menores ou médios, mas pode não ser a melhor escolha para ambientes que exigem uma complexidade maior de orquestração ou que envolvem milhares de nós.

3. Seus ecossistemas

Por ser mais antigo e extremamente popular, o ecossistema do Kubernetes é vasto e está em constante crescimento. Existem ferramentas para praticamente tudo: monitoramento (Prometheus, Grafana), gerenciamento de secrets (HashiCorp Vault), CI/CD (ArgoCD, Jenkins) e muito mais. Além da presença do mesmo em vários serviços de nuvem como a Azure, AWS e GCP.

O Docker Swarm é bem popular também, mas ainda não é tão adotado pela comunidade como o Kubernetes é, por consequente acaba por ter menos recursos e ferramentas disponível para o uso. Ele funciona bem para casos de uso mais simples, mas não oferece a mesma flexibilidade e variedade de ferramentas que o Kubernetes. Se você precisar de algo além do básico, irá acabar sentindo falta de funcionalidades.

4. Mas Rui, qual tu recomenda?

Depois de analisar esses pontos podemos chegar em uma conclusão bem simples até: Você precisa subir poucos deployments, sem muita complexidade e com uma certa velocidade? Usa o Docker Swarm, nesse caso o Kubernetes vai ser um overkill no teu projeto, tanto em complexidade como no bolso. Mas agora, se seu ambiente ira rodar de forma distribuída em vários servidores, precisa garantir um nearly 100% UP Time, ter varias ferramentas de observabilidade e comunicação complexa entre seus micro-serviços? Usa o Kubernetes, seu ambiente estará bem mais robusto e preparado para esse workload intenso.

5. Vamos por a mão na massa

Um pequeno exemplo de uso das duas ferramentas:

Docker Swarm:

Inicie o cluster:

   docker swarm init

Crie um serviço:

   docker service create --name web --replicas 3 -p 80:80 nginx

Pronto! Seu nginx está rodando com 3 réplicas.

Kubernetes:

Crie um Deployment:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-deployment
   spec:
     selector:
       matchLabels:
         app: web
     template:
       metadata:
         labels:
           app: web
       spec:
         containers:
         - name: nginx
           image: nginx
           ports:
           - containerPort: 80

Crie um Service para expor o Deployment:

   apiVersion: v1
   kind: Service
   metadata:
     name: web-service
   spec:
     selector:
       app: web
     ports:
       - protocol: TCP
         port: 80
         targetPort: 80
     type: LoadBalancer

Crie um HPA para configurar o AutoScaling:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: memory
        target:
          averageUtilization: 80
          type: Utilization

Aplique os arquivos YAML:

   kubectl apply -f deployment.yaml
   kubectl apply -f service.yaml
   kubectl apply -f hpa.yaml

Como você pode ver, o Docker Swarm é mais direto, enquanto o Kubernetes exige um pouco mais de configuração.

Conclusão

Tanto Kubernetes quanto Docker Swarm têm seus pontos fortes e fracos. A escolha certa depende das necessidades do seu projeto e da sua familiaridade com as ferramentas.

E você, já usou alguma dessas ferramentas? Qual foi sua experiência? Compartilhe nos comentários!

Esse texto foi inteiramente escrito por mim, utilizando IA apenas como correção de texto.

5 tendências para ficarmos de olho em 2025 no mundo do DevOps

Rui Valim — Fri, 15 Nov 2024 14:50:54 +0000

Read this article in English

Nos últimos anos, práticas DevOps têm se tornado cada vez mais necessárias para os times de desenvolvimento, ajudando a agilizar a entrega, realizar testes automatizados, garantir segurança, entre outras tarefas essenciais. À medida que novas tecnologias e necessidades vão surgindo, o guarda-chuva do DevOps cresce e se adapta. Mas quais são as tendências para 2025 que devemos ficar de olho?

1. Automação + IA = <3

“Automação” é a primeira palavra que vem à mente quando pensamos em DevOps, e todos nós sabemos que 2024 (assim como 2023) foi o ano em que a IA tomou conta do Zeitgeist atual. Então, naturalmente, nós do DevOps vamos aproveitar essas novas ferramentas para melhorar ainda mais a qualidade do desenvolvimento.

Com a IA, atividades como monitoramento, detecção de anomalias e resposta a incidentes serão aprimoradas. O conceito de AIOps (Inteligência Artificial para Operações de TI) deve ganhar ainda mais força, integrando IA para otimizar o gerenciamento de infraestrutura e reduzir a necessidade de intervenção humana em tarefas repetitivas e complexas. Isso também vai aprimorar o monitoramento das aplicações e servidores, ajudando as equipes a identificar e solucionar problemas antes que impactem o usuário final.

2. DevOps 2: DevSecOps

Uma tendência que tenho visto é a evolução do termo DevOps. Estamos na era do DevSecOps (integração de segurança em cada etapa do processo DevOps), onde, acima da automação, está a segurança dos nossos ambientes virtuais. Mais do que uma prática recomendada, essa ideia se tornará essencial.

Em 2025, acredito que as ferramentas de DevOps deverão incluir verificações de segurança automatizadas e análise de vulnerabilidades em tempo real, tudo isso utilizando ferramentas baseadas em IA. Isso permitirá que as equipes identifiquem e neutralizem ameaças antes que se tornem um problema, fortalecendo a segurança em cada etapa do ciclo de desenvolvimento.

3. Infra as Code & GitOps: Um casamento perfeito

GitOps – a prática de usar repositórios Git para gerenciar configurações e operações de infraestrutura – vem ganhando popularidade e deve se tornar uma prática padrão. Utilizando ferramentas de Infrastructure as Code (IaC), o método GitOps oferece rastreabilidade, automação e consistência.

Com o GitOps, qualquer mudança na infraestrutura é controlada através de um repositório Git, permitindo controle de versão e auditoria em cada ajuste. Ferramentas como ArgoCD (ainda farei um post falando mais dessa belezura) e FluxCD estão na linha de frente dessa tendência, permitindo ambientes consistentes e robustos, onde rollback e histórico de mudanças são fáceis de gerenciar. Esse tipo de controle traz segurança e praticidade no gerenciamento da infraestrutura.

4. IoT: the new cool kid on the block

O uso de aparelhos inteligentes está em crescimento constante, o que traz a famosa IoT (Internet das Coisas) para o centro das atenções, e junto com ela, o Edge Computing (Computação de Borda), que se tornará cada vez mais comum na área de DevOps.

Diferentemente de um ambiente centralizado, o Edge Computing distribui o processamento e captura de dados em diversos pontos na borda da rede, reduzindo a latência e, por consequência, aumentando a eficiência. As equipes de DevOps devem estar preparadas para implementar essa arquitetura de maneira eficiente, suportando a crescente rede de dispositivos inteligentes e permitindo que o processamento aconteça mais perto do ponto de coleta de dados.

5. Sustentabilidade

Sustentabilidade deverá se tornar uma preocupação cada vez maior em todos os setores e indústrias, e acredito que DevOps terá um papel essencial nessa discussão também.

Precisaremos buscar maneiras mais eficientes de orquestrar nossos ambientes, sempre tendo em mente a utilização inteligente de recursos para diminuir o consumo energético de nossas aplicações. Criar uma rede mais verde e sustentável será parte integrante das práticas de DevOps do futuro, alinhando as operações de TI às necessidades do planeta.

Conclusão

O conceito de DevOps está em constante transformação, e a cada ano novas práticas, ferramentas e tecnologias surgem para redefinir essa área.

Em 2025, a integração da IA, o foco em segurança e sustentabilidade, e a evolução para uma observabilidade proativa estarão no centro das atenções para quem busca estar à frente e preparado para o futuro. Adaptar-se a essas novas exigências é crucial para atender tanto o usuário final quanto o mundo ao nosso redor, que necessita de práticas mais seguras e sustentáveis.

Esse texto foi inteiramente escrito por mim, utilizando IA apenas como correção de texto.

5 trends to watch in the World of DevOps in 2025

Rui Valim — Fri, 15 Nov 2024 14:45:32 +0000

Leia este artigo em Português

In recent years, DevOps practices have become increasingly essential for development teams, helping to speed up delivery, perform automated testing, ensure security, among other essential tasks. As new technologies and needs arise, the DevOps umbrella grows and adapts. But what are the trends for 2025 that we should keep an eye on?

1. Automation + AI = <3

“Automation” is the first word that comes to mind when we think of DevOps, and we all know that 2024 (just like 2023) was the year when AI took over the current Zeitgeist. So, naturally, we in DevOps will take advantage of these new tools to further improve the quality of development.

With AI, activities such as monitoring, anomaly detection, and incident response will be enhanced. The concept of AIOps (Artificial Intelligence for IT Operations) is expected to gain even more momentum, integrating AI to optimize infrastructure management and reduce the need for human intervention in repetitive and complex tasks. This will also improve the monitoring of applications and servers, helping teams identify and resolve issues before they impact the end user.

2. DevOps 2: DevSecOps

One trend I’ve seen is the evolution of the term DevOps. We are now in the era of DevSecOps (integration of security in every stage of the DevOps process), where, above automation, lies the security of our virtual environments. More than just a best practice, this concept will become essential.

In 2025, I believe DevOps tools should include automated security checks and real-time vulnerability analysis, all using AI-based tools. This will allow teams to identify and neutralize threats before they become a problem, strengthening security at every stage of the development cycle.

3. Infrastructure as Code & GitOps: A Perfect Match

GitOps – the practice of using Git repositories to manage infrastructure configurations and operations – has been gaining popularity and is expected to become a standard practice. By utilizing Infrastructure as Code (IaC) tools, the GitOps method offers traceability, automation, and consistency.

With GitOps, any infrastructure change is controlled through a Git repository, allowing for version control and auditing of each adjustment. Tools like ArgoCD (I'll still make a post about this beauty) and Flux are at the forefront of this trend, enabling consistent and robust environments, where rollbacks and change history are easy to manage. This type of control brings security and practicality to infrastructure management.

4. IoT: the new cool kid on the block

The use of smart devices is steadily increasing, bringing the famous IoT (Internet of Things) into the spotlight, along with Edge Computing, which will become increasingly common in the DevOps field.

Unlike a centralized environment, Edge Computing distributes processing and data collection across various points at the network’s edge, reducing latency and, consequently, increasing efficiency. DevOps teams must be prepared to implement this architecture efficiently, supporting the growing network of smart devices and allowing processing to occur closer to the data collection point.

5. Sustainability

Sustainability will become an ever-growing concern across all sectors and industries, and I believe DevOps will play an essential role in this discussion as well.

We will need to find more efficient ways to orchestrate our environments, always keeping in mind the intelligent use of resources to reduce the energy consumption of our applications. Creating a greener and more sustainable network will become an integral part of future DevOps practices, aligning IT operations with the planet’s needs.

Conclusion

The DevOps concept is constantly evolving, with new practices, tools, and technologies emerging every year to redefine this area.

In 2025, the integration of AI, focus on security and sustainability, and evolution towards proactive observability will be at the forefront for those looking to stay ahead and prepared for the future. Adapting to these new demands is crucial to serve both the end user and the world around us, which requires safer and more sustainable practices.

This article was entirely written by me, utilising AI only for text correction.

Como o CI/CD pode transformar o ciclo de vida de desenvolvimento

Rui Valim — Sun, 27 Oct 2024 20:51:39 +0000

Ou "Como o CI/CD pode deixar a vida da sua equipe de desenvolvimento um pouco mais tranquila"

A automação tem se tornado uma parte essencial no desenvolvimento de software moderno. Com a crescente adoção de práticas ágeis e a necessidade de entregas rápidas e frequentes, implementar uma pipeline de CI/CD (Continuous Integration e Continuous Deployment) é um passo essencial para garantir eficiência e qualidade.

Mas o que exatamente isso significa? Como integrar uma pipeline de CI/CD pode transformar o ciclo de vida de desenvolvimento do seu projeto?

Como os antigos faziam (sofriam)?

Já participei de projetos em que o processo de deploy era quase tão complicado quanto o desenvolvimento. Com frequência, quando terminávamos de desenvolver uma nova funcionalidade começávamos toda a nova de entrega para o ambiente de produção, mas realizar tal entrega era um desafio que por muitas vezes se tornou um desafio maior do que o esperado e demorado, algo particularmente problemático quando tínhamos que subir um hotfix.

O maior problema é que, sem automação, tudo dependia de processos manuais que eram sujeitos a erros humanos. Um ambiente configurado incorretamente, um passo esquecido durante o deploy ou até mesmo diferenças entre os ambientes de desenvolvimento e de produção eram causas de falhas. Isso não só atrasa o time de desenvolvimento, mas também impacta negativamente os clientes.

Foi aí que comecei a perceber o impacto que uma pipeline automatizada de CI/CD poderia ter em projetos.

Mas o que é CI/CD?

Antes de entrar em detalhes, vamos definir rapidamente o que é CI/CD.

Continuous Integration (CI): É o processo onde cada mudança no código é automaticamente integrada e testada, garantindo que o novo código funcione com o existente. Ao fazer commits frequentes e rodar testes automatizados, os times conseguem detectar problemas mais cedo.
Continuous Deployment (CD): Após o código passar pelos testes de CI, ele é automaticamente disponibilizado em um ambiente de produção, sem a necessidade de intervenções manuais. Em alguns casos, se usa o Continuous Delivery, onde o código é preparado para deploy, mas uma intervenção humana ainda é necessária para fazer a entrega.

Em essência, CI/CD significa que os processos de build, teste e deploy são automatizados, resultando em um ciclo de vida de desenvolvimento muito mais eficiente.

Como isso melhora o ciclo de desenvolvimento das aplicações

Agora que entendemos o que é CI/CD, vamos falar sobre os benefícios reais que a implementação dessa prática traz ao ciclo de vida de desenvolvimento de software.

1. Feedback Rápido

Uma das maiores vantagens da automação de CI/CD é a rapidez no feedback. Cada mudança no código é imediatamente testada, e qualquer problema pode ser identificado em questão de minutos. Isso significa que, ao invés de passar dias ou semanas tentando encontrar a origem de um bug, os desenvolvedores recebem informações rápidas sobre o que está quebrando.

2. Redução de Erros Manuais

A automação elimina a necessidade de deploys manuais, que são notoriamente propensos a erros. Já viu um desenvolvedor rodar um script de deploy em produção e acabar derrubando o serviço por causa de um parâmetro errado? Com uma pipeline de CI/CD bem configurada, isso se torna coisa do passado.

3. Consistência Entre Ambientes

Um problema comum em muitos projetos é a inconsistência entre ambientes de desenvolvimento, teste e produção. “Funciona na minha máquina” se torna um mantra temido. Com a automação, é possível garantir que o código seja testado e rodado em ambientes idênticos, minimizando surpresas na hora do deploy.

4. Entrega Contínua e Ágil

Ao automatizar o processo de integração e deploy, a equipe pode entregar novas funcionalidades de forma mais ágil e frequente. Isso é especialmente importante em um ambiente competitivo, onde o time-to-market pode ser decisivo. CI/CD permite que empresas liberem atualizações pequenas e incrementais, sem precisar esperar meses para grandes releases.

5. Foco no que Importa: Inovação

Com uma pipeline automatizada, os desenvolvedores podem focar no que realmente importa: criar novas funcionalidades e melhorar o produto. A automação reduz a carga de tarefas operacionais e permite que a equipe de engenharia dedique mais tempo à inovação.

Adorei… Mas e agora?

Começar com CI/CD pode parecer intimidador, mas na verdade, você pode iniciar aos poucos. Algumas ferramentas populares para construir pipelines de CI/CD incluem Jenkins, GitLab CI, CircleCI, e GitHub Actions. A escolha vai depender das suas necessidades e do stack que você utiliza.

Para quem está começando, sugiro focar na automação dos testes unitários primeiro. Uma vez que isso estiver rodando bem, você pode começar a integrar o deploy automático em ambientes de qa e/ou staging e, eventualmente, em produção.

Conclusão

Implementar CI/CD pode parecer um grande passo, mas os benefícios são claros. Uma pipeline bem construída pode reduzir erros, acelerar o tempo de entrega e garantir que seu código esteja sempre pronto para produção. Com o tempo, essa prática se torna uma parte essencial, e viciante, do ciclo de vida de desenvolvimento de software.