dthn

Most cloud decisions are made with incomplete data. You see costs. You see usage. But not: What drives it? Who owns it? What breaks if you change it? That’s how “optimization” creates new problems. Contact us for a free consultation: dthn.io #AWS #FinOps

📖 Want to dive deeper? Full article here: kubernetes.io/blog/2026/04/2… Drop a comment 👇 Image credit: Kubernetes (@kubernetesio).

Kubernetes (@kubernetesio) v1.36 “Haru” is out 🚀 Big upgrades in security & policies for Kubernetes. But this release also marks the end of an era: Ingress NGINX has officially been retired (March 24, 2026). A moment of silence. Thank you for your Service. 🫡 #Kubernetes #DevOps

👀 This release really feels like Kubernetes growing up with more built-in power and less glue code. 👉 What’s your favorite update in v1.36? 👉 Are you exploring CEL-based validating/mutating policies yet or sticking with tools like Kyverno?

One personal highlight from us: Mutating Admission Policies (GA) update using CEL expression. This removes the need for external webhooks in many cases, making it simpler, faster and more native. That said, we are still on Kyverno for the moment though. 👀

As more and more of their workloads move to German/EU clouds, their data privacy and sovereignty improve significantly. And that opens doors and attracts more “nervous” customers like public sector, schools and enterprises with strict compliance requirements.

For companies using providers like Amazon Web Services, Google Cloud, or Microsoft Azure, this can become a real concern. 👉 To mitigate this, companies can move to German or EU-based cloud providers such as Hetzner, OVH, IONOS, StackIT, ...

“Where is your data stored?” This question is reshaping cloud decisions in Europe. Not about cost. About compliance, trust, and sovereignty. EU-based cloud providers are becoming a strategic move, not just technical. #GDPR #Cloud #SaaS #viral #startup

Cloud waste is rarely dramatic. It’s usually quiet, structural and easy to miss. That’s why visibility and system design matter. Curious where waste might be hiding in your setup? Let’s take a closer look: dthn.io

Most cloud waste comes from a few patterns: 1. Legacy systems (years of patchwork) 2. No visibility (no tagging, no ownership) 3. Oversized resources 4. Idle servers 5. Always-on test environments Nothing looks broken. That’s why it’s expensive. Check our comments! #AWS #DevOps

Simple change, noticeable savings.

You can set it up so engineers can request to spin up the testing environment on-demand and leave it running for a couple of hours, or set up an automation with a schedule to spin-up shortly before the workday starts and spin-down shortly after it ends.

If you don't automatically scale (autoscale) appropriately, you're paying more than you need.

4. Idle Resources: Similar to (3) Servers that are un-/underutilized. In the pay-as-you-go-model AWS doesn't care if you app is getting 1 or 1 billion requests per day. You pay either way.

3. Incorrect resource sizing: Most resources, especially on plain hosting/virtual machines are scaled to handle the maximum load at any given time. But what if your app is business facing and not many people use it on the weekend? Then you're wasting ~28.6% of spend already.

But it's like knowing that you spent 4,397 EUR on the family Amazon.com and 3,265 EUR on Amazon.de accounts. Which items were actually bought? Who's responsible? Tags will help you to assign resources to the correct cost centers.

2. Missing visibility: Multi-account structure, no tagging, no cost allocation. Per default you'll only see which service costs what, depending on how deep you want to dig you'll also find out usage type and region.

Now you have a house of cards where every piece is load-bearing. Touch one thing, some other system may break down. Refactoring into a wholly comprehensive architecture can help move from patchwork to efficient cloud infrastructure.

1. Legacy systems - historical growth: You started years ago. There was no clear architecture at the beginning while you kept adding systems, workloads and complexity over time.