DEV Community: Mario Ezquerro

Gubernator [the kill ku8s]

Mario Ezquerro — Tue, 02 Jun 2026 12:55:56 +0000

Why I built an alternative to Kubernetes overkill.

Let’s talk about infrastructure efficiency.

Kubernetes is the undisputed industry standard for container orchestration, and for massive, complex enterprises, it’s irreplaceable. But for small-to-medium deployments or distributed multi-host edge environments, it often feels like an operational nightmare.

You install a massive orchestration layer, only to realize it's still missing the basics for actual operations. To get it production-ready, you have to layer on external tools for Ingress routing, plus a heavy stack for observability, health metrics, and SLOs. Suddenly, your infrastructure consumes more resources than your actual applications.

I believe in radical software minimalism. That’s why I’ve been developing Gubernator (gbnt), an open-source, lightweight distributed container orchestrator written entirely in Go.

Unlike traditional platforms, Gubernator bakes essential Site Reliability Engineering (SRE) and traffic management right into its core architecture:

Native Reverse Proxy: No complex third-party Ingress controllers. Gubernator automatically manages routing—like dynamically hooking up web containers to an Ingress layer (e.g., Caddy)—making exposure seamless and native.

Built-in SRE & Observability: Out-of-the-box support for health monitoring, metrics, and SLO tracking natively leveraging OpenTelemetry and Prometheus.

Zero-Bloat State Management: It swaps out heavy external key-value stores for an embedded, rock-solid SQLite architecture, ensuring multi-host consistency with a near-zero footprint.

Gubernator is designed for engineers who want robust, predictable, and resilient orchestration without the overhead and cognitive load of K8s.

If you are passionate about minimalist backend architecture, systems engineering, or streamlined DevOps, I’d love for you to take a look at the blueprint and documentation:

Explore the project: https://mario-ezquerro.github.io/gubernator/

How do you handle container orchestration for smaller setups? Let’s connect and discuss in the comments!

SoftwareEngineering #GoLang #SRE #DevOps #ContainerOrchestration #OpenSource #SystemsArchitecture #Minimalism

The Kubernetes Overkill: Why I Built a "K8s Killer" for Small Environments

Mario Ezquerro — Fri, 29 May 2026 09:48:30 +0000

Let’s be honest: Kubernetes is the undisputed king of orchestration. But if you are running a small to medium-sized environment, deploying K8s is often like using a sledgehammer to crack a nut. It brings massive resource overhead and operational complexity that most projects simply do not need.

Worse yet, despite its size, Kubernetes isn't actually a complete solution out of the box.

If you want proper SRE management—like native observability, health checks, and Service Level Objectives (SLOs)—you have to bolt on a complex stack of external tools. Need Ingress management to expose your services? You'll have to configure and maintain third-party Ingress controllers just to get traffic flowing.

That architectural bloat led me to advocate for a more minimalist approach. I wanted an orchestrator that provided everything necessary for robust deployments without the massive footprint.

Enter Gubernator: built to be the Kubernetes killer for small environments.

What Makes Gubernator Different?
Gubernator (gbnt) is a lightweight, distributed container orchestrator written entirely in Go. It strips away the unnecessary layers of traditional orchestration and bakes the essential operational requirements directly into its core:

Native SRE & Observability: Instead of treating SRE as an afterthought, Gubernator integrates robust health checks and observability (leveraging OpenTelemetry and Prometheus) directly into the orchestrator.

Built-in Ingress Management: No need to wrestle with external controllers. Gubernator handles your ingress routing natively, simplifying how you expose and manage your services.

True Software Minimalism: By using SQLite for data consistency rather than heavy key-value stores, Gubernator maintains a tiny resource footprint while ensuring reliable state management across multiple hosts.

Developer-Friendly Interface: A clean REST API and an intuitive CLI tool get your containers running securely and efficiently.

If you are tired of the Kubernetes learning curve and the overhead of maintaining tools you barely use, it's time to look at alternatives that prioritize simplicity and reliability.

Check out the repository, documentation, and architecture here: Gubernator on GitHub Pages:

https://mario-ezquerro.github.io/gubernator/

I’d love to hear from the community: at what point do you think Kubernetes becomes too big for its own good? Drop your thoughts in the comments!

Introducing Gubernator: A Minimalist Container Orchestrator Alternative

Mario Ezquerro — Wed, 27 May 2026 06:11:16 +0000

Hey everyone, I'm Mario. Over the past few months, I've been working on a project that I'm really excited to share with the community.

If you've ever felt that Kubernetes (K8s) is a bit too heavy or overwhelming for certain deployments, you're not alone. While K8s is a powerhouse, it isn't always the right tool when you need a streamlined, minimalist approach. That’s exactly why I built Gubernator (gbnt).

What is Gubernator?
Inspired by the efficiency of Roman governance, Gubernator is a lightweight, distributed container orchestrator written entirely in Go. It’s designed to manage containers across multiple hosts efficiently, without the massive resource footprint and complexity of traditional orchestration systems.

Key Highlights:

Simplicity by Design: It features a clean REST API and an intuitive CLI tool (gbnt) to get your containers up and running quickly.
Built for Reliability: SRE principles are a core focus. Gubernator natively integrates robust observability, health checks, and Service Level Objectives (SLOs) leveraging OpenTelemetry and Prometheus.
Efficient State Management: Instead of requiring heavy external key-value stores, it utilizes SQLite to maintain rock-solid data consistency within a minimalist architecture.
Performance-Oriented: Being Go-native, it’s fast, reliable, and perfectly suited for distributed environments or unikernel-inspired deployments.

Gubernator is an exploration into rethinking container management for modern, lightweight infrastructure. It's built for those who advocate for software minimalism and want just the right amount of orchestration without the overhead.

You can check out the documentation and the repository here: Gubernator Docs & Repo:

https://mario-ezquerro.github.io/gubernator/

I’d love to hear your thoughts, feedback, or any questions you might have in the comments. Let's talk about minimalist backend architecture!

The Loading Screen

Mario Ezquerro — Fri, 15 May 2026 08:46:20 +0000

BUILD WITH AI [Antigravity]

Building “The Loading Screen”: A Real-Time Interactive Experience with Google Cloud Run and Anti-Gravity
How we turned pre-event waiting time into a high-bandwidth, 100% stateless interactive game.

The Concept: “Don’t Panic, We’re Caching the Awesome”
We’ve all been there: waiting for a conference talk to start, staring at a static slide. We decided to change that. The Loading Screen is an interactive, real-time web application designed to turn pre-event “lag” into an analog networking experience.

It consists of a massive “Stage View” (projected on the main screen) and a “Mobile Interface” that turns every attendee’s smartphone into a remote controller.

The Architecture: 100% Stateless & Cloud-Native
When building for live events, the two biggest fears are latency and sudden traffic spikes. To solve this, we designed the system to be completely stateless, optimized for the serverless nature of Google Cloud Run.

Key Tech Stack:
Backend: Node.js 20+ with Express.
Real-Time: WebSockets via Socket.io for sub-millisecond interaction.

Deployment: Dockerized containers on Google Cloud Run.
Scaling: Designed to scale horizontally. Since it operates entirely in memory, it eliminates database bottlenecks during the high-intensity “shaking” phase of the game.

Core Components

The Stage View (The Visual Centerpiece) The Stage View is a retro-futuristic canvas inspired by 8-bit hacker culture and circuit board aesthetics.

The I/O Portal: A moving digital gateway acting as a 3D vanishing point.

loading-screen.fiware.app

The “Muggle March”: When a user launches a “Muggle” (a pixel-art character) from their phone, it appears on the big screen and marches toward the portal, shrinking in size to create a depth effect.

Dynamic QR Integration: The screen automatically generates a QR code so attendees can jump into the action instantly without typing a URL.

2. The Mobile Interface (Launch Control)
We wanted a “zero-install” experience. No App Store, just the browser.

Shake-to-Launch: Leveraging the HTML5 DeviceMotion API, users physically shake their phones to "throw" their character onto the big screen.
Anti-Gravity Feel: The integration with motion sensors provides a tactile, “anti-gravity” sensation as if the phone is pushing the character into the digital space.
Customization: Users can add a 25-character message that floats above their character, creating a real-time, anonymous chat-bubble parade.

Deployment & Scalability on Google Cloud
By using Google Cloud Run, we achieved a “Pay-as-you-go” model that is perfect for events. The application stays at zero cost until the event starts, then scales instantly as hundreds of attendees scan the QR code.

Become a Medium member
The container is bound to the $PORT environment variable, making it fully compatible with Cloud Run’s managed runtime.

Running it locally
If you want to experiment with this setup, you can run the Dockerized version in seconds:

Bash

Build the lightweight Alpine image

docker build -t loading-screen .

Run the container

docker run -d -p 8080:8080 -e PORT=8080 --name loading-screen-app loading-screen

Lessons Learned
Building The Loading Screen taught us that:

State is the Enemy of Scale: Keeping the app in-memory and stateless allowed us to handle connections without worrying about DB latency.

Permissions Matter: Modern mobile browsers (especially iOS 13+) require explicit user consent for motion sensors. A “Ready to Launch” button is essential for the UX.

Visual Feedback is King: In a crowded room, seeing your specific character appear instantly on a 20-foot screen creates a powerful “wow” moment.

Check out the Project
The project is fully open-source. We encourage you to fork it, add new “Muggle” characters, or adapt it for your own tech meetups!

to probe:

loading-screen.fiware.app

Repository: https://github.com/mario-ezquerro/loading-screen
Keywords: #GoogleCloud #NodeJS #WebSockets #GameDev #CloudRun #Serverless