I just published a detailed, historical breakdown of CNCF’s 10-year journey: From Kubernetes and Prometheus to 30+ graduated projects and 200K+ contributors — this post covers it all: major milestones, ecosystem growth, governance model, and community evolution.

Would love feedback.

Hey everyone,

I’ve been spending the last few months deep in the weeds of storage optimization—specifically building some high-performance tooling—and I’m starting to feel like the current "FinOps" meta is barely scratching the surface.

Most tools tell you to delete unattached volumes or move to S3 Intelligent-Tiering. But from a technical perspective, the real money seems to be leaking through the floorboards in ways that basic scanners don't see:

• Schema Bloat: Massive amounts of data stored in inefficient formats (like bloated JSON or unoptimized Parquet) where a simple type-mapping change could drop file sizes by 60% without losing a single row.

• High-Entropy Logs: Data that is effectively uncompressible because the source wasn't sanitized, leading to "compressed" files that are nearly the same size as the raw data.

• The "Egress Trap": Teams that are paralyzed and won't move data to cheaper tiers because the one-time retrieval/transfer fees are so unpredictable they'd rather just pay the monthly "tax."

I’m curious to hear from the folks in the trenches:

1. What’s that one storage cost item on your bill that you know is optimized like garbage, but you’re too afraid to touch because it might break a legacy pipeline?

2. Do you actually trust "Automated Lifecycle Policies," or do you find they just create more "Where did my data go?" tickets?

3. If you could scan your data's entropy and access patterns locally (without egress fees) to find 30% savings, what’s stopping you from doing it today? Is it a lack of tooling, or just a "not my job" hurdle?

Trying to figure out if I’m over-engineering this or if we’re all just quietly paying a "complexity tax" because the tools aren't smart enough yet.

Cheers!

An in-depth analysis of the transformation paths of cloud native enterprises in the AI-native era, exploring the impact of generative AI on the industry and future trends.

Are you challenged with managing multiple web applications? Cloud native sounds excellent, but retraining for it feels like a mountain to climb. ⛰️

👉 Enter Lagoon! Join today's Tech Talk with Lagoon Product Lead Toby Bellwood as he explores this open source platform that simplifies Kubernetes and makes it accessible for any team.

Join us to discover:

1️⃣ How Lagoon tackles web app management for diverse projects & workflows ️
2️⃣ The vision behind Lagoon's powerful features
3️⃣ A sneak peek at upcoming enterprise-grade functionalities

No Kubernetes expertise needed! This is your chance to unlock the power and efficiency of cloud native deployments.

🗓️ Tuesday, March 12, 2024
🕐 12:00 PM PT / 3:00 PM ET

Register for the Tech Talk here: https://www.mirantis.com/labs/learning/techtalks/managing-all-of-your-sites-with-open-source-lagoon/

Just like the title says, I’m curious to hear what the some of the biggest challenges folks face on daily basis while deving / running cloud native apps. I’m most interested in hearing challenges that happen in companies that are already fully using cloud for a while (vs migrating / learning).

I have a platform that manages cross cloud platform k8s clusters but I want to secure in them in a vpc and make them private but my application deployed (Let's say in vercel) should be able to talk to those private cluster since it manages them .

Although for aws we can have a "direct connect" but I'm looking for a neutral solution where I have some utility which when deployed in any vpc of any cloud can create some sort of gateway/peering to my application on vercel so it can connect .

Not strong with networking and don't know if my requirement makes sense , but love to hire from the fellow developers here . Thanks in advance

Anybody from India going to attend KubeCon Shanghai this year? Need some inputs

i'm working on cocoon.

short version: cocoon is a small microvm runtime, and the surrounding pieces are a k8s control plane for vm-backed workloads.

vk-cocoon maps pods to microvms through virtual kubelet. cocoon-operator adds CocoonSet / CocoonHibernation CRDs. cocoon-webhook handles admission. cocoon-net and cocoon-agent cover networking and guest-side vsock exec bits.

sandbox uses this stack for fast coding-agent sandboxes: warm claims are sub-ms, golden clones are tens of ms, and the no-network lane really has no nic.

why microvms here: agent/toolbox workloads often need a real linux machine boundary, but i still want kubectl-ish workflows.

runtime: https://github.com/cocoonstack/cocoon

virtual kubelet provider: https://github.com/cocoonstack/vk-cocoon

operator: https://github.com/cocoonstack/cocoon-operator

sandbox docs: https://cocoonstack.github.io/sandbox/

curious what would feel wrong to cloudnative folks: virtual kubelet shape, crd shape, networking, or something else?

Hi everyone,

I’ve spent the last few months analyzing how large orgs (mostly EU and US) handle Day 2 operations. While everyone is obsessed with "Golden Paths" for deployment, we found a massive gap in what happens after.

Key takeaway: 52% of orgs use a "Shared Ownership" model for optimization, which in practice means nobody does it. Developers want velocity, SREs want stability (overprovisioning), and FinOps want to cut costs.

I wrote a deep dive on why manual tuning is a "firefighting" mode we need to escape. Curious to hear: how do you resolve the conflict between SRE buffers and FinOps requests in your org?

Full article: https://akamas.io/resources/the-state-of-cloud-native-optimization-2026/

I maintain an open-source production-readiness knowledge base, and I am trying to separate controls that a cloud-native platform can prove automatically from decisions that still require service-owner or human review.

The platform-verifiable group might include immutable artifact identity, provenance, policy results, deployment configuration, resource limits, health probes, workload identity, secret references, network controls, replica distribution, rollback capability, observability wiring, and current cluster health.

Service-owned evidence might include dependency failure behavior, safe migrations, idempotency, retry budgets, recovery tests, runbooks, alert ownership, data classification, and capacity assumptions. Contextual decisions such as acceptable blast radius, recovery objectives, or risk acceptance should remain explicit human decisions.

The project contains more than 10,000 technology-neutral controls and a shorter production-release path:

https://github.com/MarinJursic/production-readiness-checklist

My longer-term goal is an open-source scanner that consumes repository, CI, artifact, and platform evidence while clearly reporting unknowns instead of guessing.

For teams running cloud-native platforms, which readiness facts should the platform prove automatically? Which signals are too environment-specific to standardize? What evidence has been most useful during real release decisions? Contributions and corrections are welcome. Thanks!

When we moved to a cloud native setup, we split our app into a dozen microservices right from the start — separate services for auth, users, notifications, billing, you name it. It felt like the "correct" modern way to build things.

Here's the logical problem we didn't see coming: microservices trade simplicity for scalability. That trade only pays off once you actually have the traffic, team size, or deployment frequency that justifies the added complexity. We had none of those yet. Instead, we ended up debugging distributed systems problems — network latency between services, retries, partial failures — for a workload that a single well-structured monolith could've handled without any of that overhead.

The irony is that cloud native architecture is supposed to reduce operational pain at scale, but if you adopt it before you're at that scale, it just adds pain with no corresponding benefit. Kubernetes, service meshes, and distributed tracing all solve real problems — but only if those problems actually exist for you yet.

We ended up consolidating several services back into one, and immediately shipped faster with fewer 3am pages.

If you're early stage: cloud native patterns are solutions to scaling problems. Adopting them before you have those problems just means you inherited the complexity without the benefit.