The Hidden Frictions of Kubernetes Adoption: From Speed Gains to Platform Engineering Challenges

After adopting Kubernetes, we were thrilled and our team's velocity increased dramatically, but we didn't notice emerging frictions.

1 K8s Surge, but also Disagreements

Kubernetes has been around for nearly ten years, and in the past five years its adoption has exploded across teams of all sizes, from static sites to mature micro‑service solutions, driven by promises of standardized deployment and scaling.

Kubernetes is currently in a "hype cycle" stage. Engineers find it easier to accept Kubernetes as their platform of choice, whether on cloud or on‑premises, leading to single‑node clusters in retail stores and thousands of nodes across data centers for e‑commerce sites.

Undoubtedly Kubernetes is unstoppable, but when the hype subsides we will discover many disagreements it brings.

2 Some Things Cannot Be Standardized

When promoting Kubernetes, the discussion inevitably turns to standardization: the idea that everything you run can be containerized, giving each service a standard shape and connector.

Indeed, Kubernetes standardizes large‑scale software deployment, but it does not solve how to know whether the software is doing what it should. We cannot standardize the verification of a program's intended behavior because different applications solve different problems.

3 K8s Disrupts DevOps

I am an application engineer who fully embraces the DevOps movement, which for me means close collaboration with experts who give my code life beyond my local machine and ensure my applications run optimally for users.

This collaboration helped me understand the challenges faced by platform engineers, and they began to see my limitations, allowing us to co‑create the applications users want.

With Kubernetes, development teams move so fast that new frictions appear under the name of "platform engineering". Kubernetes administrators can create clusters but know nothing about what runs on them because we have standardized everything around containers.

Some may think this is beneficial because the boundary between applications (containers) and infrastructure (clusters) is clearer, but I disagree. Engineers still need to consider deployments, services, sidecars, service meshes, nodes, node affinity, and countless other concerns.

You might say, "That's the platform's job," yet this proves the earlier point: new disagreements arise. We push infrastructure and application engineers to work together, understand each other's worlds, and ask informed questions. The old "let someone else handle it" mindset leads to blame‑shifting when problems occur.

Good dialogue and awareness that each team needs different tools are essential for project execution. Platform engineers manage everything from auto‑scaling to network routing, while application engineers focus on product features and user experience.

However, after migrating to Kubernetes, many treat the migration as the end goal. Once everything runs, they feel there is nothing else to do, neglecting regular upgrades and continuous improvement.

4 K8s Arrives, Monitoring Tools Fail

With the shift to Kubernetes and the ephemerality of infrastructure components like Pods, our traditional methods for monitoring and debugging applications have broken down. We are applying infrastructure‑level techniques to application debugging, which hampers both developers and platform engineers.

K8s makes it easier to deploy and iterate, but it does not make applications easier to observe.

Updating applications, enabling more deployments, and supporting canary releases are great, yet they do not simplify debugging for developers.

When we had a fixed number of servers, we could add each server as a dimension in application metrics and combine it with version numbers, yielding low‑cardinality data suitable for time‑series databases. Now Pods can be rescheduled onto new nodes, and each deployment generates new high‑cardinality Pod names that traditional metric systems struggle to handle.

5 Platform and Application Teams Isolated, Context Missing

Users do not care about our infrastructure; they only care whether the overall system responds to their requests.

Unless there is an exception or HTTP error, issues are often escalated to the platform team as infrastructure problems, leaving application engineers with little context.

We need to determine whether a problem is confined to a single infrastructure component (e.g., a Pod or node) or affects the entire system, which makes high‑cardinality data crucial for telemetry.

Bridging this gap requires both teams to collaborate, combining customer‑centric data (custom traces from application engineers) with infrastructure‑centric data (Kubernetes metrics) to fully understand why customers are dissatisfied.

6 In Conclusion: K8s Is Not a Panacea

When enterprises complete their migration to Kubernetes and enter operations, they must avoid siloed approaches. Platform engineering must support application engineers and together deliver the best service to customers.

This requires processes, tools, and culture that enable collaboration rather than control, preventing a "us vs. them" mentality that harms the overall customer experience.

Remember: if a tool must be invoked by command rather than being adopted voluntarily, the tool may have a problem.

Building high‑performance teams that collaborate seamlessly calls for a common technical language as a bridge. Tools like OpenTelemetry can provide joint visibility through developer‑focused traces and infrastructure‑focused metrics.

Only when platform engineering and application/product engineering work together can the best customer experience be delivered, though this collaboration is not free.

In short, Kubernetes is not a magic bullet for better software performance; collaborative teamwork across multiple teams is essential.

Advertisement: Backend‑Specific Technical Group

Build a high‑quality technical community; developers, recruiting HR, and anyone willing to share internal referral information are welcome to join and help each other improve.

Civilized discussion, focusing on 交流技术 , 职位内推 , and 行业探讨 .

Advertisers stay out; do not trust private messages to avoid scams.

Add me as a friend and I will invite you to the group.