description = "Is the cloud really the ultimate solution? This post questions the current cloud-first mentality, arguing for a return to 'real' servers and discussing the hidden costs, dependency, and political vulnerabilities of relying solely on the cloud."
## The Case for Bringing Back "Real" Servers: Why the Cloud Isn't Always King
For years now, the narrative has been clear: the cloud is the future. Businesses big and small have flocked to platforms like Google Cloud and AWS, lured by promises of scalability, flexibility, and cost savings. But lately, I've been thinking: is this headlong rush to the cloud truly the best path? I believe it's time we seriously consider a return to "real" servers and acknowledge the limitations and potential pitfalls of relying solely on these tech giants.
Let's be honest, the cloud providers aren't doing anything magical. At their core, Google, Amazon, and the rest are simply running massive data centers filled with… you guessed it… servers. They've built impressive infrastructure and offer a wide range of services on top, but fundamentally, "they also just cook with water," as the saying goes. The perceived complexity and innovation can sometimes mask the underlying reality.
One of the biggest issues I've encountered, and I know many others have too, is the often-opaque pricing structure of cloud services. While the initial allure might be pay-as-you-go flexibility, the reality can be a tangled web of instance types, storage tiers, network egress fees, and a host of other charges that can quickly balloon your monthly bill. These "hidden costs" can be difficult to predict and manage, often negating the promised cost savings compared to the more predictable expenses of owning and maintaining your own hardware.
Furthermore, the increasing reliance on a handful of major cloud providers creates a significant dependency. We are essentially entrusting critical data and infrastructure to these companies, making ourselves vulnerable to their pricing changes, service outages, and even their long-term strategic decisions. This lack of control is a worrying trend, especially when considering the potential for vendor lock-in, where migrating away from a specific cloud platform becomes prohibitively expensive and complex.
Beyond the technical and economic considerations, the current political landscape adds another layer of risk to our cloud dependency. Imagine a scenario where political tensions rise, and a country like the United States, under a potential future administration, decides to impose tariffs on cloud services. Someone like Trump, for example, has shown a willingness to use tariffs as a political tool. If such tariffs were levied on cloud usage, businesses relying heavily on these platforms would face significant and potentially crippling cost increases. This geopolitical uncertainty makes the idea of having more control over our own infrastructure increasingly appealing.
In conclusion, while the cloud offers undeniable benefits in certain situations, it's crucial to have a more balanced perspective. We need to recognize that "real" servers still hold significant value, offering greater control, potentially more predictable costs, and insulation from the unpredictable nature of both cloud pricing and international politics. It's time to re-evaluate our cloud-first mentality and consider whether bringing some workloads back in-house, or at least diversifying our infrastructure, might be a more resilient and ultimately more cost-effective strategy in the long run.
@@ -53,9 +53,19 @@ Agency for internet and design founded in 1998, established in Kastellaun in the
## Projects
### DevOps Engineer, AEF AgIN Common-Connector
The Common-Connector is being developed by the Agricultural Industry Electronics Foundation (AEF) as part of their Agricultural Interoperability Network (AgIN) initiative. In my role as a DevOps engineer, I supported the tender and contributed to the development of the MVP. Our team developed a Java Spring Boot application to facilitate seamless data exchange between platforms.
- Conception and Development of a Dev Cluster based on AWS EKS (IaC)
- Setting up build and deployment pipelines (GitLab)
- Development of a test concept (Playwright, Testcontainers)
- Development and integration of the operator pattern in a Java Spring Boot application
- Development of the security pipelines (SonarQube, Mend, SAST)
### DevOps Engineer, Cofinity-X
**since 2023**
**until 2024**
Cofinity-X is the first operator of the Catena-X network, connecting automotive partners at every level of the value chain. As a DevOps engineer, I was responsible for the enablement services.
@@ -85,3 +95,4 @@ Just right for your pharmacy! amamed is the only digital solution on the market
- Design and operation of Kubernetes clusters (3 locations)
- Management of automated pipelines via Bitbucket Pipelines (continuous integration)
You know the feeling. It’s that gentle, peaceful moment just before you drift off to sleep. Or maybe it’s 3 AM on a Tuesday. Your mind is blissfully empty, and then, a rogue thought, fired from the darkest recesses of your subconscious, slams into your brain:
*“That server I spun up for that ‘quick test’ in Q2 2022… is it still running?”*
A cold sweat follows. What was it running? Is it patched? Is it secretly hosting the world's largest collection of pirated cat videos? You have no idea.
As a DevOps Engineer, I’m basically a professional juggler. But instead of juggling cute, fluffy balls, I’m juggling servers, containers, microservices, and the lingering ghosts of projects past. I’m spread across so many clients and internal projects that my brain has more tabs open than a web developer on a research binge.
The biggest nightmare? The *unmanaged* resources. The ones that aren’t neatly tucked into an Ansible playbook or a Terraform state file. The digital strays you adopted out of necessity and now have to feed, walk, and occasionally scrape digital chewing gum off of. Keeping track of what’s running is hard enough. Remembering what needs to be updated is a Herculean task.
### The Breaking Point
My breaking point came after a frantic afternoon spent auditing a forgotten corner of a client’s network. I found a container running a version of a service so old, its logo was probably still carved in stone. The feeling wasn't anger, it was a deep, existential sigh. There has to be a better way than relying on my own faulty, coffee-powered memory.
I complained to my rubber duck. I stared into the void. The void stared back and whispered, “Dude, just script it.”
And you know what? The void was right.
### Introducing: updates-sucks
Because let’s be honest, they do. The process of checking for them, that is.
So, I built a beautifully simple tool to scratch my own itch: **[updates-sucks](https://github.com/wellcom-rocks/updates-sucks)**.
It’s not fancy. It won’t make you a latte or file your taxes. But what it *will* do is save your sanity.
I created a dead-simple pipeline that runs once a week. It quietly scans for my digital flock and checks which resources are lagging behind, crying out for a fresh update. It then gives me a neat little nudge, a “Hey, don’t forget this thing!” report.
It’s like having a hyper-organized, slightly passive-aggressive robot assistant whose only job is to prevent me from becoming the subject of a future IT horror story.
### How It Saves Your Bacon
The beauty of `updates-sucks` is its simplicity. It’s a lightweight Go application that focuses on one thing: checking for container image updates. No bloated dashboards, no 200-page user manuals.
1.**It checks:** It looks at the resources you tell it to watch.
2.**It compares:** It sees if a newer, shinier version is available.
3.**It reports:** It lets you know what needs your attention.
That’s it. It’s the digital equivalent of putting sticky notes on everything, but the notes apply themselves automatically and don't fall off.
### Stop the Madness. Reclaim Your Sleep
If you’re a DevOps engineer, a sysadmin, or just someone who has spun up one too many “temporary” things, I invite you to check it out. Stop letting the ghosts of servers past haunt your nights.
Give **[updates-sucks](https://github.com/wellcom-rocks/updates-sucks)** a look on GitHub. Fork it, star it, use it. Let’s make that 3 AM cold sweat a thing of the past. Your sanity (and your security team) will thank you.
<arel="{{ rel_attributes }}"{{blank_target}}href="https://www.getzola.org">Zola</a> and running on real <a{{blank_target}}href="/blog/use-real-servers-again">Servers</a>
{# Shows link to remote repository #}
{%- if config.extra.remote_repository_url and config.extra.show_remote_source | default(value=true) -%}
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
