Contrary to popular belief, monitoring an infrastructure is the opposite of just having some metrics about applications and network.
There are many excellent resources on this topic. One of the most interesting is just a few pages from Google — the art of SLOs. I took the book version from a Google on-site deep dive.
To structure this properly, I want to use four simple statements:
This is probably the main argument we’ll discuss here.
Great marketing quote in the title — but honestly, the underlying principle is always true: keep it simple, keep it safe.
I want to structure this around four topics:
Each could be its own post. This one will cut across all of them because they’re connected.
This is not a post about how to create a blog. This post inspects some technology that can simplify your life or your work with small but important concepts.
NO.
That’s the short answer. Kubernetes has not destroyed virtualization. Let me explain why.
I’ve been watching the “Kubernetes rush” for a few years now. Companies highlight success stories and cost savings, but I often wonder if they’re sharing the complete picture. I want to focus specifically on Kubernetes and virtualization — not the broader data center ecosystem with databases, legacy systems, and corporate infrastructure.
It’s time to talk about the API gateway.
In a modern infrastructure — especially in a microservices environment — you probably know what I’m referring to. But it’s worth being explicit about it:
“An API gateway takes all API calls from clients, then routes them to the appropriate microservice with request routing, composition, and protocol translation. Typically it handles a request by invoking multiple microservices and aggregating the results, to determine the best path.”
When you work in platform engineering focused on infrastructure, you sometimes need to create prototypes specifically built for platform testing purposes. I needed a backend that could simulate real API behavior without coupling to any actual business logic — something I could abuse freely.
Two goals:
Build the image and run it:
First, a thought about what this is and what it isn’t: this is about website metrics management. Not the only way, but one way for a high-level overview.
I’m focused on sharing concepts about website monitoring and one possible way to manage this in Kubernetes. You can reach the same goal with just Docker and crontab — but I’m using some other tools in Kubernetes because I’m evaluating them for other purposes.
Long story short: my VPS provider changed the price for their small instance from $1 to $3, so I took the opportunity to move my Postfix service from cloud to on-premises. Why move away from cloud when the rest of the world is moving toward it? Because my own domain is used primarily for alerting, and the cost/benefit stopped making sense at $3/month.
Every network admin hears it. “The VPN is slow.” “I can’t connect to $something.” “It worked yesterday.”
The problem: these complaints are vague. Is it the provider? A T2/T3 routing issue? The user’s local network? Without data, you’re guessing.
This tool collects data.
Deploy a pre-configured Grafana stack that monitors internet connection statistics. Select the endpoints that matter — VPN gateways, datacenter public IPs, main DNS servers — and get a continuous picture of latency and packet loss.
When you have Ingress resources, Ambassador, Nginx, Traefik, and service meshes — why would you put Apache HTTPD in a Kubernetes pod?
Because sometimes the routing logic isn’t ops’ problem. It’s a product problem.
Complex e-commerce sites serve multiple microservices under one domain. www.example.com might route like this:
/it/ and /it/offerte → CMS/uk/ and /uk/offers → CMS/it/clienti/ → customer-app/uk/customers/ → customers-app/secure/ → payment-appAnd then there are third-party domain acquisitions that need redirects. And A/B test variants. And country-specific promotional paths that change weekly.
A bastion host is “the only host computer that a company allows to be addressed directly from the public network.” It’s the security barrier between the internet and your internal infrastructure — the single controlled point for SSH and RDP access.
Apache Guacamole turns a bastion host into a browser-accessible portal: no VPN client, no SSH client, just a browser.
The problem with most Guacamole deployments: MySQL. A database dependency for something that’s fundamentally config management.