Platform engineering é a resposta estrutural para esse problema. Não porque seja uma moda, mas porque a única forma de escalar IA em engenharia com governança, consistência e medição de impacto é por meio de uma plataforma interna madura. O DORA Report 2025 é explícito: há uma correlação direta entre a qualidade de uma plataforma interna e a capacidade de uma organização de extrair valor real da IA.

Esse artigo trata de como fazer isso funcionar na prática.

Por que platform engineering e GenAI precisam um do outro

A relação é bidirecional e isso importa.

Por um lado, GenAI acelera as práticas de engenharia existentes. Agentes embebidos em pipelines melhoram a cobertura de testes, identificam vulnerabilidades de segurança antes do deploy e reduzem o trabalho repetitivo que consome o tempo dos engenheiros sênior. Por outro lado, a plataforma é o que torna isso possível em escala: provendo os recursos de computação certos (GPUs, TPUs, clusters especializados), além de guardrails, observabilidade e governança.

Sem plataforma, o que se tem é shadow AI: cada time escolhendo seu próprio LLM, construindo seus próprios conectores, reinventando as mesmas regras de governança. Os custos ficam opacos, os riscos de compliance se multiplicam e a organização acumula dívida técnica em IA tão rapidamente quanto a de infraestrutura nos anos 2010.

Gartner previa que 80% das organizações de engenharia de software teriam times dedicados a platform engineering até 2026. O dado real chegou antes: quase 90% das empresas já têm plataformas internas, superando a previsão de um ano adiantado. A aceleração foi diretamente impulsionada pela necessidade de governar a adoção de IA.

Os três enablers técnicos que tornaram isso possível

RAG: ancorando agentes no conhecimento interno

Retrieval-Augmented Generation resolve o problema fundamental dos LLMs em contexto organizacional: modelos treinados em dados genéricos não conhecem seus runbooks, seu histórico de PRs, suas políticas de segurança. RAG permite que agentes recuperem esse conhecimento em tempo de inferência, sem necessidade de re-treinar modelos.

Em 2025–2026, RAG evoluiu para arquiteturas modulares e agênticas, sistemas iterativos e auto-corretivos que decidem dinamicamente quando e como recuperar informação externa. A diferença entre um agente que alucina contexto genérico e um que propõe um fix correto para um pipeline falho está quase sempre na qualidade do RAG por trás.

MCP: o protocolo que virou infraestrutura

O Model Context Protocol, lançado pela Anthropic em novembro de 2024, padronizou a comunicação entre agentes de IA e ferramentas externas. Antes do MCP, cada integração era um conector custom: o clássico problema N×M de integração que a indústria já resolveu uma vez com APIs e teve que resolver de novo para os agentes.

Em menos de um ano, o MCP acumulou mais de 97 milhões de downloads mensais de SDK, mais de 10 mil servidores ativos e adoção formal de OpenAI, Google DeepMind e Microsoft. Em dezembro de 2025, a Anthropic doou o protocolo à Agentic AI Foundation, sob a Linux Foundation, o sinal mais claro possível de que MCP é infraestrutura crítica neutra de vendor, não um diferencial competitivo.

Para equipes de platform engineering, o MCP resolve algo concreto: quando um agente dispara um job de CI, o MCP carrega o metadado e o contexto necessários para que a plataforma entenda a intenção. É a camada de comunicação padronizada entre o mundo dos agentes e o das plataformas.

Agentes nos pipelines de CI/CD

A infusão de GenAI diretamente nos pipelines cria um nível de inteligência que vai além da automação tradicional. Pipelines que detectam anomalias em logs por meio de similaridade de embeddings, propõem fixes contextualizados e disparam rollbacks condicionados à aprovação humana não são ficção científica: são casos de uso em produção hoje. O resultado direto é a redução do MTTR e a prevenção da recorrência de falhas que antes dependiam de post-mortem humano.

O que realmente separa adoção de experimento

1. Integrar ao fluxo, não adicionar por cima

O erro mais comum é tratar GenAI como uma camada nova: um dashboard separado, uma ferramenta à parte, um bot que o desenvolvedor precisa lembrar de consultar. Isso não funciona. O DORA 2025 confirma que a user-centricity amplifica o impacto positivo da IA: fazer com que o desenvolvedor precise mudar seu fluxo de trabalho para usar IA é a receita para baixa adoção.

GenAI precisa estar onde o desenvolvedor já está: extensões no dev portal (Backstage, Cortex), plugins de IDE, respostas automáticas no CLI. A plataforma deve prover funcionalidades de IA baseadas no contexto do papel e do momento, como a geração de pipeline de CI para quem está escrevendo uma feature e a sugestão de right-sizing para quem está provisionando infraestrutura, sem que ninguém precise declarar explicitamente o que quer.

Dados do State of AI in Platform Engineering 2025 mostram que 75% dos profissionais de plataforma usam IA diariamente na geração de código. Mas uso individual e adoção estratégica são coisas diferentes: apenas 48% conseguiram integrar IA com sucesso nos processos de seus times.

2. Agentes que propõem, não que decidem

A tentação de substituir o julgamento humano pela automação é real, especialmente quando os primeiros resultados parecem bons. Resistir a ela não é conservadorismo, e sim pragmatismo. O DORA 2025 aponta que 30% dos desenvolvedores ainda relatam pouca ou nenhuma confiança no código gerado por IA. Forçar autonomia antes de construir confiança produz o resultado oposto.

O design correto é: agentes propõem ações, humanos aprovam. Com o tempo, à medida que os padrões de qualidade são estabelecidos e a confiança aumenta, o escopo de autonomia pode ampliar-se. Desenvolvedores precisam poder sobrescrever, re-treinar e re-contextualizar agentes sem atrito. Isso não é uma limitação de design, é parte da arquitetura de valor.

3. Golden paths como primeiro-cidadão para IA

Golden paths (os workflows padronizados e suportados que definem a forma recomendada de fazer as coisas) tornam-se ainda mais críticos no contexto de IA, pois estabelecem os limites seguros dentro dos quais agentes podem operar. Sem golden paths, agentes introduzem variabilidade em lugares onde você precisa de consistência.

A abordagem correta é tratar templates de agentes como você trata templates de microsserviço: pré-configurados com capacidades de produção desde o primeiro dia, integração com LLM providers, gerenciamento de quota, governança de acesso e observabilidade padrão. Não deixar cada time reinventar isso é exatamente o problema para o qual o platform engineering existe.

4. Observabilidade LLM-specific não é opcional

O stack de observabilidade existente não é suficiente para os agentes em produção. Além das métricas tradicionais de infraestrutura, você precisa de:

• Token trace logs: rastreabilidade de cada ação do agente, o que foi invocado, com qual contexto
• Prompt drift detection: identificar quando o comportamento do agente deriva do esperado ao longo do tempo, um problema que se manifesta lentamente e é invisível sem instrumentação específica
• Relevância de scoring de respostas RAG: ter um RAG não garante respostas relevantes. Medir continuamente a qualidade do que é recuperado é o que separa RAG útil de RAG que confunde
• Audit trails explícitos: não só para compliance, mas para debug e para construir confiança com os times que usam os agentes
• Versionamento de agentes e prompts: o mesmo rigor que você aplica a código se aplica aqui

O Datadog State of AI Engineering 2026 documenta que a próxima onda de vantagem competitiva pertence a organizações que conseguem madurar agentes em sistemas de produção disciplinados: observáveis, governáveis, resilientes e com visibilidade de custo.

5. Governança de IA como código de plataforma, não como política de compliance

A regulação está chegando. Na Europa, obrigações para provedores de IA de propósito geral já são aplicáveis desde agosto de 2025, com requisitos para sistemas de alto risco entrando em vigor em agosto de 2026, e multas de até €35 milhões ou 7% do faturamento global. Organizações que tentam atender a esses requisitos na camada de aplicação, onde cada time constrói seus próprios mecanismos de logging, transparência e audit trails, vão encontrar compliance caro, inconsistente e frágil.

A plataforma é o lugar certo para embutir mecanismos de compliance: autenticação e autorização na camada de acesso ao modelo, logging padronizado para audit trails, avaliação de bias integrada nos pipelines de desenvolvimento, documentação obrigatória antes de um serviço de IA ir ao ar. Gartner encontrou que organizações que implantam plataformas de governança de IA têm 3,4 vezes mais probabilidade de alcançar alta efetividade na governança de IA do que as que gerenciam ad hoc.

6. Medir impacto de negócio, não só métricas técnicas

A precisão e a latência são métricas necessárias, mas não suficientes. O que sustenta o investimento em AI em plataforma é conectar ações de desenvolvimento a resultados de negócio.

Isso significa rastrear melhorias no MTTR, na redução da change failure rate e no flow index dos times. Significa conseguir dizer “meu agente economizou duas horas de escrita de configuração por semana em seis times, o que equivale a X em valor de engenharia”. Significa conectar commits e releases de features a dashboards de OKRs.

A evolução das métricas DORA vai nessa direção: de métricas de throughput puras para um framework que conecta o desempenho de entrega a resultados de produto e ao bem-estar dos times. Plataformas que expõem essa visibilidade para os próprios desenvolvedores criam um loop de engajamento que se auto-sustenta.

7. Platform as a product não é opcional

A última chave que fecha tudo. Times de plataforma que não tratam a plataforma como um produto, com pesquisa de usuário, documentação, customer success e melhoria contínua: ainda não estão fazendo platform engineering. Estão operando a infraestrutura.

O mesmo princípio se aplica à IA: não coloque funcionalidades de IA nos seus usuários sem saber o que eles querem. A easyJet, por exemplo, só observou aceleração na adoção de ferramentas de IA quando as lideranças a tornaram uma expectativa verbalizada, não um mandato. Segurança e outras travas devem ser obrigatórias. Tudo o que serve ao desenvolvedor interno deve ser opcional e suficientemente bom para que ninguém queira sair do golden path.

A arquitetura que suporta tudo isso

Uma plataforma que implementa esses princípios se organiza em quatro zonas funcionais:

Zona de Input: onde reside o intent do desenvolvedor: source code, issue tracking, CLI, dev portal. É aqui que ficam os prompt engines e os agentes locais: co-pilots, PR assistants, pipeline generators.

Zona de Plataforma: serviços core: CI/CD, infraestrutura-as-code, golden paths, definindo workflows padronizados para integração segura de IA.

Zona de IA: a infraestrutura agêntica, múltiplos agentes LLM, MCP para comunicação padronizada entre agentes e plataforma, RAG para contexto a partir de bases de conhecimento internas. É aqui que fica o AI gateway, que roteia chamadas entre os providers, gerencia quotas e faz failover.

Zona de Dados: telemetria centralizada via OpenTelemetry, feedback loops (histórico de prompts, performance metadata, feedback de desenvolvedor), e a camada de business intelligence que conecta a atividade da plataforma a OKRs. Sem essa zona, você está operando às cegas.

O que o dado mais duro de 2025 diz

O DORA Report 2025 traz uma constatação que vale guardar: a adoção de IA tem relação positiva com o throughput de entrega de software e com a performance do produto — uma melhoria em relação a 2024, quando a relação era negativa. Mas ainda há uma relação negativa com a estabilidade de entrega.

A interpretação correta não é a de que a IA é problemática. É que a IA acelera o desenvolvimento e essa aceleração expõe fragilidades downstream. Sem sistemas de controle robustos (testes automatizados maduros, batch sizes pequenos, loops de feedback rápido), o aumento do volume de mudanças gera instabilidade. A plataforma interna é exatamente o ambiente em que esses sistemas de controle vivem.

Platform engineering e GenAI não são tendências paralelas. É um único movimento. As organizações que entenderem isso primeiro vão ter uma vantagem difícil de replicar.

Referências

DORA RESEARCH TEAM. Accelerate State of DevOps Report 2024. Google Cloud, 2024. Disponível em: https://dora.dev/research/2024/dora-report/. Acesso em: 23 abr. 2026.

GOOGLE CLOUD. Announcing the 2025 DORA Report. Google Cloud Blog, set. 2025. Disponível em: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report. Acesso em: 23 abr. 2026.

PLATFORM ENGINEERING. State of AI in Platform Engineering 2025. PlatformEngineering.org, 2025. Disponível em: https://platformengineering.org/reports/state-of-ai-in-platform-engineering-2025. Acesso em: 23 abr. 2026.

PLATFORM ENGINEERING. A framework for integrating AI into platform engineering. PlatformEngineering.org, jan. 2026. Disponível em: https://platformengineering.org/blog/a-framework-for-integrating-ai-into-platform-engineering. Acesso em: 23 abr. 2026.

PLATFORM ENGINEERING. Platform engineering in 2025: What changed, AI, and the future of platforms. PlatformEngineering.org, dez. 2025. Disponível em: https://platformengineering.org/events/platform-engineering-in-2025-what-changed-ai-and-the-future-of-platforms-2025-12-09. Acesso em: 23 abr. 2026.

MIA PLATFORM. Top 5 Predictions For Platform Engineering In 2026. Mia-Platform Blog, dez. 2025. Disponível em: https://mia-platform.eu/blog/top-5-predictions-platform-engineering-2026/. Acesso em: 23 abr. 2026.

LINUX FOUNDATION. Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF). San Francisco, dez. 2025. Disponível em: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation. Acesso em: 23 abr. 2026.

MODEL CONTEXT PROTOCOL BLOG. MCP joins the Agentic AI Foundation. Anthropic, dez. 2025. Disponível em: https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/. Acesso em: 23 abr. 2026.

THOUGHTWORKS. The Model Context Protocol’s impact on 2025. Thoughtworks United States, dez. 2025. Disponível em: https://www.thoughtworks.com/en-us/insights/blog/generative-ai/model-context-protocol-mcp-impact-2025. Acesso em: 23 abr. 2026.

LEADDEV. AI made platform engineering strategic again. LeadDev, abr. 2026. Disponível em: https://leaddev.com/technical-direction/ai-made-platform-engineering-strategic-again. Acesso em: 23 abr. 2026.

THENEWSTACK. In 2026, AI Is Merging With Platform Engineering. Are You Ready?. The New Stack, jan. 2026. Disponível em: https://thenewstack.io/in-2026-ai-is-merging-with-platform-engineering-are-you-ready/. Acesso em: 23 abr. 2026.

DATADOG. State of AI Engineering. Datadog, 2026. Disponível em: https://www.datadoghq.com/state-of-ai-engineering/. Acesso em: 23 abr. 2026.

EHTESHAM, Abul et al. Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG. arXiv, jan. 2025. Disponível em: https://arxiv.org/abs/2501.09136. Acesso em: 23 abr. 2026.

AMAZON WEB SERVICES. What is RAG? Retrieval-Augmented Generation AI Explained. AWS, 2025. Disponível em: https://aws.amazon.com/what-is/retrieval-augmented-generation/. Acesso em: 23 abr. 2026.

FAROS AI. DORA Report 2025 Key Takeaways: AI Impact on Dev Metrics. Faros AI Blog, set. 2025. Disponível em: https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025. Acesso em: 23 abr. 2026.

Mercado Libre, Latin America’s largest digital ecosystem, runs one of the most demanding and scalable infrastructures in the Southern Hemisphere.

Our operation at scale

• 35,000 active microservices
• Over 20,000 technology professionals
• Approximately 30,000 daily deployments
• Around 120,000 pull requests per day
• Traffic peaks of 15 million requests per second

In this fast-paced environment, efficient workload orchestration across multiple cloud providers is crucial. Kubernetes has become our standard for container management and is the foundation of our multi-cloud strategy, powering our internal compute engine. You can see more details here.

This article explores how we’ve used Karpenter and GitOps to evolve our ecosystem, achieving automated provisioning, declarative governance, and large-scale cloud-native operations.

The challenge of scale

With tens of thousands of microservices, ticket-driven workflows and manual changes quickly became bottlenecks, slowing delivery and increasing operational risk. Even with the evolution of Infrastructure as Code (IaC), new challenges emerged:

• Explosive diversity of templates and pipelines
• State drift and lack of standardization
• Overloaded Platform/DevOps teams with repetitive requests

In response, we evolved toward declarative, auditable, and fully automated practices, guided by GitOps, continuous automation, and internal infrastructure abstractions.

Karpenter: What it is and why it changed the game

Karpenter is an open-source, Kubernetes-native provisioning engine designed to deliver automatic scalability, cost optimization, and high flexibility in managing a cluster’s data plane (compute nodes).

How it works at a high level

• Monitors the Kubernetes scheduler for pending pods caused by insufficient compute resources.
• Analyzes each workload’s requirements (CPU, memory, architecture, affinities, labels, tolerations, and more).
• Provisions, scales, or terminates nodes on demand, automatically selecting the ideal instance type, profile (Spot or On-Demand), and architecture.
• Performs advanced bin packing, consolidating multiple pods on fewer nodes to maximize efficiency and minimize costs.

In short, Karpenter eliminates overprovisioning and aligns infrastructure capacity to business demand within seconds, enabling elastic and resilient clusters.

With Karpenter, Mercado Libre now operates with:

• Just-in-time provisioning: Nodes are created or terminated exactly when workloads require them.
• Intelligent instance decisions: Node types and configurations are dynamically chosen to balance cost and SLA requirements.
• Fully automated cluster lifecycle: Clusters can be created, scaled, and adjusted in minutes, even under peak load.
• Sustainable growth: Supporting thousands of workloads across dozens of clusters that rapidly adapt to changes and seasonal demand.

In practice, the average pod scheduling time (from Pending to Running) dropped to around 50 seconds, even under high concurrency. This improvement represents a significant leap in agility and operational efficiency.

How on-demand provisioning works

Karpenter replaces the traditional approaches based on Auto Scaling Groups or Cluster Autoscaler, bringing greater intelligence and automation to the node lifecycle.

The diagram below illustrates the end-to-end flow from resource request to optimized pod execution, showing how Karpenter continuously observes, analyzes, and provisions compute capacity on demand.

The provisioning cycle happens through several continuous and coordinated stages:

1. Demand detection by the scheduler

When a new pod is created and no available nodes meet its requirements, the Kubernetes scheduler detects its pending state and triggers the provisioning cycle.

2. Constraint evaluation (scheduling simulation)

Karpenter simulates the scheduling process by analyzing key constraints, such as:

• nodeAffinity: Preferences and restrictions for node location and type.
• topologySpreadConstraints: Rules that ensure high availability by distributing pods across zones or failure domains to avoid overconcentration.
• tolerations: Criteria allowing pods to run on nodes with specific taints within certain node pools.

This simulation ensures that defined policies and SLAs are respected while preparing the ground for efficient resource allocation.

3. Allocation strategy selection

Based on workload requirements and organizational policies, Karpenter determines:

• The best NodePool for demand, considering architecture, compute profile (general-purpose, compute-intensive, ML, or GPU), or logical domain.
• Capacity type, deciding between Spot, On-Demand, or Preemptible instances to balance cost and service criticality.
• Availability Zone (AZ), selecting the most appropriate zone to optimize availability and resource efficiency.

4. Intelligent batching

To prevent inefficient bursts of node creation during high-demand spikes, Karpenter batches multiple pod requests within a short window (typically 1–10 seconds). This consolidation maximizes resource utilization and avoids waste.

5. Instance provisioning and launch

Karpenter then proceeds with actual provisioning by:

• Requesting the ideal instance type and size from the cloud provider, considering dozens of parameters like machine family, generation, capacity, and pricing.
• Creating the instance in the most suitable availability zone and automatically joining it to the cluster.

6. Optimized workload execution

Once the instance is ready, the pod is scheduled and begins execution on infrastructure tailored to its specific requirements. The result is a highly efficient and resilient operation, with Karpenter continuously consolidating pods, eliminating underutilized nodes, and dynamically adjusting compute resources in real-time.

Allocation strategies and operational governance

Operating Kubernetes clusters at scale requires balancing isolation, flexibility, and cost efficiency. At Mercado Libre, we achieve this balance using NodePools and NodeClasses.

A NodePool is a group of nodes with similar configurations, organizing and scheduling workloads according to several key criteria:

• Service type: User-facing applications, platform services, batch jobs, or machine learning workloads.
• Capacity model: A division between On-Demand and Spot instances, each offering different levels of resilience and cost optimization.
• Architecture and hardware: AMD64, ARM64, or GPU-based nodes, chosen based on the workload profile.
• Compute profile: Distinction between general-purpose nodes and CPU-intensive workloads.

These NodePools follow self-descriptive naming conventions, making automation simpler and aligning engineering teams more straightforward. Real-world examples include:
user_application-spot-amd64-cpu_optimized
platform_application-ondemand-arm64-general_computing

Intelligent Spot usage and virtual domains

To balance cost and stability, we apply Spot ratio policies based on workload type:

• Critical workloads: Use up to 10% Spot capacity.
• Medium-priority workloads: Use up to 70% Spot.
• Test and staging environments: Can run on 100% Spot instances to maximize savings.

Instead of relying on fixed affinities, we use declarative labels that define virtual domains. This allows the Kubernetes scheduler to distribute pods evenly across availability zones. Constraints like topologySpreadConstraints and maxSkew ensure high availability and prevent workload concentration within a single failure domain.

Below is a simplified example of a Pod configuration:

In this example, the workload can be scheduled on Spot nodes, requires the ARM64 architecture, and is distributed evenly across multiple availability zones to prevent concentration and ensure higher resilience.

Robust isolation by design

Each domain, represented by a NodePool and a NodeClass, can be configured with dedicated subnets, security groups, and custom permissions. This design strengthens regulatory compliance, protects sensitive workloads, and mitigates operational risks while ensuring each workload runs on the most suitable resources for its profile.

Declarative governance: GitOps as the foundation for scale

As our platform expanded, we needed an operational model that combined agility, traceability, and quality control. GitOps became the cornerstone of this governance model:

• The environment’s desired state is declaratively defined and versioned in Git repositories.
• FluxCD and custom pipelines perform continuous reconciliation with the actual state.
• Every change goes through a pull request, with automated validations and human review.
• Progressive rollouts are applied in multiple waves, reducing risk and enabling fast, safe rollbacks.

The result is a consistent, predictable, and fully auditable environment, even with tens of thousands of monthly changes.

Automatrix: A governance-first platform for large-scale operations

Managing dozens of clusters and hundreds of thousands of workloads requires more than just automation; it requires governance by design. With this principle in mind, we developed Automatrix, a proprietary platform that centralizes and standardizes the provisioning and lifecycle management of Kubernetes clusters at Mercado Libre.

Automatrix is API-driven and enables:

• Fully automated provisioning and upgrade workflows.
• The generation of hybrid templates using CDKTF and CDK8s for fast creation and configuration adjustments.
• Inheritance of corporate standards across different types of clusters and workloads.
• Native integration with GitOps pipelines for continuous governance and automation.

Every change automatically generates a pull request that is validated and tested before being applied. This process minimizes human error, simplifies rollbacks, and ensures sustainable, auditable platform evolution.

The result is an operation where clusters can be created and made production-ready within minutes, with security, compliance, and best practices embedded from the start.

Results in production

Karpenter, GitOps, and Automatrix integration have transformed our container operations. The key outcomes include:

• Intelligent provisioning and scalability enable near-instant deployments and migrations.
• Operational consistency is achieved with automated and auditable policies that ensure compliance and traceability.
• Autonomy and productivity for squads allow teams to focus on innovation and delivering business value.
• Cost efficiency results from the extensive use of Spot instances and advanced bin packing, achieving continuous savings without sacrificing availability.

Lessons for the Kubernetes community

Our experience at Mercado Libre demonstrates that scaling Kubernetes across large, multi-cloud environments is achievable without compromising control, cost efficiency, or governance. The pillars of this model include:

• Automation and intelligence: Tools like Karpenter enhance automation, optimize costs, and improve resilience without adding bureaucracy.
• Declarative governance and GitOps: A single source of truth, auditable pipelines, and continuous reconciliation ensure quality even in complex, large-scale environments.
• Robust internal platforms: Investing in solutions like Automatrix promotes reusability, standardization, and adopting new practices while maintaining flexibility and compliance.
• Focus on development: We empower product teams to focus on innovation by simplifying and automating infrastructure.

Our journey continues as we explore intelligent autoscaling, serverless provisioning, and AI-powered observability, innovations that continuously expand our capabilities. For those operating at a large scale, pursuing automation, intelligence, and governance at every level is the key to building the next generation of cloud-native platforms.

Acknowledgments

This article was written with the support of Marcelo Quadros and Marcos Pinheiro

Scaling Kubernetes at Mercado Libre with Karpenter and GitOps was originally published in Tecnología de Mercado Libre on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous article, How Kubernetes powers Fury at Mercado Libre, we explored how our internal development platform overcame the challenges of scale and complexity by adopting Kubernetes as its core engine. We also highlighted how Fury transforms the developer experience (DevEx) by abstracting infrastructure management, allowing teams to focus entirely on innovation and value creation.

This new article dives deeper into the technical and strategic aspects behind our decision to adopt Kubernetes. We’ll analyze the alternatives we evaluated, the challenges we faced during implementation, and how these decisions continue to support our multi-cloud strategy and operational resilience. This evaluation process, which took about six months, resulted in the creation of multiple RFCs and detailed reports, complete with metrics that guided our decision-making.

Context

As Mercado Libre continued to expand, we encountered limitations with Fury’s first computing model, known as “Standard.” This instance-based model effectively served as an interface between our platform and cloud providers. However, we faced two critical issues: low efficiency due to the 1:1 relationship between application replicas and computing instances, and limited utilization of native cloud provider functionalities.

These challenges underscored the need for a more efficient solution to optimize resource utilization and reduce costs, ultimately steering us toward adopting Kubernetes.

Evaluating alternatives

In our search for the best infrastructure solution, we conducted a thorough study of several alternatives, as shown in Image 1. We started by examining job workloads and then looked at Function as a Service (FaaS) options. Next, we explored Container-as-a-Service (CaaS) models and finally assessed orchestrators for enhanced container management. Each alternative had its own strengths and weaknesses, leading us to choose Kubernetes as the optimal solution.

First alternative: Job workloads

We started evaluating new alternatives starting with Job workloads. For this type of workload, where Cron rules schedule executions, inefficiency was particularly noticeable: instances remained active 24/7, incurring unnecessary costs even when jobs ran only once a week, for example.

To address the inefficiencies associated with idle resources in our infrastructure, we explored AWS Batch, a managed service designed for running batch-processing workloads at scale. AWS Batch dynamically provisions compute resources based on a job’s requirements, making it suitable for scheduled workloads such as those managed via Cron jobs. By using AWS Batch, we could trigger jobs without keeping instances running continuously, reducing the overhead of maintaining idle resources for infrequent workloads (e.g., once a week or monthly).

However, while AWS Batch is effective for traditional batch jobs, it didn’t meet all our needs. Specifically, it wasn’t suitable for workloads that require more dynamic scaling or event-driven activation. One example is BigQueue, our internal messaging system built on cloud services. BigQueue processes messages consumed by various applications that may only receive messages sporadically. This pattern led to idle periods, with message consumers remaining inactive until new data arrived. Since AWS Batch is designed for jobs with predictable start and end times, it wasn’t suitable for the unpredictable workload of systems like BigQueue consumers, which often handle bursts of messages. As a result, AWS Batch was insufficient for our needs; we required a solution that could effectively manage variable message traffic with minimal latency and scale on demand.

Second alternative: Function as a Service

The second set of alternatives we considered was Function as a Service(FaaS), specifically evaluating AWS Lambda. While AWS Lambda was designed to run code in response to events, it has a maximum execution time of 15 minutes, making it unsuitable for long-running tasks — a critical requirement for some workloads. Although Lambda works well for short-lived, stateless tasks triggered by events, its limitations in execution duration and state management forced us to explore other options.

Moreover, combining AWS Lambda with AWS Batch would have introduced significant complexity. Each service is optimized for different use cases — Lambda is event-driven and stateless, while AWS Batch manages large-scale batch jobs. Implementing and managing two distinct systems would increase operational overhead, particularly in terms of monitoring, logging, and workflow orchestration. This complexity highlighted our need for a more unified solution.

Another significant challenge was the extensive code refactoring needed to adapt our existing applications to new solutions. With over 30,000 microservices in operation, this would have required considerable rework on our development teams. Since our architecture was container-based, we decided to focus on Container-as-a-Service (CaaS) models to simplify deployment and management.

Third alternative: Container as a Service

In evaluating Container as a Service (CaaS) options, we considered AWS ECS, Google Cloud Run, and Cloud Run with Anthos. Each had its strengths, but none fully met our requirements.

We started by assessing AWS ECS (Elastic Container Service), designed for deploying and scaling containerized applications. ECS supports sidecar containers, which are critical for our architecture, as we rely on sidecars to manage auxiliary services such as logging and monitoring. Despite its power, ECS lacked the flexibility we needed, particularly in multi-cloud environments, and didn’t support certain features we required out of the box.

Next, we evaluated Google Cloud Run, a fully managed, serverless platform optimized for stateless containers. Cloud Run automatically scales containers based on HTTP requests, making it ideal for event-driven workloads. However, it didn’t support sidecar containers at the time, which are central to our system’s design, leading us to rule out Cloud Run for our use cases.

We then tested Cloud Run integrated with Anthos, which enables Cloud Run’s serverless workloads to deploy across hybrid and multi-cloud environments. While this integration provided flexibility to overcome some limitations of using Cloud Run alone, it introduced additional operational complexity. Managing Cloud Run for container execution alongside Anthos’ orchestration capabilities across different cloud environments proved to be challenging. The added complexity and integration challenges made this solution less favorable for us.

Ultimately, none of these CaaS options fully met our requirements, especially considering the complexity of managing such a large-scale architecture.

The final solution: orchestrators

Our exploration then shifted toward orchestrators. We evaluated Kubernetes (EKS and GKE), Nomad, and solutions like Knative, which builds on Kubernetes to offer additional serverless and event-driven workload features. However, Knative was ruled out early as it didn’t align with Fury’s operational requirements and introduced functionality that conflicted with our existing architecture. The ideal orchestrator needed to integrate seamlessly with Fury’s operating model while avoiding application rewrites or significant rework by developers.

With prior experience using Nomad in other projects, we divided the team to run proofs of concept (POCs) simulating Fury’s workloads on Kubernetes and Nomad. Both POCs yielded positive results, but a deeper analysis of critical factors — such as cluster management and service exposure — revealed Kubernetes as the more suitable choice. Its straightforward IP-per-pod configuration, robust autoscaling capabilities, and strong community support (including plugins tailored to multiple cloud providers) gave it a clear edge. In contrast, Nomad’s cluster management presented more significant challenges, mainly due to the need for complementary tools like Consul and the absence of managed clusters on the cloud platforms we used.

After several months of thorough research — including POCs, RFCs, and comparative analyses — we selected managed Kubernetes solutions: Elastic Kubernetes Service (EKS) and Google Kubernetes Engine (GKE). These platforms best addressed Fury’s operational and technical needs while ensuring scalability and ease of integration with our ecosystem.

Lessons learned

Reflecting on our journey, several key lessons emerged that can serve as actionable takeaways for others embarking on a similar path:

• Evaluate all options thoroughly: Conduct comprehensive assessments of multiple platforms, considering not only technical features but also alignment with operational needs.
• Plan for code refactoring: Anticipate the need for code changes and factor in the potential impact on development timelines and resources.
• Focus on integration: Choose solutions that can seamlessly integrate with existing architectures to minimize disruptions and reduce the burden on development teams.
• Use proofs of concept: Implement POCs to test the viability of solutions in the context of your specific workloads and operational requirements before fully committing.
• Leverage community support: Opt for technologies with strong community backing to ensure access to resources, plugins, and best practices that can ease the implementation process.
• Do not buy the buzz: Evaluate solutions against your unique needs rather than following trends or popular choices. A solution that meets others’ needs may not suit your specific criteria.

By keeping these lessons in mind, organizations can better navigate the complexities of adopting new orchestration technologies like Kubernetes and enhance their chances of successful implementation.

Conclusion

Adopting Kubernetes has significantly enhanced Fury, amplifying the platform’s capabilities and flexibility. By transitioning to managed Kubernetes solutions like EKS and GKE, we resolved operational inefficiencies and seamlessly integrated with our existing container-based architecture. This improvement empowered our platform to better support the needs of over 30,000 microservices, providing developers with a scalable, streamlined environment focused on innovation rather than operational complexities.

What sets our implementation apart is its forward-looking design. By aligning with Kubernetes, we’ve ensured that Fury remains adaptable to future technologies. Our architecture is built to allow a transition to an alternative orchestrator or paradigm with minimal disruption, reflecting our commitment to flexibility and resilience in a constantly evolving tech landscape.

Kubernetes has improved Fury’s operational power and strengthened its position as a platform built for sustainable growth and innovation. For organizations looking to elevate their internal platforms, this journey underscores the importance of balancing immediate benefits with long-term adaptability.

Even though we say Kubernetes is our final solution, at Mercado Libre, we’re in a state of Continuous Beta. We are always looking for new options. Who knows — in the future, we’ll revisit this article and add an evolution or a new choice. What do you think?

This article was written in collaboration with Marcos Antonio Souza Pinheiro and Marcelo Cordeiro De Quadros.

How Kubernetes became the right fit for Mercado Libre’s internal developer platform was originally published in Tecnología de Mercado Libre on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Mercado Libre, managing over 30,000 microservices and supporting 16,000 developers requires a robust and scalable solution. To address these challenges, we adopted Kubernetes (K8s) as the core engine of our internal platform, Fury. This article explores how Kubernetes streamlined our infrastructure management, accelerated software delivery, and improved cost efficiency, enabling our developers to focus on innovation and product creation.

Fury structure

Since this article focuses on implementing Kubernetes within the Fury platform, it’s important to have a basic understanding of Fury to better grasp the topics covered. We recommend a preliminary reading on the subject.

In brief, Fury is an internal developer platform (IDP) composed of cloud applications and services. It provides a web interface and a command-line interface (CLI), allowing developers to create and manage resources. Additionally, the Cloud and Platform teams use a back office to administer and monitor the platform and manage its operations.

Fury and its abstractions

In a simplified way, Fury is an abstraction layer developed internally at Mercado Libre. It serves as a bridge between third-party services, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), Datadog, and others, and user applications. Regardless of the provider or partner used, developers generally interact with services through Software Development Kits (SDKs), while Fury’s APIs communicate with the providers.

This means that applications do not communicate directly with cloud services. There is an anti-corruption layer that prevents lock-in, facilitates version updates, and enables switching to similar services without requiring code changes. This abstraction is essential to support the company’s multi-cloud strategy, ensuring flexibility and better cost and security management.

The genesis: the compute engine

The compute engine is the Fury component responsible for managing user workloads. When Fury was created in 2015, Kubernetes was still in its early stages and wasn’t mature enough to handle the volume of workloads and technical needs that Mercado Libre required. Thus, adopting instance-based computing services from cloud providers like AWS EC2 and Google Compute Engine was the most natural choice.

The first computing model developed was called Standard. It serves as an interface between the platform and cloud providers. This model receives platform commands, such as creating or scaling instances, and executes these operations on the providers.

While the simplified diagram below represents this model, its complexity is much greater. One example is a component called Little Monster (LM), part of the Standard module, which manages the atomicity of distributed transactions. LM requests instances from the cloud provider and ensures they are ready for use, handling necessary waits and pooling during the creation and initialization process.

The diagram shows that this model already operates across multiple regions and cloud providers. Since its inception, it has been designed for this purpose, so all auto-scaling management was developed internally as part of the compute module without relying on AWS Auto Scaling Groups (ASGs) or equivalent features from other clouds. This decision was motivated by the need to create a multi-vendor solution, thus justifying the development of this abstraction layer.

The Standard module has been a reliable component of Fury, operating successfully for many years. It has enabled Mercado Libre to scale and address significant business challenges. However, over time, it presented two challenges that needed solution:

1. Low efficiency: Each replica of an application requires a computing instance, such as an EC2, creating a 1:1 relationship. Even though we employed strategies like reservations, spot instances, savings plans, and ARM instances with Graviton for cost efficiency, there was still room for improvement.
2. Limited utilization of native cloud provider resources: Due to the developed abstractions, the module did not optimally leverage native cloud provider resources and functionalities, limiting the full potential of the capacities offered.

Alternative study

We conducted an extensive study to find a more efficient solution, evaluating various technologies and approaches. Initially, we explored AWS Batch for on-demand resource activation, but it didn’t meet all our needs. We also considered AWS Lambda, but its limitations for long-running tasks made it unsuitable. We looked into container-based solutions like ECS and Cloud Run as well, but their complexity and lack of necessary features led us to dismiss them. After testing Kubernetes (EKS and GKE) and Nomad, we ultimately discarded Nomad and decided to move forward with managed Kubernetes solutions, EKS and GKE, as they best fit our needs.

This evaluation and its findings are available in this post.

Current implementation: compute service with EKS and GKE

After months of planning and development, we arrived at the current architectural model, named Serverless. Unlike the common concept of serverless computing, which typically refers to Lambda functions, we adopted this name to illustrate the complete lack of direct server knowledge and management required from developers — they interact exclusively with Fury’s abstraction layer, embracing a server-free perspective. The platform, in turn, manages resources transparently, with Serverless serving as a unique differentiator that reflects this philosophy of full automation, thus facilitating adoption.

This evolution introduced the Serverless Module, replacing the old Standard Module while retaining the Little Monster (LM) component, ensuring operations’ atomicity. The most notable change lies in the communication layer between the platform and the cloud providers: the new compute module interacts with a solution called Cluster API. It’s worth noting that this Cluster API is not the same as the one defined by Kubernetes; in our context, it abstracts the Kubernetes control plane, acting as a translation layer between various Kubernetes versions and the compute module.

Cluster API: an efficient abstraction layer

The Cluster API was developed to address the growing complexity of managing multiple simultaneous Kubernetes versions and to handle APIs that are frequently deprecated over time. This component is designed to minimize the impact of these changes on the compute module, leaving the lifecycle management of Kubernetes versions solely to the Cluster API. This approach also allows us to replace Kubernetes in the future, if necessary, with minimal migration effort to another orchestrator.

Serverless module: control and scalability

Unlike the Cluster API, which acts as a wrapper for the control plane, the Serverless Module abstracts the computational “shadings” introduced by clusters. Clusters fragmented what was once a single regional data plane into multiple ones. The Serverless Module is responsible for adapting this new concept to the platform, handling additional complexities such as inferring the most suitable cluster for a given workload.

Scalability and controlled upgrades

With over 130,000 instances, the current architecture is already segmented by regions, providers, and other divisions based on criticality and workload type. These segmentations are crucial in our approach to controlled upgrades, especially during data and control plane component updates. When an upgrade is required, the process begins with clusters of lower criticality and test environments to ensure stability. Only after careful validation are changes gradually promoted to higher criticality clusters. This strategy minimizes risks and ensures that service continuity is not compromised.

Deployment flow

Now that we’ve explored our engine’s architecture, let’s examine the application deployment flow within the Fury platform. We adopted a GitOps approach to deploy our engine’s internal components; however, this topic deserves a separate discussion.

There are different deployment strategies within Fury, such as All-in, Blue-Green, and Canary, each catering to specific developer scenarios. However, there are two platform-specific strategies: Safe deployment and Migration:

• Safe deployment: This strategy is similar to Blue-Green deployment but takes a more gradual and cautious approach. It continuously monitors metrics and makes automated rollback decisions or adjustment recommendations, ensuring a safe and controlled process.
• Migration: A broader strategy that allows workloads to be moved between vendors, regions, or even between different computational environments (from Standard to Serverless and vice versa), depending on resilience and cost needs.

Deployment flow details

In the deployment architecture, Fury triggers the Serverless Module, which initiates the process by requesting the creation of workloads. This request passes through the Cluster API via an Application Load Balancer (Ingress ALB), which distributes the traffic and creates everything necessary to route the applications properly.

Next, the Cluster API configures the required Kubernetes components, such as ReplicaSets and Horizontal Pod Autoscalers (HPAs). We chose to use ReplicaSets instead of Kubernetes Deployments because our goal is to ensure the proper number of replicas without needing additional resources provided by Deployments, as such strategies were already part of the platform.

Monitoring and asynchronous control

Once the workloads are created, the Serverless Module — specifically its Little Monster (LM) component — performs continuous monitoring and handles the asynchronous requests sent to the cluster. The Serverless API Controller (a Kubernetes controller) extends K8S by observing the behavior of the pods and nodes directly in the cluster, keeping the platform informed about any real-time changes. This controller reconciles the state of the cluster with an external state through the “watchers” of these objects, notifying the Serverless Module so that the platform can respond and dynamically adapt.

This structure allows Fury to perform deployments efficiently and robustly, monitor the state of clusters and workloads, and respond to real-time changes with resilience and security.

Deployment flow — Blue-Green

When applying a Blue-Green deployment in Fury, the process follows the same basic flow described earlier but includes some essential specifics.

In this scenario, the current set of workloads in production (the Blue version) is maintained while a new set of workloads (the Green version) is created in parallel. This new set can be deployed in the same cluster or, depending on shard balancing strategies, in a different cluster.

The creation flow is the same as the standard deployment: the platform activates the Serverless Module, which then requests the Cluster API via the Ingress ALB. This step sets up all the necessary Kubernetes components, such as ReplicaSets and HPAs, replicating the current infrastructure for the new set of workloads.

Once the Blue-Green deployment is completed, the platform automatically updates its internal state, recording all changes. This way, we maintain continuous and detailed control over both versions of the workloads (Blue and Green), allowing for a safe and organized transition to the new version once the necessary checks are completed.

Network and traffic swap

A critical point during the Blue-Green deployment is the progressive traffic redirection from the current version to the candidate. To achieve this, we employ a specific approach that ensures comprehensive network visibility and rapid synchronization between components.

Every pod inside our clusters have unique and routable IPs from the VPC instead of VIPs (Virtual IP). This allows each pod to have direct network visibility, facilitating communication with other services and reducing the need for entry points per cluster.

Since we do not use third-party networking products for routing, we developed an internal component called the Mesh Controller. This controller plays a crucial role in the traffic swap process, responding to changes generated by the control plane. As soon as an event is detected, the Mesh Controller synchronizes the state and notifies the control plane API of the platform, that is, our Service Mesh.

This notification automatically updates all Envoy sidecars deployed with the applications. As a result, the routes are adjusted so that the Envoys redirect traffic to the new candidate, completing the traffic transition to the latest version and ensuring that the platform and applications are always aware of the updated route.

Conclusion

The journey of Fury at Mercado Libre exemplifies how technological evolution and constant innovation determine the ability to overcome challenges and drive efficiency at scale. Built on a robust Kubernetes foundation, Fury has transcended operational complexities, offering developers an intuitive, secure, and scalable environment. By abstracting infrastructure management and optimizing the deployment flow, Fury allows our engineers to focus on creating real value through code while also enabling the company to adopt strategies like multi-cloud and make strategic decisions with rapid financial impact. This approach positions us to meet current demands and anticipate and overcome future challenges, reaffirming our commitment to an exceptional development experience and continuous evolution.

Acknowledgments

This article was written with the collaboration of Marcos Antonio Souza Pinheiro and Marcelo Cordeiro De Quadros.

Kubernetes at Mercado Libre was originally published in Tecnología de Mercado Libre on Medium, where people are continuing the conversation by highlighting and responding to this story.

The technological evolution at Mercado Libre: from the monolith to the multicloud platform

If you are wondering whether to embrace a multicloud platform or not, then you’ve come to the right place. Welcome to our series of articles where we share our experiences in building the main features of the Fury platform, an Internal Developer Platform created by Mercado Libre that provides developers with a unified and self-service environment to efficiently create, deploy, manage, and monitor applications.

Join us on a journey to the heart of Mercado Libre’s tech team, where we create and orchestrate all the applications that make up our ecosystem. Throughout this exploration, you will witness our technological evolution as we move from a monolithic architecture to an integrated, cloud-agnostic, and flexible platform as a service.

To get to speed with the exponential growth of Mercado Libre, our Tech team has developed a solution that enables massive scaling and provides a world-class user experience to our +15,000 engineers. They use this platform daily to create top-notch applications. Managing over 30,000 microservices running on 100,000 instances in production, our team ensures seamless integration, agility, simplicity, and security.

The Mercado Libre ecosystem consists of various pillars or business units such as marketplace, fintech, online shops and ERP, logistics, and advertising. These units rely on a single platform, Fury, for their development and operation. But how did we come up with this innovative solution?

A glimpse into history: Old World

Back in 1999, we released the first version of Mercado Libre’s Marketplace, which was built on a monolithic architecture. At that time, the platform consisted of a few hundred physical servers running on a single Oracle database, with only one code repository in which over 200 developers interacted daily. What started as a small-scale solution quickly grew into a behemoth.

Deployments were carried out on a weekly basis, resulting in frequent delays in the development process as code freezes were required to deliver the solution to the Quality teams. Testing every functionality became a challenge, leading to slow error response times. Additionally, the complex configurations of the environments made it difficult to test new technologies.

Developers faced significant challenges when deploying their changes on the same codebase. This often resulted in conflicting functionalities, where one functionality would work correctly while the others would break. Scaling the system became significantly challenging, finally leading to a high time-to-market.

Imagine the chaos — would it be possible to have 3000 developers deploying more than 10 times a day in this scenario?

MeliCloud: Embracing innovation for complex workflows

Around 2010, Mercado Libre faced a critical decision — to build a “New World” that could break free from constraints an embrace a more scalable infrastructure based on microservices. With the mobile technology boom creating a demand for APIs to handle the growing complexity of workflows, our Cloud & Platform team embarked on a journey of research and experimentation. After careful consideration, we boldly decided to migrate to a cutting-edge platform called MeliCloud.

Melicloud introduced infrastructure as a service, bringing several advantages, including increased developer speed and flexibility. We were able to efficiently manage a large number of interconnected microservices, including:

• 17,500 instances
• Over 1,200 traffic pools
• Deployment of over 1,400 instances per day (representing over 10% of the total number of instances)
• Partial service failure support

Now that you are into microservices, is chaos controlled?

As our focus shifted towards microservices, we found ourselves in a precarious situation — was chaos truly under control? Too much flexibility led to a complex scenario where our teams dedicated considerable time to resolving operational production issues instead of focusing on product improvement. We transitioned from a state of utter chaos, where progress seemed impossible, to a state of chaotic freedom, where everyone had unlimited control.

However, this infrastructure posed significant maintenance challenges given the available resources at that time:

• Numerous environments and configurations
• Complexity in evolving the infrastructure
• Substantial disparities between Development, Stage, and Production environments
• Steep learning curve
• Demanding extensive infrastructure knowledge to operate
• Team expansion and an increase in the number of development centers

What were our needs?

Our main objective was to streamline operational tasks for engineers, providing them with all the necessary tools for simple development and production management while maintaining a clear separation between frontends and APIs. We required a single location for infrastructure, build, deployment, metrics, and services.

We realized that we needed a robust platform that would allow our developers to have an application up and running in just three clicks. Our goal was to enable them to download the app, make changes, and test it while brewing a cup of coffee: easy to run, easier to deploy to production. So, we designed and developed Fury.

Fury: Hello, world

That’s how Fury was born in 2015. It’s an internal developer platform (IDP) built in-house that empowers developers to create, deploy, manage, and monitor applications.

Here are some highlights:

• A unified platform with a defined technological stack, languages, frameworks, and tools tailored to our needs and quality standards
• Portability and consistency in deployment by using containerization
• Similar and replicable environments with reusable components and services
• Cost management and optimization
• Multicloud capability with cloud provider abstraction
• Ready-to-use deployment infrastructure
• Integrated monitoring tools within the platform
• Simple development workflow
• User-centered UI focused on a platform that is easy to manage and use
• Scalability for products and teams

What benefits does Fury bring to Mercado Libre?

Fury brings several benefits to Mercado Libre:

1. Streamlined Development Process: Fury provides a centralized, self-service platform where developers can access the necessary tools, services, and infrastructure to build and deploy applications. This improves developer productivity and accelerates the development cycle.
2. Reduced Cognitive Load: By offering a unified platform, Fury relieves developers of the cognitive load associated with navigating multiple systems and processes. This allows them to focus more on developing high-quality applications.
3. Enhanced Security and Compliance: Fury enforces standardized policies and controls, ensuring consistency and reducing risks associated with ad-hoc development practices. This strengthens security and helps maintain compliance with relevant regulations.
4. Flexibility and Scalability: With its multicloud abstraction, Fury enables teams to leverage the most suitable services and resources from different cloud providers. This flexibility and scalability allow Mercado Libre to adapt and grow as needed.

In summary, Fury has significantly contributed to faster, more efficient, and secure software development at Mercado Libre.

Building apps has never been this easy at Mercado Libre

To create an application, developers can use the Fury front end. With just a few clicks, they can select the desired application type and technology. Behind the scenes, the platform automatically generates a GitHub code repository with the necessary team permissions, sets up the CI/CD pipeline, and provides a basic scaffolding with a preconfigured containerized image.

Additionally, Fury offers a command-line interface (CLI) that enables developers to download the application locally, run it, test it, and create versions ready to deploy using the terminal on their computers. This seamless integration not only extends to the infrastructure but also to the developer’s local environment, providing a cohesive development experience.

Simplifying application deployment with Scopes

At Mercado Libre, we have introduced the concept of Scopes as a means of managing application versions, deployments, and segmentation. Scopes serve as a simplified representation of Fury within cloud provider containers like AWS or GCP. With Scopes, applications can quickly transition from the development environment to an integrated infrastructure, enabling efficient testing in a dedicated test or demo scope. Once the final version is ready, it can be deployed to a production scope.

When creating a scope, the necessary infrastructure is automatically generated, including a load balancer, autoscaling groups, and instances. Traffic is directed to these resources, generating logs, metrics, and monitoring alerts. Fury also provides insights into infrastructure costs and leverages automated optimizations to reduce them. To ensure reliability, critical applications are divided into separate scopes. This approach prevents any failure in one scope from affecting others, enabling a more efficient response to contingencies.

What does this mean for us? With Fury as our platform, the infrastructure is automatically managed and scaled based on our business needs, adding or removing instances as necessary. This enables us to maximize efficiency and optimize costs.

Efficient code integration with Release Process

Since 2018, we have implemented a Release Process feature to manage code integration into our applications effectively. This process leverages the concepts of Continuous Integration (CI) and Continuous Delivery (CD). It uses open-source tools to ensure a simple and rapid flow that aligns with our development needs.

Powering over 26,000 repositories, our Release process automatically runs seven tailored quality validations to uphold the integrity of every application we build. These comprehensive checks include dependencies, branching models, CI, code coverage, and hardcoded credentials. If any check fails, the entire flow is interrupted until the issue is solved. The result? A seamless and efficient code integration process that backs up our developers every step of the way.

Deploying with different strategies according to scenario criticality

When it comes to deploying our applications, there is no one-size-fits-all approach. Each scenario has its unique requirements and considerations. That’s why Fury offers a range of deployment strategies for developers to choose from according to the scenario’s criticality and the potential impact on the business.

Some strategies involve reusing existing infrastructure, making them fast and cost-effective. However, they can bedifficult to roll back in case of errors, potentially causing downtime. These strategies are ideal for testing small changes or low-criticality scopes.

On the other hand, strategies like Blue Green deployment involve creating a new environment and gradually swapping traffic. They are ideal for productive scopes that requiere fast recovery in case of errors. They allow for quick rollback with no downtime and minimize user impact through careful traffic monitoring.

By providing these different deployment strategies, Fury enables developers to make informed decisions based on the specific needs of each scenario, ensuring efficient and reliable application deployments.

Empowering developers with app monitoring tools

At Fury, we provide developers with robust app tools to keep their applications running. By focusing on metrics, logs, and monitoring, we detect issues early and minimize potential downtime. From monitoring infrastructure (CPU and memory) to tracking business rules like peak payment processing times, we ensure that nothing slips from our radar.

Developers have complete ownership over their applications and are equipped with customizable alerts for all kinds of errors. This proactive monitoring culture enables us to take action before problems escalate. With Fury, developers can leverage the power of monitoring services like DataDog, NewRelic, and Opsgenie, with standard monitors tailored to the specific services they are using.

Keep driving innovation and growth

The technological evolution at Mercado Libre has been remarkable. Evolving our work culture in this way allowed us to iterate on our products in an agile and decoupled manner. At the same time, it has accelerated our innovation processes to accompany Mercado Libre’s exponential growth.

From the early days of monolithic architecture to the current state of our advanced multicloud platform, we have witnessed tremendous growth and innovation. We have embraced the power of microservices for greater scalability and flexibility. The adoption of containerization technology has revolutionized our development and deployment processes, allowing us to iterate faster and deliver value to our users more efficiently.

The shift towards a multicloud approach has unlocked new possibilities, providing us with the flexibility to leverage the best services and resources from multiple cloud providers. This strategic decision has not only improved our performance and resilience but has also optimized our costs.

Next steps in our journey

At Mercado Libre, we are always seeking new opportunities to innovate and push the boundaries of what is possible. That’s why we have formed a strategic alliance with OpenAI, with whom we are exploring the possibilities of generative artificial intelligence (GenAI). We believe that GenAI holds great potential within our ecosystem to create disruptive solutions that bring value to our developers.

As we continue to evolve and push the boundaries of what is possible, we remain committed to delivering better experiences for our developers. We strive to provide them with the best tools and resources to improve our mission of democratizing commerce and financial services to transform the lives of millions of people in Latin America.

In our upcoming articles, we will delve deep into various aspects such as traffic security, cost optimization, and our multicloud strategy. These topics are vital to our technological evolution and will showcase the innovative solutions we have implemented to ensure the scalability, resilience, and efficiency of our systems.

This amazing journey has only just begun, and we invite you to stay tuned for more exciting updates and insights. Together, we will continue to shape the future of technology and revolutionize the way people engage in commerce and financial services.

The technological evolution at Mercado Libre was originally published in Tecnología de Mercado Libre on Medium, where people are continuing the conversation by highlighting and responding to this story.