Fernando SRE

What if Kubernetes was the wrong tool for almost everyone?

It was 11 PM on a Tuesday, and for the third time that week, we were on an emergency call. Not because our product had a critical bug, but because a routine deployment had, once again, mysteriously broken the internal DNS. Three of our sharpest engineers weren’t creating value; they were offering sacrifices to the capricious god of Istio, hoping it might bless our pods with connectivity.

As I stared at the sprawling diagram we’d made just to add a single, simple microservice, a heretical thought wormed its way into my brain: When did our job stop being about building software and become about… well, serving Kubernetes?

A rumor we couldn’t ignore

The next morning, amidst our collective YAML-induced hangover, someone dropped a screenshot into our team’s Slack channel. It was from some tiny, no-name startup, claiming they were getting 8x the performance of a standard Kubernetes stack at one-tenth of the cost.

The team’s reaction was a collective, cynical laugh. “Sure,” our lead SRE typed, “and my home server can out-render Pixar.” It was obviously marketing fluff. Propaganda. The post itself was deleted within an hour, but the screenshot had already gone viral. It was absurd, unbelievable, and we all knew it was nonsense.

But the idea, like a catchy, terrible pop song, got stuck in our heads.

Let’s just prove it’s impossible

That Friday, we decided to do it. We’d run a small, contained experiment, mostly for the bragging rights of publicly debunking the ridiculous claim. The plan was simple: take one of our standard, moderately complex services and see what it would take to run it on a simpler stack.

Our service, an image processor, wasn’t a behemoth, but its YAML file had grown… organically. Like a colony of particularly stubborn mold. It had sidecars, persistent volume claims, readiness probes, and enough annotations to qualify as a short novel.

Here’s a sanitized glimpse of the beast we were trying to tame:

# apiVersion: apps/v1
# kind: Deployment
# metadata:
#   name: image-processor-svc
#   labels:
#     app: image-processor
# spec:
#   replicas: 3
#   selector:
#     matchLabels:
#       app: image-processor
#   template:
#     metadata:
#       labels:
#         app: image-processor
#     spec:
#       containers:
#       - name: processor
#         image: our-repo/image-processor:v1.2.4
#         ports:
#         - containerPort: 8080
#         resources:
#           requests:
#             memory: "512Mi"
#             cpu: "250m"
#           limits:
#             memory: "1024Mi"
#             cpu: "500m"
#         readinessProbe:
#           httpGet:
#             path: /healthz
#             port: 8080
#           initialDelaySeconds: 5
#           periodSeconds: 10
#       - name: metrics-sidecar
#         image: prom/statsd-exporter:v0.22.0
#         args:
#         - "--statsd.mapping-config=/etc/statsd/mapper.yml"
#         ports:
#         - name: metrics
#           containerPort: 9102
#         volumeMounts:
#         - name: config-volume
#           mountPath: /etc/statsd
#   # ...and so on, for another 150 lines.

We figured it would take us all afternoon just to untangle it.

The uncomfortable silence of success

We set up a competing stack using Firecracker MicroVMs, essentially tiny, lightning-fast virtual machines. The goal was to run the same container, but without the entire Kubernetes universe orbiting around it.

By 3 PM, we had our first results. And that’s when the room went quiet. It was the kind of uncomfortable silence you get when you realize the joke you’ve been telling for months is actually on you.

The numbers weren’t just holding up; they were embarrassing us. We stared at the Grafana dashboard, waiting for the figures to make sense. They didn’t. Our projected monthly cloud bill for this single service didn’t just shrink; it plummeted.

We had spent years building a complex, expensive, and fragile machine, all to solve a problem that, it turned out, could be handled with a much, much simpler approach.

Our quest for sane infrastructure

That weekend experiment turned into a full-blown obsession. Inspired, we started building our own internal escape hatch. We cobbled together a tool that we jokingly called the “SQL-ifier.” The premise was simple and, to a Kubernetes purist, utterly profane: what if you could manage infrastructure with simple, readable rules instead of YAML incantations?

Instead of a 200-line YAML file for an autoscaler, what if you could just write this?

-- This is our internal, SQL-like syntax for managing MicroVMs.
-- It's not a public standard (yet!).

-- Rule: If CPU usage on the frontend service is over 80% for 3 minutes,
-- add two more instances, but never exceed 20 total.
ON high_cpu(>80%) FOR 3m
IF service.name = 'image-processor-svc'
DO SCALE service.name TO instances + 2
LIMIT 20;

-- Rule: If we see more than 10 critical payment errors in 1 minute,
-- immediately revert to the last stable version.
ON log_error(level='critical', service='payment-gateway') > 10 FOR 1m
DO ROLLBACK service 'payment-gateway' TO previous_stable;

It was declarative, readable, and, most importantly, it could be understood by a human being without needing a certification.

How did we all end up here?

This journey forced us to ask a bigger question. Why did we, and thousands of other smart teams, willingly chain ourselves to this complexity?

The answer is surprisingly human. We bought an 18-wheeler truck to do our weekly grocery shopping.

Sure, a giant truck can carry milk and eggs. But you spend most of your time finding a place to park it, paying for diesel, getting a special license to drive it, and explaining to your neighbors why you just flattened their mailbox. Kubernetes was built for Google-scale problems. Most of us run businesses that need the reliability of a Toyota Camry, not a fleet of space shuttles. We adopted the tool because everyone else did, mistaking its complexity for sophistication.

Is your infrastructure serving you?

This whole experience led us to create a simple “mirror test.” If you’re wondering if you’re in the same boat, ask your team these questions:

Do you dread upgrading your cluster more than you dread a root canal?
Is a significant portion of your engineering time spent on “infra-babysitting” instead of building product features?
Could you confidently explain your service mesh configuration to a new hire without a whiteboard and a two-hour meeting?

If you answered “yes” to two or more, you might not have an infrastructure problem. You might have a Kubernetes problem.

This isn’t a manifesto to uninstall kubectl tomorrow. Some organizations genuinely operate at a scale where Kubernetes is not just useful, but necessary. This is just a friendly nudge. A reminder to look up from your YAML files once in a while and ask: is this tool still serving me, or have I started serving it?

The AWS bill shrank by 70%, but so did my DevOps dignity

Fourteen thousand dollars a month.

That number wasn’t on a spreadsheet for a new car or a down payment on a house. It was the line item from our AWS bill simply labeled “API Gateway.” It stared back at me from the screen, judging my life choices. For $14,000, you could hire a small team of actual gateway guards, probably with very cool sunglasses and earpieces. All we had was a service. An expensive, silent, and, as we would soon learn, incredibly competent service.

This is the story of how we, in a fit of brilliant financial engineering, decided to fire our expensive digital bouncer and replace it with what we thought was a cheaper, more efficient swinging saloon door. It’s a tale of triumph, disaster, sleepless nights, and the hard-won lesson that sometimes, the most expensive feature is the one you don’t realize you’re using until it’s gone.

Our grand cost-saving gamble

Every DevOps engineer has had this moment. You’re scrolling through the AWS Cost Explorer, and you spot it: a service that’s drinking your budget like it’s happy hour. For us, API Gateway was that service. Its pricing model felt… punitive. You pay per request, and you pay for the data that flows through it. It’s like paying a toll for every car and then an extra fee based on the weight of the passengers.

Then, we saw the alternative: the Application Load Balancer (ALB). The ALB was the cool, laid-back cousin. Its pricing was simple, based on capacity units. It was like paying a flat fee for an all-you-can-eat buffet instead of by the gram.

The math was so seductive it felt like we were cheating the system.

We celebrated. We patted ourselves on the back. We had slain the beast of cloud waste! The migration was smooth. Response times even improved slightly, as an ALB adds less overhead than the feature-rich API Gateway. Our architecture was simpler. We had won.

Or so we thought.

When reality crashes the party

API Gateway isn’t just a toll booth. It’s a fortress gate with a built-in, military-grade security detail you get for free. It inspects IDs, pats down suspicious characters, and keeps a strict count of who comes and goes. When we swapped it for an ALB, we essentially replaced that fortress gate with a flimsy screen door. And then we were surprised when the bugs got in.

The trouble didn’t start with a bang. It started with a whisper.

Week 1: The first unwanted visitor. A script kiddie, probably bored in their parents’ basement, decided to poke our new, undefended endpoint with a classic SQL injection probe. It was the digital equivalent of someone jiggling the handle on your front door. With API Gateway, its built-in Web Application Firewall (WAF) would have spotted the malicious pattern and drop-kicked the request into the void before it ever reached our application. With the ALB, the request sailed right through. Our application code was robust enough to reject it, but the fact that it got to knock on the application’s door at all was a bad sign. We dismissed it. “An amateur,” we scoffed.

Week 3: The client who drank too much. A bug in a third-party client integration caused it to get stuck in a loop. A very, very fast loop. It began hammering one of our endpoints with 10,000 requests per second. The servers, bless their hearts, tried to keep up. Alarms started screaming. The on-call engineer, who was attempting to have a peaceful dinner, saw his phone light up like a Christmas tree. API Gateway’s built-in rate limiting would have calmly told the misbehaving client, “You’ve had enough, buddy. Come back later.” It would have throttled the requests automatically. We had to scramble, manually blocking the IP while the system groaned under the strain.

Week 6: The full-blown apocalypse. This was it. The big one. A proper Distributed Denial-of-Service (DDoS) attack. It wasn’t sophisticated, just a tidal wave of garbage traffic from thousands of hijacked machines. Our ALB, true to its name, diligently balanced this flood of garbage across all our servers, ensuring that every single one of them was completely overwhelmed in a perfectly distributed fashion. The site went down. Hard.

The next 72 hours were a blur of caffeine, panicked Slack messages, and emergency calls with our new best friends at Cloudflare. We had saved $9,800 on our monthly bill, but we were now paying for it with our sanity and our customers’ trust.

Waking up to the real tradeoff

The hidden cost wasn’t just the emergency WAF setup or the premium support plan. It was the engineering hours. The all-nighters. The “I’m so sorry, it won’t happen again” emails to customers.

We had made a classic mistake. We looked at API Gateway’s price tag and saw a cost. We should have seen an itemized receipt for services rendered:

Built-in WAF: Free bouncer that stops common attacks.
Rate Limiting: A Free bartender who cuts off rowdy clients.
Request Validation: Free doorman that checks for malformed IDs (JSON).
Authorization: Free security guard that validates credentials (JWTs/OAuth).

An ALB does none of this. It just balances the load. That’s its only job. Expecting it to handle security is like expecting the mailman to guard your house. It’s not what he’s paid for.

Building a smarter hybrid fortress

After the fires were out and we’d all had a chance to sleep, we didn’t just switch back. That would have been too easy (and an admission of complete defeat). We came back wiser, like battle-hardened veterans of the cloud wars. We realized that not all traffic is created equal.

We landed on a hybrid solution, the architectural equivalent of having both a friendly greeter and a heavily-armed guard.

1. Let the ALB handle the easy stuff. For high-volume, low-risk traffic like serving images or tracking pixels, the ALB is perfect. It’s cheap, fast, and the security risk is minimal. Here’s how we route the “dumb” traffic in serverless.yml:

# serverless.yml
functions:
  handleMedia:
    handler: handler.alb  # A simple handler for media
    events:
      - alb:
          listenerArn: arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-main-alb/a1b2c3d4e5f6a7b8
          priority: 100
          conditions:
            path: /media/*  # Any request for images, videos, etc.

2. Protect the crown jewels with API Gateway. For anything critical, user authentication, data processing, and payment endpoints, we put it back behind the fortress of API Gateway. The extra cost is a small price to pay for peace of mind.

# serverless.yml
functions:
  handleSecureData:
    handler: handler.auth  # A handler with business logic
    events:
      - httpApi:
          path: /secure/v2/{proxy+}
          method: any

3. Add the security we should have had all along. This was non-negotiable. We layered on security like a paranoid onion.

AWS WAF on the ALB: We now pay for a WAF to protect our “dumb” endpoints. It’s an extra cost, but cheaper than an outage.
Cloudflare: Sits in front of everything, providing world-class DDoS protection.
Custom Rate Limiting: For nuanced cases, we built our own rate limiter. A Lambda function checks a Redis cache to track request counts from specific IPs or API keys.

Here’s a conceptual Python snippet for what that Lambda might look like:

# A simplified Lambda function for rate limiting with Redis
import redis
import os

# Connect to Redis
redis_client = redis.Redis(
    host=os.environ['REDIS_HOST'], 
    port=6379, 
    db=0
)

RATE_LIMIT_THRESHOLD = 100  # requests
TIME_WINDOW_SECONDS = 60    # per minute

def lambda_handler(event, context):
    # Get an identifier, e.g., from the source IP or an API key
    client_key = event['requestContext']['identity']['sourceIp']
    
    # Increment the count for this key
    current_count = redis_client.incr(client_key)
    
    # If it's a new key, set an expiration time
    if current_count == 1:
        redis_client.expire(client_key, TIME_WINDOW_SECONDS)
    
    # Check if the limit is exceeded
    if current_count > RATE_LIMIT_THRESHOLD:
        # Return a "429 Too Many Requests" error
        return {
            "statusCode": 429,
            "body": "Rate limit exceeded. Please try again later."
        }
    
    # Otherwise, allow the request to proceed to the application
    return {
        "statusCode": 200, 
        "body": "Request allowed"
    }

The final scorecard

So, after all that drama, was it worth it? Let’s look at the final numbers.

Verdict: For us, yes, it was ultimately worth it. Our traffic profile justified the complexity. But we traded money for time and complexity. We saved cash on the AWS bill, but the initial investment in engineering hours was massive. My DevOps dignity took a hit, but it has since recovered, scarred but wiser.

Your personal sanity check

Before you follow in our footsteps, do yourself a favor and perform an audit. Don’t let a shiny, low price tag lure you onto the rocks.

1. Calculate your break-even point. First, figure out what API Gateway is costing you.

# Get your usage data from API Gateway 
aws apigateway get-usage \ --usage-plan-id your_plan_id_here \ 
   --start-date 2024-01-01 
   --end-date 2024-01-31 \ 
   --query 'items'

Then, estimate your ALB costs based on request volume.

# Get request count to estimate ALB costs
aws cloudwatch get-metric-statistics \
    --namespace AWS/ApplicationELB \
    --metric-name RequestCount \
    --dimensions Name=LoadBalancer,Value=app/my-main-alb/a1b2c3d4e5f6a7b8 \
    --start-time 2024-01-01T00:00:00Z \
    --end-time 2024-01-31T23:59:59Z \
    --period 86400 \
    --statistics Sum

2. Test your defenses (or lack thereof). Don’t wait for a real attack. Simulate one. Tools like Burp Suite or sqlmap can show you just how exposed you are.

# A simple sqlmap test against a vulnerable parameter 
sqlmap -u "https://api.yoursite.com/endpoint?id=1" --batch

If you switch to an ALB without a WAF, you might be horrified by what you find.

In the end, choosing between API Gateway and an ALB isn’t just a technical decision. It’s a business decision about risk, and one that goes far beyond the monthly bill. It’s about calculating the true Total Cost of Ownership (TCO), where the “O” includes your engineers’ time, your customers’ trust, and your sleep schedule. Are you paying with dollars on an invoice, or are you paying with 3 AM incident calls and the slow erosion of your team’s morale?

Peace of mind has a price tag. For us, we discovered its value was around $7,700 a month. We just had to get DDoS’d to learn how to read the receipt. Don’t make the same mistake. Look at your architecture not just for what it costs, but for what it protects. Because the cheapest option on paper can quickly become the most expensive one in reality.

July 27, 2025 by Fernando SRE Cloud stuff DevOps stuff SRE stuff

Hybrid Cloud vs Multicloud which strategy is right for you

Cloud computing has been a game-changer, enabling businesses to scale, innovate, and deliver services at a pace once thought impossible. Most companies begin their journey with a single public cloud provider, which serves them well initially. But as a business grows and its needs become more complex, that single-cloud environment often starts to feel restrictive. The one-size-fits-all solution no longer fits.

This is the point at which organizations reach a critical crossroads. The path forward splits, leading toward two powerful strategies that promise greater flexibility, resilience, and freedom: Hybrid Cloud and Multicloud. Let’s unpack these two popular approaches to help you decide which journey is right for you.

When one Cloud is no longer enough

Before diving into definitions, it’s important to understand why businesses are looking beyond a single provider. This isn’t a trend driven by technology for technology’s sake; it’s a strategic evolution fueled by practical business needs.

The core drivers are often a desire for more control over sensitive data, the need to avoid being locked into a single vendor’s ecosystem, and the goal of building a more resilient infrastructure that can withstand outages. As your organization’s digital footprint expands, relying on one provider can feel like putting all your eggs in one basket, a risky proposition in today’s fast-paced digital economy.

Understanding your two main options

Once you’ve decided to expand your cloud strategy, you’ll encounter two primary models. While they sound similar, they solve different problems.

A Hybrid Cloud approach is like having a custom-built workshop at home for your most specialized, delicate work, while also renting a massive, fully-equipped industrial space for heavy-duty production. It’s a mixed computing environment that combines a private cloud (usually on-premises infrastructure you own and manage) with at least one public cloud (like AWS, Azure, or Google Cloud). The two environments are designed to work together, connected by technology that allows data and applications to be shared between them.

A Multicloud strategy, on the other hand, is like deciding to source ingredients for a gourmet meal from different specialty stores. You buy your bread from the best artisan bakery, your cheese from a dedicated fromagerie, and your vegetables from the local farmer’s market. This approach involves using services from multiple public cloud providers at the same time. The key difference is that these cloud environments don’t necessarily need to be integrated. You simply pick and choose the best service from each provider for a specific task.

The hybrid approach is a blend of control and scale

Opting for a hybrid model gives an organization a unique balance of ownership and outsourced power. It’s a popular choice for good reason, offering several distinct advantages.

Flexibility in workload placement

Hybrid setups allow you to run applications and store data in the most suitable location. For example, you can keep your highly sensitive customer database on your private, on-premises servers to meet strict compliance rules, while running your customer-facing web application in the public cloud to handle unpredictable traffic spikes. This ability to “burst” workloads into the public cloud during peak demand is a classic and powerful use case.

Regulatory compliance and security

For industries like finance, healthcare, and government, data sovereignty and privacy regulations (like GDPR or HIPAA) are non-negotiable. A hybrid cloud allows you to keep your most sensitive data within your own four walls, giving you complete control and making it easier to pass security audits. It’s the digital equivalent of keeping your most important documents in a personal safe rather than a rented storage unit.

Enhanced resilience

A well-designed hybrid model offers a robust disaster recovery solution. If your local infrastructure experiences an issue, you can failover critical operations to your public cloud provider, ensuring business continuity with minimal disruption.

However, this approach isn’t without its challenges. Managing and securing two distinct environments requires a more complex operational model and a skilled IT team. Building the “bridge” between the private and public clouds requires careful planning and the right tools to ensure seamless and secure communication.

The multicloud path to freedom and specialization

A multicloud strategy is fundamentally about choice and avoiding dependency. It’s for organizations that want to leverage the unique strengths of different providers without being tied to a single one.

Avoiding vendor lock-in

Dependency on a single provider can be risky. Prices can rise, service quality can decline, or the vendor’s strategic direction might no longer align with yours. Multicloud mitigates this risk. It’s like diversifying your financial investments instead of putting all your money into one stock. This freedom gives you negotiating power and the agility to adapt to market changes.

Access to best-of-breed services

Each cloud provider excels in different areas. AWS is renowned for its mature and extensive set of services, Google Cloud is a leader in data analytics and machine learning, and Azure offers seamless integration with Microsoft’s enterprise software ecosystem. A multicloud strategy allows you to use Google’s AI tools for one project, Azure’s Active Directory for identity management, and AWS’s S3 for robust storage, all at the same time.

Improved global scalability

For businesses with a global user base, multicloud enables you to choose providers that have a strong presence in specific geographic regions. This can reduce latency and improve performance for your customers, while also helping you comply with local data residency laws.

The primary challenge of multicloud is managing the complexity. Each cloud has its own set of APIs, management tools, and security models. Without a unified management platform, your teams could find themselves juggling multiple control panels, leading to operational inefficiencies and potential security gaps. Cost management can also become tricky, requiring careful monitoring to avoid budget overruns.

How to chart your Cloud course

So, how do you decide which path to take? The right choice depends entirely on your organization’s specific circumstances. There is no single “best” answer. Ask yourself these key questions:

What are our business and regulatory needs? Do you handle data that is subject to strict residency or compliance laws? If so, a hybrid approach might be necessary to keep that data on-premises.
How do our legacy systems fit in? If you have significant investments in on-premises hardware or critical legacy applications that are difficult to move, a hybrid strategy can provide a bridge to the cloud without requiring a complete overhaul.
What is our team’s technical maturity? Is your team ready to handle the operational complexity of managing multiple cloud environments? A multicloud strategy requires a higher level of technical expertise and often relies on automation tools like Terraform or orchestration platforms like Kubernetes to be successful.

The road ahead

The lines between hybrid and multicloud are blurring. The future will see these strategies intersect even more with emerging technologies like AI-driven automation, which will simplify management, and edge computing, which will bring processing power even closer to where data is generated.

Ultimately, navigating your cloud journey isn’t about picking a predefined label. It’s about thoughtfully designing a strategy that aligns perfectly with your organization’s unique goals. By clearly understanding the strengths and challenges of each approach, you can build a cloud infrastructure that is strategic, efficient, and ready for the future.

July 15, 2025 by Fernando SRE Cloud stuff DevOps stuff

The case of the missing EC2 public IP

It was a Tuesday. I did what I’ve done a thousand times: I logged into an Amazon EC2 instance using its public IP, a respectable 52.95.110.21. Routine stuff. Once inside, muscle memory took over, and I typed ip addr to see the network configuration.

And then I blinked.

inet 10.0.10.147/24.

I checked my terminal history. Yes, I had connected to 52.95.110.21. So, where did this 10.0.10.147 character come from? And more importantly, where on earth was the public IP I had just used? For a moment, I felt like a detective at a crime scene where the main evidence had vanished into thin air. I questioned my sanity, my career choice, and the very fabric of the TCP/IP stack.

Suppose you’ve ever felt this flicker of confusion, congratulations. You’ve just stumbled upon one of AWS’s most elegant sleights of hand. The truth is, the public IP doesn’t exist inside the instance. It’s a ghost. A label. A brilliant illusion.

Let’s put on our detective hats and solve this mystery.

Meet the real resident

Every EC2 instance, upon its creation, is handed a private IP address. Please think of this as its legal name, the one on its birth certificate. It’s the address it uses to talk to its neighbors within its cozy, gated community, the Virtual Private Cloud (VPC). This instance, 10.0.10.147, is perfectly happy using this address to get a cup of sugar from the database next door at 10.0.10.200. It’s private, it’s intimate, and frankly, it’s nobody else’s business.

The operating system itself, be it Ubuntu, Amazon Linux, or Windows, is blissfully unaware of any other identity. As far as it’s concerned, its name is 10.0.10.147, and that’s the end of the story. If you check its network configuration, that’s the only IP you’ll see.

# Check the network interface, see only the private IP
$ ip -4 addr show dev eth0 | grep inet
    inet 10.0.10.147/24 brd 10.0.10.255 scope global dynamic eth0

So, if the instance only knows its private name, how does it have a public life on the internet?

The master of disguise

The magic happens outside the instance, at the edge of your VPC. Think of the AWS Internet Gateway as a ridiculously efficient bouncer at an exclusive club. Your instance, wanting to go online, walks up to the bouncer and whispers, “Hey, I’m 10.0.10.147 And I need to fetch a cat picture from the internet.“

The bouncer nods, turns to the vast, chaotic world of the internet, and shouts, “HEY, TRAFFIC FOR 52.95.110.21, COME THIS WAY!”

This translation trick is called 1-to-1 Network Address Translation (NAT). The Internet Gateway maintains a secret map that links the public IP to the private IP. The public IP is just a mask, a public-facing persona. It never actually gets assigned to the instance’s network interface. It’s all handled by AWS behind the scenes, a performance so smooth you never even knew it was happening.

When your instance sends traffic out, the bouncer (Internet Gateway) swaps the private source IP for the public one. When return traffic comes back, the bouncer swaps it back. The instance is none the wiser. It lives its entire life thinking its name is 10.0.10.147, completely oblivious to its international fame as 52.95.110.21.

Interrogating the local gossip

So, the instance is clueless. But what if we, while inside, need to know its public identity? What if we need to confirm our instance’s public IP for a firewall rule somewhere else? We can’t just ask the operating system.

Fortunately, AWS provides a nosy neighbor for just this purpose: the Instance Metadata Service. This is a special, link-local address (169.254.169.254) that an instance can query to learn things about itself, things the operating system doesn’t know. It’s the local gossip line.

To get the public IP, you first have to get a temporary security token (because even gossip has standards these days), and then you can ask your question.

# First, grab a session token. This is good for 6 hours (21600 seconds).
$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Now, use the token to ask for the public IP
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-ipv4
52.95.110.21

And there it is. The ghost in the machine, confirmed.

A detective’s field guide

Now that you’re in on the secret, you can avoid getting duped. Here are a few field notes to keep in your detective’s journal.

The clueless security guard. If you’re configuring a firewall inside your instance (like iptables or UFW), remember that it only knows the instance by its private IP. Don’t try to create a rule for your public IP; the firewall will just stare at you blankly. Always use the private IP for internal security configurations.

The persistent twin: What if you need a public IP that doesn’t change every time you stop and start your instance? That’s what an Elastic IP (EIP) is for. But don’t be fooled. An EIP is just a permanent public IP that you own. Behind the scenes, it works the same way: it’s a persistent mask mapped via NAT to your instance’s private IP. The instance remains just as gloriously ignorant as before.

The vanishing act. If you’re not using an Elastic IP, your instance’s public IP is ephemeral. It’s more like a hotel room number than a home address. Stop the instance, and it gives up the IP. Start it again, and it gets a brand new one. This is a classic “gotcha” that has broken countless DNS records and firewall rules.

The case is closed

So, the next time you log into an EC2 instance and see a private IP, don’t panic. You haven’t SSH’d into your smart fridge by mistake. You’re simply seeing the instance for who it truly is. The public IP was never missing; it was just a clever disguise, an elegant illusion managed by AWS so your instance can have a public life without ever having to deal with the paparazzi. The heavy lifting is done for you, leaving your instance to worry about more important things. Like serving those cat pictures.

July 12, 2025 by Fernando SRE Cloud stuff

How Headless services and StatefulSets work together in Kubernetes

Kubernetes is an open-source platform designed to seamlessly manage containerized applications. Imagine the manager at your favorite café coordinating baristas, chefs, and servers effortlessly, ensuring a smooth customer experience every single time. Kubernetes automates deployments, scaling, and operations, making it indispensable for today’s complex digital landscape.

Understanding headless services

At first glance, Headless Services might seem unusual, yet they’re essential Kubernetes components. Regular Kubernetes Services act as receptionists routing your calls; Headless Services, however, skip the receptionist altogether and connect you directly to individual pods via their unique IP addresses.

Consider them as a neighborhood directory listing direct phone numbers, eliminating the central switchboard. This direct approach is particularly beneficial when individual pod identity and communication are critical, such as with database clusters.

Example YAML for a headless service:

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
  - port: 80

Demystifying StatefulSets

StatefulSets uniquely manage stateful applications by assigning each pod a stable identity and persistent storage. Imagine a classroom where each student (pod) has an assigned desk (storage) that remains consistent, no matter how often they come and go.

Comparing StatefulSets and deployments

Deployments are ideal for stateless applications, where each instance is interchangeable and can be replaced without affecting the overall system. StatefulSets, however, excel with stateful applications, ensuring pods have stable identities and persistent storage, perfect for databases and message queues.

Example YAML for a StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-stateful-app
spec:
  serviceName: my-headless-service
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app-container
        image: my-app-image
        ports:
        - containerPort: 80
        volumeMounts:
        - name: my-volume
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: my-volume
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 1Gi

The strength of pairing headless services with StatefulSets

Headless Services and StatefulSets each have significant strengths independently, but they truly shine when combined. Headless Services provide stable network identities for StatefulSet pods, akin to each member of a specialized team having their direct communication line for efficient collaboration.

Picture an emergency medical team; direct lines enable doctors and nurses to coordinate rapidly and precisely during critical situations. Similarly, distributed databases such as Cassandra or MongoDB rely heavily on this direct communication model to maintain data consistency and reliability.

Practical use-case

Consider a Cassandra database running on Kubernetes. StatefulSets ensure each Cassandra node has dedicated data storage and a unique identity. With Headless Services, these nodes communicate directly, consistently synchronizing data and ensuring seamless accessibility, irrespective of which node handles the incoming requests.

Concluding insights

Headless Services combined with StatefulSets form a powerful solution for managing stateful applications within Kubernetes. They address distinct challenges in state management and network stability, ensuring reliability and scalability for your applications.

Leveraging these Kubernetes capabilities equips your infrastructure for success, akin to empowering each team member with the necessary tools for clear communication and consistent performance. Embrace this dynamic duo for a more robust and efficient Kubernetes environment.

July 9, 2025 by Fernando SRE Cloud stuff DevOps stuff Kubernetes SRE stuff

Choosing your message queue AWS SQS or GCP Pub/Sub

In the world of modern software, applications are rarely monolithic islands. Instead, they are bustling cities of interconnected services, each performing a specific job. For this city to function smoothly, its inhabitants, microservices, functions, and components need a reliable way to communicate without being directly tethered to one another. This is where message brokers come in, acting as the city’s postal service, ensuring that messages are delivered efficiently and reliably.

Two of the most prominent cloud-based postal services are Amazon Web Services’ Simple Queue Service (SQS) and Google Cloud’s Pub/Sub. Both are exceptional at what they do, but they operate on different philosophies. Understanding their unique characteristics is crucial for any cloud architect or DevOps engineer aiming to build robust, scalable, and event-driven systems. This guide will explore their differences to help you choose the right service for your application’s needs.

A quick look at our contenders

Before we examine the details, let’s get a general feel for each service.

AWS SQS is the seasoned veteran of message queuing. Think of it as a highly organized system of mailboxes. A service writes a letter (a message) and places it into a specific mailbox (a queue). The recipient service then comes to that mailbox and picks up its mail when it has the capacity to process it. It’s a straightforward, incredibly reliable system that has been battle-tested for years.

GCP Pub/Sub operates more like a global newspaper subscription. A publisher (your service) doesn’t send a message to a specific recipient. Instead, it publishes a message to a “topic,” like a news flash for the “user-signup” channel. Any service that has subscribed to that topic instantly receives a copy of the message. It’s designed for broad, real-time distribution of information on a global scale.

The delivery dilemma Push versus Pull

The most fundamental difference between SQS and Pub/Sub lies in how messages are delivered. This is often referred to as the “push vs. pull” model.

The pull model, which is SQS’s native approach, is like checking your P.O. box. The consumer application is responsible for periodically asking the queue, “Is there any mail for me?” This gives the consumer complete control over the rate of consumption. If it’s overwhelmed with work, it can slow down its requests or stop asking for new messages altogether. This is ideal for batch processing or any workload where you need to manage the processing pace carefully.

The push model, where Pub/Sub shines, is akin to home mail delivery. When a message is published, Pub/Sub actively “pushes” it to all subscribed endpoints, such as a serverless function or a webhook. The recipient doesn’t have to ask; the message just arrives. This is incredibly efficient for real-time notifications and event-driven workflows where immediate reaction is key. While Pub/Sub also supports a pull model, its architecture is optimized for push-based delivery.

Comparing key features

Let’s break down how these two services stack up in a few critical areas.

Message ordering

Sometimes, the sequence of events is just as important as the events themselves. For these cases, AWS SQS offers a specific FIFO (First-In, First-Out) queue type. This works exactly like a single-file line at a bank; the first person to get in line is the first one to be served. It provides a strict guarantee that messages will be processed in the exact order they were sent, which is critical for tasks like processing financial transactions or application logs.

GCP Pub/Sub, in contrast, does not have a dedicated FIFO queue type. Instead, it achieves partial ordering through the use of ordering keys. You can assign a key to messages (for example, a userId), and Pub/Sub will ensure that all messages with that specific key are delivered in order. However, it doesn’t guarantee order between different keys. To reuse the analogy, it’s less like a single line and more like a deli with separate ticket numbers for the butcher and the bakery. It keeps orders straight within each department, but not across the entire store.

Scale and reach

This is where their architectural differences become clear. SQS is a regional service. It’s incredibly scalable and resilient, but its scope is confined to a single AWS region.

Pub/Sub is inherently global. You publish a message once, and it can be delivered to subscribers in any region around the world with low latency. If your application has a global user base and you need to propagate events worldwide, Pub/Sub has a distinct advantage.

Message size and retention

Think of SQS as being for postcards and letters. It supports messages up to 256 KB. It can hold onto these messages for up to 14 days, giving your consumers plenty of time to process them.

Pub/Sub, on the other hand, can handle larger packages, with a maximum message size of 10 MB. However, its standard retention period is shorter, at 7 days.

Special delivery options

SQS has a native feature called Delay Queues. This allows you to postpone the delivery of a new message for up to 15 minutes. It’s like writing a post-dated check; the message sits in the queue but is invisible to consumers until the timer expires. This is useful for scheduling tasks without a complex scheduling service. Pub/Sub does not offer a similar built-in feature.

When to choose AWS SQS

SQS is your go-to choice when you need a dependable, orderly mailroom for your application. It excels in scenarios where:

Strict ordering is non-negotiable. For task sequencing or financial ledgers, SQS FIFO is the gold standard.
You need to control the pace of consumption. The pull model is perfect for decoupling a fast producer from a slower consumer or for batch processing jobs.
Task scheduling is required. The native delay queue feature is a simple yet powerful tool.
Your application’s architecture is primarily contained within a single AWS region.

When to choose GCP Pub/Sub

Pub/Sub is the right tool when you’re building a global broadcasting system or a highly reactive, event-driven platform. Consider it when:

You need to fan-out messages to many consumers. Pub/Sub’s topic-and-subscription model is designed for this.
Global distribution with low latency is a priority. Its global nature is a massive benefit for distributed systems.
You are sending large messages. The 10 MB limit offers much more flexibility than SQS.
A push-based model fits your architecture. It integrates seamlessly with serverless functions for instant, event-triggered execution.

A final word

So, after all this technical deliberation, which digital courier should you entrust with your precious data packets? The one that meticulously forms a single, orderly queue, or the one that shouts your message through a global megaphone to anyone who will listen?

The truth is, there’s no single “best” service. There’s only the one whose particular brand of crazy best matches your application’s personality. Is your app a stickler for the rules, demanding every event be processed in perfect sequence, lest it have a digital panic attack? Then the quiet, predictable, and slightly obsessive SQS is your soulmate. Or is your app more of a drama queen, needing to announce every minor update to the entire world, immediately? Then the boisterous, globe-trotting Pub/Sub is probably already sliding into your DMs.

Ultimately, the best way to choose is to put them to the test. Think of it as a job interview. Give them both a trial run with your actual workload and see which one handles the pressure with more grace, or at least breaks in a more interesting, less catastrophic way. Go on, do it for science. And for the future sanity of your on-call engineer.

July 6, 2025 by Fernando SRE Cloud stuff

An irreverent tour of Linux disk space and RAM mysteries

Linux feels a lot like living in a loft apartment: the pipes are on display, every clank echoes, and when something leaks, you’re the first to squelch through the puddle. This guide hands you a mop, half a dozen snappy commands that expose where your disk space and memory have wandered off to, plus a couple of click‑friendly detours. Expect prose that winks, occasionally rolls its eyes, and never ever sounds like tax law.

Why checking disk and memory matters

Think of storage and RAM as the pantry and fridge in a shared flat. Ignore them for a week, and you end up with three half‑finished jars of salsa (log files) and leftovers from roommates long gone (orphaned kernels). A five‑minute audit every Friday spares you the frantic sprint for extra space, or worse, the freeze just before a production deploy.

Disk panic survival kit

Get the big picture fast

df is the bird’s‑eye drone shot of your mounted filesystems, everything lines up like contestants at a weigh‑in.

# Exclude temporary filesystems for clarity
$ df -hT -x tmpfs -x devtmpfs

-h prints friendly sizes, -T shows filesystem type, and the two -x flags hide the short‑lived stuff.

Zoom in on space hogs

du is your tape measure. Pair it with a little sort and head for instant gossip about the top offenders in any directory:

# Top 10 fattest directories under /var
$ sudo du -h --max-depth=1 /var 2>/dev/null | sort -hr | head -n 10

If /var/log looks like it skipped leg day and went straight for bulking season, you’ve found the culprit.

Bring in the interactive detective

When scrolling text gets dull, ncdu adds caffeine and colour:

# Install on most Debian‑based distros
$ sudo apt install ncdu

# Start at root (may take a minute)
$ sudo ncdu /

Navigate with the arrow keys, press d to delete, and feel the instant gratification of reclaiming gigabytes, the Marie Kondo of storage.

Visualise block devices

# Tree view of drives, partitions, and mount points
$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT --tree

Handy when that phantom 8 GB USB stick from last week still lurks in /media like an uninvited houseguest.

Memory and swap reality check

Check the ledger

The free command is a quick wallet peek, straightforward, and slightly judgemental:

$ free -h

Focus on the available column; that’s what you can still spend without the kernel reaching for its credit card (a.k.a. swap).

Real‑Time spy cam

# Refresh every two seconds, ordered by RAM gluttons
$ top -o %MEM

Prefer your monitoring colourful and charming? Try htop:

$ sudo apt install htop
$ htop

Use F6 to sort by RES (resident memory) and watch your browser tabs duke it out for supremacy.

Meet RAM’s couch‑surfing cousin

Swap steps in when RAM is full, think of it as sleeping on the living‑room sofa: doable, but slow and slightly undignified.

# Show active swap files or partitions
$ swapon --show

Seeing swap above 20 % during regular use? Either add RAM or conjure an emergency swap file:

$ sudo fallocate -l 2G /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile

Remember to append it to /etc/fstab so it survives a reboot.

Prefer clicking to typing

Yes, there’s a GUI for that. GNOME Disks and KSysGuard both display live graphs and won’t judge your typos. On Ubuntu, you can run:

$ sudo apt install gnome-disk-utility

Launch it from the menu and watch I/O spikes climb like toddlers on a sugar rush.

Quick reference cheat sheet

Show all mounts minus temp stuff
Command: df -hT -x tmpfs -x devtmpfs
Memory aid: df = disk fly‑over
Top ten heaviest directories
Command: du -h –max-depth=1 /path | sort -hr | head
Memory aid: du = directory weight
Interactive cleanup
Command: ncdu /
Memory aid: ncdu = du after espresso
Live RAM counter
Command: free -h
Memory aid: free = funds left
Spot memory‑hogging apps
Command: top -o %MEM
Memory aid: top = talent show
Swap usage
Command: swapon –show
Memory aid: swap on stage

Stick this list on your clipboard; your future self will thank you.

Wrapping up without a bow

You now own the detective kit for disk and memory mysteries, no cosmic metaphors, just straight talk with a wink. Run df -hT right now; if the numbers give you heartburn, take three deep breaths and start paging through ncdu. Storage leaks and RAM gluttons are inevitable, but letting them linger is optional.

Found an even better one‑liner? Drop it in the comments and make the rest of us look lazy. Until then, happy sleuthing, and may your logs stay trim and your swap forever bored.

July 4, 2025 by Fernando SRE DevOps stuff Linux Stuff SRE stuff

Edge computing reshapes DevOps for the real-time era

A new frontier at your doorstep

When Amazon started placing delivery lockers in neighborhoods, packages arrived faster and more reliably. Edge computing follows a similar logic, bringing computational power closer to the user. Instead of sending data halfway around the world, edge computing processes it locally, dramatically reducing latency, enhancing privacy, and maintaining autonomy.

For DevOps teams, this shift isn’t trivial. Like switching from central mail hubs to neighborhood lockers, it demands new strategies and skills.

CI/CD faces a new reality

Classic cloud pipelines are centralized, much like a single distribution center. Edge computing flips that model upside-down, scattering deployments across numerous tiny locations. Deploying updates to thousands of edge devices isn’t the same as updating a handful of cloud servers.

DevOps teams now battle version drift, a scenario similar to managing software on thousands of smartphones with different versions. The solutions? Smaller, incremental updates and lightweight build artifacts, ensuring that pushing changes doesn’t overwhelm limited network bandwidth or hardware resources.

Designing for when things go dark

Planning a family dinner knowing there’s a possibility of a power outage means stocking up on candles and sandwiches. Similarly, edge devices must be designed for disconnection, ensuring operations continue uninterrupted during network downtime.

Offline-first architectures become critical here. Techniques like local queuing and eventual data reconciliation help edge applications function seamlessly, even if connectivity is lost for hours or days. Managing schema migrations carefully is crucial; it’s akin to updating recipes without knowing if family members received the memo.

Keeping data consistently in sync

Imagine organizing a city-wide neighborhood watch: push notifications ensure quick alerts, while pull mechanisms periodically fetch updates. Edge deployments use similar synchronization tactics.

Techniques such as Conflict-Free Replicated Data Types (CRDTs) help manage data consistency, even when devices are offline or slow to respond. DevOps engineers also need to factor in bandwidth budgeting, using intelligent compression and prioritizing data to ensure crucial information reaches its destination promptly.

Observability without seeing everything

Monitoring edge deployments is like managing a fleet of food trucks spread across the city. You can’t constantly keep an eye on every truck. Instead, you rely on periodic check-ins and key signals.

Telemetry sampling, data aggregation at the edge, and effective back-pressure management prevent network floods. Selecting a few meaningful metrics, like checking a truck’s gas gauge rather than tracking every sandwich sold, helps quickly pinpoint issues without drowning in data.

Incident response across the edge

Responding to issues at thousands of remote locations is challenging, like troubleshooting vending machines scattered nationwide without direct access.

Edge incident response leverages runbook templates, policy-as-code, and remote diagnostics tools. Because traditional SSH access isn’t always viable, tactics like automated self-healing and structured escalation paths blending central SRE teams with local staff become indispensable.

Bridging cloud and edge

Integrating IoT devices into your infrastructure is similar to securely registering visitors at a large event, you need clear identification, managed credentials, and accurate headcounts.

Edge computing uses secure onboarding, rotating credentials, and message brokers that maintain state coherence across the network. Digital twins represent device states virtually, helping maintain consistent and accurate information between edge and cloud environments. Cost-effective strategies determine whether workloads run locally or in centralized clouds.

Preparing for what’s next

Edge computing evolves rapidly, with emerging standards like WebAssembly (WASM) running applications directly at the edge, and maturing tools like OpenTelemetry simplifying observability.

DevOps teams should embrace these changes early. Developing skills in hardware awareness and basic radio frequency (RF) knowledge becomes increasingly valuable. Experimenting now, rigorously measuring results, and sharing insights ensures teams stay ahead.

Innovate and adapt for the road ahead

Edge computing is reshaping DevOps in real-time. Thriving in this era requires adapting practices, tooling, and mindset. Bring your computational lockers closer to home, plan proactively for network disruptions, streamline synchronization, enhance remote observability, and respond intelligently to incidents.

By preparing today, your DevOps team can confidently navigate tomorrow’s distributed landscape. Embracing edge computing means more than just keeping pace with technology; it positions your team to deliver faster, more reliable services, capitalize on emerging business opportunities, and maintain a competitive advantage. Investing now in the right tools, processes, and skills not only safeguards against future challenges but also unlocks potential for innovation, growth, and sustained success in a rapidly evolving technological world.

In short, the future belongs to those who embrace change and adapt quickly; let your team be among them.

July 3, 2025 by Fernando SRE Cloud stuff DevOps stuff SRE stuff

Free that stuck Linux port and get on with your day

A rogue process squatting on port 8080 is the tech-equivalent of leaving your front-door key in the lock: nothing else gets in or out, and the neighbours start gossiping. Ports are exclusive party venues; one process per port, no exceptions. When an app crashes, restarts awkwardly, or you simply forget it’s still running, it grips that port like a toddler with the last cookie, triggering the dreaded “address already in use” error and freezing your deployment plans.

Below is a brisk, slightly irreverent field guide to evicting those squatters, gracefully when possible, forcefully when they ignore polite knocks, and automatically so you can get on with more interesting problems.

When ports act like gate crashers

Ports are finite. Your Linux box has 65535 of them, but every service worth its salt wants one of the “good seats” (80, 443, 5432…). Let a single zombie process linger, and you’ll be running deployment whack-a-mole all afternoon. Keeping ports free is therefore less superstition and more basic hygiene, like throwing out last night’s takeaway before the office starts to smell.

Spot the culprit

Before brandishing a digital axe, find out who is hogging the socket.

lsof, the bouncer with the clipboard

sudo lsof -Pn -iTCP:8080 -sTCP:LISTEN

lsof prints the PID, the user, and even whether our offender is IPv4 or IPv6. It’s as chatty as the security guard who tells you exactly which cousin tried to crash the wedding.

ss, the Formula 1 mechanic

Modern kernels prefer ss, it’s faster and less creaky than netstat.

sudo ss -lptn sport = :8080

fuser, the debt collector

When subtlety fails, fuser spells out which processes own the file or socket:

sudo fuser -v 8080/tcp

It displays the PID and the user, handy for blaming Dave from QA by name.

Tip: Add the -k flag to fuser to terminate offenders in one swoop, great for scripts, dangerous for fingers-on-keyboard humans.

Gentle persuasion first

A well-behaved process will exit graciously if you offer it a polite SIGTERM (15):

kill -15 3245     # give the app a chance to clean up

Think of it as tapping someone’s shoulder at closing time: “Finish your drink, mate.”

If it doesn’t listen, escalate to SIGINT (2), the Ctrl-C of signals, or SIGHUP (1) to make daemons reload configs without dying.

Bring out the big stick

Sometimes you need the digital equivalent of cutting the mains power. SIGKILL (9) is that guillotine:

kill -9 3245      # immediate, unsentimental termination

No cleanup, no goodbye note, just a corpse on the floor. Databases hate this, log files dislike it, and system-wide supervisors may auto-restart the process, so use sparingly.

One-liners for the impatient

sudo kill -9 $(sudo ss -lptn sport = :8080 | awk 'NR==2{split($NF,a,"pid=");split(a[2],b,",");print b[1]}')

Single line, single breath, done. It’s the Fast & Furious of port freeing, but remember: copy-paste speed correlates strongly with “oops-I-just-killed-production”.

Automate the cleanup

A pocket Bash script

#!/usr/bin/env bash
port=${1:-3000}
pid=$(ss -lptn "sport = :$port" | awk 'NR==2 {split($NF,a,"pid="); split(a[2],b,","); print b[1]}')

if [[ -n $pid ]]; then
  echo "Port $port is busy (PID $pid). Sending SIGTERM."
  kill -15 "$pid"
  sleep 2
  kill -0 "$pid" 2>/dev/null && echo "Still alive; escalating..." && kill -9 "$pid"
else
  echo "Port $port is already free."
fi

Drop it in ~/bin/freeport, mark executable, and call freeport 8080 before every dev run. Fewer keystrokes, fewer swearwords.

systemd, your tireless janitor

Create a watchdog service so the OS restarts your app only when it exits cleanly, not when you manually murder it:

[Unit]
Description=Watchdog for MyApp on 8080

[Service]
ExecStart=/usr/local/bin/myapp
Restart=on-failure
RestartPreventExitStatus=64   # don’t restart if we SIGKILLed

Enable with systemctl enable myapp.service, grab coffee, forget ports ever mattered.

Ansible for the herd

- name: Free port 8080 across dev boxes
  hosts: dev
  become: true
  tasks:
    - name: Terminate offender on 8080
      shell: |
        pid=$(ss -lptn 'sport = :8080' | awk 'NR==2{split($NF,a,"pid=");split(a[2],b,",");print b[1]}')
        [ -n "$pid" ] && kill -15 "$pid" || echo "Nothing to kill"

Run it before each CI deploy; your colleagues will assume you possess sorcery.

A few cautionary tales

Containers restart themselves. Kill a process inside Docker, and the orchestrator may spin it right back up. Either stop the container or adjust restart policies.
Dependency dominoes. Shooting a backend API can topple every microservice that chats to it. Check systemctl status or your Kubernetes liveness probes before opening fire .
Sudo isn’t seasoning. Use it only when the victim process belongs to another user. Over-salting scripts with sudo causes security heartburn.

Wrap-up

Freeing a port isn’t arcane black magic; it’s janitorial work that keeps your development velocity brisk and your ops team sane. Identify the squatter, ask it nicely to leave, evict it if it refuses, and automate the routine so you rarely have to think about it again. Got a port-conflict horror story involving 3 a.m. pager alerts and too much caffeine? Tell me in the comments, schadenfreude is a powerful teacher.

Now shut that laptop lid and actually get on with your day. The ports are free, and so are you.

June 28, 2025 by Fernando SRE DevOps stuff Linux Stuff SRE stuff

Why Kubernetes Ingress feels outdated and Gateway API is stepping up

Kubernetes has transformed container orchestration, rapidly pushing the boundaries of scalability and flexibility. Yet some core components haven’t evolved as gracefully. Kubernetes Ingress is a prime example; it’s beginning to feel like using an old flip phone when everyone else has moved on to smartphones.

What’s driving this shift away from the once-reliable Ingress, and why are more Kubernetes professionals turning to Gateway API?

The rise and limits of Kubernetes Ingress

When Kubernetes introduced Ingress, its appeal lay in its simplicity. Its job was straightforward: route HTTP and HTTPS traffic into Kubernetes clusters predictably. Like traffic lights at a busy intersection, it provided clear and reliable outcomes: set paths and hostnames, and your Ingress controller (NGINX, Traefik, or others) took care of the rest.

However, as Kubernetes workloads grew more complex, this simplicity became restrictive. Teams began seeking advanced capabilities such as canary deployments, complex traffic management, support for additional protocols, and finer control. Unfortunately, Ingress remained static, forcing teams to rely on cumbersome vendor-specific customizations.

Why Ingress now feels outdated

Ingress still performs adequately, but managing it becomes increasingly cumbersome as complexity rises. It’s comparable to owning a reliable but outdated vehicle; it gets you to your destination but lacks modern conveniences. Here’s why Ingress feels out-of-date:

Limited protocol support – Only HTTP and HTTPS are supported natively. If your applications require gRPC, TCP, or UDP, you’re out of luck.
Vendor lock-in with annotations – Advanced routing features and authentication mechanisms often require vendor-specific annotations, locking you into particular solutions.
Rigid permission models – Managing shared control across multiple teams is complicated and inefficient, similar to having a single TV remote for an entire household.
No evolutionary path – Ingress will remain stable but static, unable to evolve as the Kubernetes ecosystem demands greater flexibility.

Gateway API offers a modern alternative

Gateway API isn’t merely an upgraded Ingress; it’s a fundamental rethink of how Kubernetes handles external traffic. It cleanly separates roles and responsibilities, streamlining interactions between network administrators, platform teams, and developers. Think of it as a well-run restaurant: chefs, managers, and servers each have clear roles, ensuring smooth and efficient operation.

Additionally, Gateway API supports multiple protocols, including gRPC, TCP, and UDP, natively. This eliminates reliance on awkward annotations and vendor lock-in, resembling an upgrade from single-purpose appliances to versatile multi-function tools that adapt smoothly to emerging needs.

When Gateway API becomes essential

Gateway API won’t suit every situation, but specific scenarios benefit from its use. Consider these questions:

Do your applications require sophisticated traffic handling, like canary deployments or traffic mirroring?
Are your services utilizing protocols beyond HTTP and HTTPS?
Is your Kubernetes cluster shared among multiple teams, each needing distinct control?
Do you seek portability across cloud providers and wish to avoid vendor lock-in?
Do you often desire modern features that are unavailable through traditional Ingress?

Answering “yes” to any of these indicates that Gateway API isn’t just helpful, it’s essential.

Deciding to move forward

Ingress isn’t entirely obsolete. For straightforward HTTP/HTTPS routing for smaller services, it remains effective. But as soon as your needs scale up, involve complex traffic management, or require clear team boundaries, Gateway API becomes the superior choice.

Technology continuously advances, and your infrastructure must evolve with it. Gateway API isn’t a futuristic solution; it’s already here, enhancing your Kubernetes deployments with greater intelligence, flexibility, and manageability.

When better tools appear, upgrading isn’t merely sensible, it’s crucial. Gateway API represents precisely this meaningful advancement, ensuring your Kubernetes environment remains robust, adaptable, and ready for whatever comes next.

June 26, 2025 by Fernando SRE Cloud stuff DevOps stuff Kubernetes SRE stuff