Platform Engineering

DevOps, CloudOps and Platform Engineering

State of app certifications on Kubernetes in 2025

von

The software industry has undergone significant changes in how applications are deployed and supported, particularly with the rise of containerization and Kubernetes. Traditionally, application vendors certified their software for specific operating system versions. Kubernetes introduced a new paradigm that potentially changes this support model. In this post, I want to examine whether it is time to shift from traditional support models to supporting Kubernetes (API) versions.

Traditional OS-Specific Support Model

How the Traditional Model Works

In the traditional model, software vendors test and certify their applications against specific operating system versions and patch level. This approach creates a tightly controlled environment where the vendor can ensure compatibility and performance. For enterprise applications vendors like SAP, Oracle or Microsoft this model has been the standard for decades – with detailed compatibility matrices specifying app versions are supported on which OS versions and what patchlevel.

Benefits of the Traditional Model

  1. Predictability and Stability: By limiting supported environments, vendors can thoroughly test their applications in controlled conditions, reducing the risk of unexpected behavior
  2. Clear Support Boundaries: When issues arise, there’s a clear delineation of responsibility between the application vendor, OS vendor, and customer
  3. Simplified Testing: Vendors only need to test against a finite number of OS versions rather than an infinite combination of configurations
  4. Established Processes: Enterprise customers are familiar with this model and have built their IT operations around it

The Kubernetes Paradigm Shift

How Kubernetes Changes Application Deployment

More than 10 years ago, first Docker and then Kubernetes started to introduce an abstraction layer between applications and the underlying infrastructure, using containers to package applications with their dependencies. This creates a more consistent runtime environment regardless of the underlying infrastructure. Kubernetes provides standardized APIs for deploying, scaling, and managing containerized applications across different environments – including fundamental infrastructure abstractions like storage (volumes) or networking capabilities.

The Kubernetes Conformance Testing Process

Kubernetes is governed by the Cloud-Native Computing Foundation (CNCF). And the CNCF has established a process to ensure “Kubernetes actually is Kubernetes”. This is called conformance testing. Kubernetes conformance is verified through Sonobuoy, a diagnostic tool that runs the official conformance test suite. The conformance test suite checks whether Kubernetes distributions meet the project’s specifications, ensuring compatibility across different implementations by covering APIs, networking, storage, scheduling, and security. Only API endpoints that are generally available and non-optional features are eligible for conformance testing.

The CNCF has made significant progress in conformance coverage – from approximately 11% of endpoints covered by tests in 2018 to less than 6% of endpoints not covered by conformance tests as of Kubernetes 1.25. This comprehensive coverage means that any CNCF-certified Kubernetes distribution must support the same core APIs, regardless of the underlying infrastructure or vendor-specific additions.

The Case for Kubernetes API-Based Support

At the same time, many application vendors are still applying the traditional OS-specific support model to Kubernetes by certifying their applications for specific commercial Kubernetes distributions. This approach treats each Kubernetes distribution as if it were a different operating system, requiring separate certification and support processes.

Benefits of Supporting Kubernetes API Versions

  1. Simplified Support Model: By focusing on Kubernetes API compatibility, support becomes more straightforward, with clearer boundaries between application issues and infrastructure issues
  2. Improved Portability: By supporting Kubernetes API versions rather than specific distributions, applications become more portable across different environments
  3. Vendor Lock-in Concerns: Some customers worry about vendor lock-in with specific Kubernetes distributions and want assurance their applications will work in other environments
  4. Reduced Certification Burden: Application vendors can focus on testing against standard Kubernetes APIs rather than multiple distributions, reducing the testing matrix significantly
  5. Faster Innovation: Application vendors can release updates more quickly without waiting for certification across multiple Kubernetes distributions
  6. Alignment with Cloud-Native Principles: This approach better aligns with the cloud-native philosophy of platform independence and portability
  7. Kubernetes API Stability Guarantees: Kubernetes provides strong API stability guarantees, especially for GA (Generally Available) APIs, making them reliable targets for support
  8. Support Ecosystem: Established support channels and partnerships exist between application vendors and Kubernetes distribution providers

Challenges with the Kubernetes API-Based Approach

While there are many advantages to this approach, of course there are some potential challenges.

  1. Distribution-Specific Features: Different Kubernetes distributions offer unique features and extensions that applications might leverage
  2. Enterprise Customer Expectations: Many enterprise customers still expect vendor certification for their specific Kubernetes platform
  3. Varying Implementation Details: Despite standardized APIs, implementations can vary across distributions, potentially causing subtle compatibility issues
  4. Security and Compliance Requirements: Enterprise customers often have specific security and compliance requirements that are tied to particular distributions

Practical Considerations for Application Vendors

So what can be done about the situation? And how could the cloud-native community move forward towards a new model? As always in life, a balanced approach might be the best option to get started – and evolve from there.

Implementing a Balanced Approach

  1. Define Core Requirements: Specify minimum Kubernetes version and required capabilities (like RWO volumes or load balancing) rather than specific distributions.
  2. Tiered Support Model: Offer different levels of support – full support for tested distributions and best-effort support for any Kubernetes cluster meeting API requirements.
  3. Leverage Kubernetes Certification: The CNCF Kubernetes Certification Program ensures distributions meet API compatibility requirements, providing a baseline for support.
  4. Container-Focused Testing: Test applications in containers across different environments to ensure consistent behavior regardless of the underlying distribution.
  5. Documentation and Guidance: Provide clear documentation on required Kubernetes features and configuration, enabling customers to self-validate their environments.

Conclusion & Comment

The transition from OS-specific support models to Kubernetes API-based support represents a significant evolution in application deployment and management. And a huge shift towards choice for customers and end-users. But while there are compelling reasons to adopt a more platform-agnostic approach based on Kubernetes API versions, many application vendors still rely on distribution-specific support.

As a user, I’d challenge application vendors that say “my app is only supported on X”. So is it a super cool cloud-native, container-based workload? A modern app that promises business benefits, a better operational experience or better resiliency?

Because if the container-based app can’t run on any conformant Kubernetes, it might actually be better suited for a traditional OS deployment model inside a VM. The operational burden of using and maintaining specific distributions or specific versions of distributions is just adding complexity – where Kubernetes and cloud-native apps actually promised a “next-gen” experience.

My VMworld 2016 session proposals (NFV, Containers/Docker, …)

von

VMworld session voting time has come and I just wanted to share my session proposals – your votes would be appreciated:

On the multi-dimensional evolution of platforms and applications

von

I’d like to touch on a topic that I am seeing in several of my areas of interest right now. In general, it’s related a lot to the overall topic of „First, Second and Third Platform“ but I’d like to focus more on the individual implications for multiple domains. Over the course of the last few months, I have been involved in several discussions around different platforms and applications as well as their individual evolution and maturity. My personal observation is that both don’t necessarily evolve synchronously. Therefore, it is important to not only identify the phase that you are currently in but also to understand the operational implications of the „generation disconnect“ between app and platform.

 

Evolution of Platforms

As mentioned above, I’d like to relate my observations to the three platform generations below. I’d like to point out that these three generations are subdivided in several different technologies and can look and feel different in specific use-cases or fields of application. The common sense around the generations is:

platform_evolution

 

In addition to these phases, I see different „implementations“ of the respective platform generation. Take Client-Server as one example – this can be a physical-server-only model, this also stretches to server virtualization and potentially even to „VM-oriented“ hosting or even cloud services. My friend Massimo also wrote a nice piece on this.

 

Evolution of Applications

One of my key observations is that there is no simple 1:1 connection between applications and platforms. With the rise of 2nd generation platforms, not all applications from the 1st platform have been dropped and immediately been available for the next-generation platform. It’s actually an evolution for applications that are still business-relevant and therefore make sense to be optimized for the next-generation platform. And here comes the important observation: I believe there are (at least) three phases in an application evolution cycle that is happening for each platform generation – or potentially even in each concrete implementation of the platform generation. I’ll call theses phases „Unchanged“, „Optimized“ and „Purpose-built“ for now:

application_evolution

But how does that fit in the overall platform picture? I’ll try to merge the previous two pictures into one. It also shows a potential application evolution path across platform generations. As you can see, there can be a slight overlap between „purpose-built“ of the previous and the „unchanged“ phase of the next-generation platform.

evolution

But let’s move on to two concrete examples that I see applicable.

 

Example 1: Network Functions Virtualization

I’ll start with Network Functions Virtualization (NFV). NFV is a Telco industry movement that is supposed to provide hardware independence, new ways of agility, reduced time to market for carrier applications & services, cost reduction and much more – basically, it’s about the delivery of promises of Cloud Computing (and Third Platform) for the Telco industry (read more about it here). The famous architectural overview as described by ETSI can be seen below:

ETSI NFV

NFV differentiates between several functional components such as the actual platform (NFVI = Network Functions Virtualization Infrastructure), the application (VNF = Virtual Network Function), the application manager (VNF manager) and e.g. the orchestration engine.

So how could this look in reality? Let’s assume the VNF manager detects a certain usage pattern of its VNF and that VNF is reaching it’s potential maximum scale for the currently deployed amount of VNF instances. The VNF manager then talks to the Orchestrator that could then trigger e.g. the scale-out of the VNF by deploying additional worker instances on the underlying infrastructure/platform resources. The worker instances of the VNF could then automatically be included in the load distribution and have instant integration into necessary backend services where applicable. All of that happens via open APIs and standardized interfaces – it looks and feels a lot like a typical implementation example for a „third platform“ including the „purpose-built“ app.

Now into a quick reality check. ETSI’s initial NFV whitepaper is from October 2012. It basically describes the destination that the industry is aiming for. And while there might be some examples where VNFs, NFVI and Orchestration are already working hand in hand, there is still a lot of work to do. Some of the „NFV applications“ (or VNFs) might have been just „P2V“’ed (1:1 physical to virtual conversion) onto a virtualization platform and basically have the same configuration, same identity and are kept as close to its physical origins as possible. This allows a VNF provider/vendor to keep existing support procedures and organizations while offering their customers a „NFV 1.0 product“ that is providing some early benefits of NFV (hardware independence, faster time to market, …). But this also implies that you transfer some of the configurations that made perfect sense in the physical world over to the virtual world – where it only makes questionable sense. In this case, I’d actually talk about a move from a „purpose-built“ app from the first platform to an „unchanged“ app on the second platform. 

One example: one physical server in a telco application had 30*300GB harddisks, had 2*4Core CPUs and 128GB RAM. It never used more than 1TB of storage and average utilization has been below 4 CPUs and 32GB RAM. The „unchanged“ version of this app would be a 1:1 conversion with all (unnecessary) resource overhead provided in a virtual machine. The „optimized“ version of this app is a right-sized application (so only 1TB storage, 4 CPUs and 32GB RAM) that is also leveraging easy configuration files for installation as well as crash-consistent and persistent data management to allow backup & restore as VM. But a „purpose-built“ version of that app would leverage the underlying NFVI APIs, would allow scale-out deployment options based on actual demand as well as optimizations that are e.g. encryption at every layer of the application to ensure global deployment models even in the face of lawful interception relevance, etc.

 

Example 2: Microservices, Containers & Docker

My next example are microservices and their close friends containers. They are promising a new generation of application architecture and are drivers for the „3rd platform“ architecture. One of this movements famous poster-childs is Docker. Docker is a great (new) way to package and distribute applications in „containers“ that contain applications or just pieces of a larger application architecture. Newly developed applications usually follow a scale-out design, some might be written with something like the „12 factor app“ manifesto in mind (or the 15 factors according to Pivotal). Coming back to the pictures above: a 12 factor app could be considered „purpose-built“ for the „third platform“.

But how many applications have been built for this? There are many great examples for microservices-oriented applications by the „cloud-native“ companies such as Google, Amazon, Facebook and the likes. Adrian Cockcroft also gives inspirational talks about these topics around the globe. But I actually expect many applications to stay mainly unchanged as they are optimized for their current platform. At the same time, some of them might become available as (Docker) containers as part their next release. But again – if you look into the details, you’ll find the same application in a different wrapper. RAR is now ZIP (for my German readers: „Aus Raider wird nun Twix…“). But will these potentially „single-container-applications“ run well on a Cloud-Native/third platform architecture? They might not! To put it in a picture:

So in this case, it is actually important to understand these application limitations and expectations towards the platform (what about data persistence, security, platform resilience, networking, …) to make sure it runs smoothly in production. Coming back to Massimo’s blogpost – you can run your old Windows NT4 on a Public Cloud, but does it make sense?

Summary

Just like the continuous evolution of platforms that expose new characteristics and capabilities, there is also an ongoing evolution of applications. It is important to understand the key aspects of the application architecture and it’s deployment model before making a platform decision. The word „VNF“ does not necessary imply the alignment with NFV and the word „Docker“ does not automatically describe a Cloud-Native or microservices-oriented application.

 

Edits:

18.05.2016: added picture (containerizing legacy applications)

Cloud-Native Applications – Link Collection

von

vmware_cna

I started to collect the most comprehensive and important links around (VMware) Cloud-Native Applications on a dedicated page on this blog. I’ll keep it updated over time. If you feel something is missing, just ping me on Twitter and I’ll add the link/material.

You can find the page at:

Cloud-Native Applications

VMworld Tipp: Cloud-Native Applications & vSphere Integrated Containers

von

Die VMworld 2015 in Barcelona steht unmittelbar bevor. Eine Teilnahme an der VMworld hat für mich schon immer bedeutet über den eigenen Tellerrand zu schauen und ein Gefühl für die aktuellen Trends und Themen der nächsten Jahre zu bekommen. Dazu gehört natürlich auch der persönliche Austausch mit Kollegen aus anderen Firmen, Sessions, Labs, Diskussionsrunden und vieles mehr.

Auf die Frage nach den interessantesten Sessions zum Thema „Zukunft“ verweise ich in den letzten Wochen gern auf alles, was sich im Cloud-Native Applications (CNA) Bereich abspielt: die Sessions mit dem Kürzel „CNA“, die Hands-On Labs zum Thema, etc. Warum ich das Thema besonders für vSphere Administratoren und Manager von Virtualsierungsteams als wichtig ansehe werde ich in einem separaten Blogpost erläutern.

Als Teaser und 3:30min Zusammenfassung eines der wichtigsten Announcements rund um Cloud-Native Applications von der VMworld 2015 in San Francisco möchte ich an dieser Stelle auf ein Video hinweisen – viel Spaß mit vSphere Integrated Containers:

vRealize Operations 6.0 – collection of new material

von

As you may have seen already, vRealize Operations (former vCenter Operations) has been updated to version 6.0 right before Christmas . With this new version, lots of great features have been added and there were lots of changes to the User Interface – mainly the convergence of vSphere and Custom UI. Besides architectural changes, there were also major updates around Views and Custom Reports. I collected some links around version 6.0 that I’d like to share here as well.

Documentation & Whitepaper

Videos

„The Phoenix Project“ – book recommendation

von

Just a couple of weeks ago, I received a recommendation for the book „The Phoenix Project“ (Amazon.com Link) that I want to reshare here today. It’s „A Novel About IT, DevOps, and Helping Your Business Win“ and I really enjoyed reading this book. It tells the story of Bill, an IT manager inside the fictional company Parts Unlimited. Their challenges pretty much overlap with many topics addressed in VMware Cloud Operations.

On a regular Tuesday morning, Bill receives a call from the VP of HR and suddenly finds himself in the office of Parts Unlimited CEO Steve. Steve talks him into becoming the new VP of IT Operations, reporting directly to him. But this is not part of the usual promotion process. Bill is becoming VP after the previous CIO and VP of IT Operations were fired just hours ago. In a phase where Parts Unlimited is facing major competitive threats – and lots of IT issues. Besides numerous major outages, they have just two weeks until the release of their long-awaited Phoenix project. A project that CEO Steve expects to „close the gap with the competition“. Customers, shareholders and all employees of Parts Unlimited are waiting for this release. And it has to be a success, otherwise the company might even go out of business. Now, Steve expects Bill to run operations and launch Phoenix. But (of course) this project is already two years delayed and has cost more than $20 million. No pressure, Bill…

And so the story begins. Over time, Bill, Steve and many others are starting to realize where IT Operations and Development have room for improvement. But the business starts also to realize how many projects actually rely on IT.

With lots of great examples, the authors give practical insights on how a successful transition towards a more business-oriented IT delivery can be realized. Because in the end, IT is all about helping the business win.

Related links, I’d like to recommend as well:

Shameless plug: my VMworld Sessions on Cloud Ops

von

I am in the middle of preparing the VMworld session „SDDC IT Operations Transformation: Multi-customer Lessons Learned„. My colleague Valentin Hamburger and myself got accepted to present both at VMworld 2013 in San Francisco and Barcelona and we are very excited about this opportunity.

Just last week, we hosted several VMware TAM customer roundtables in Germany with focus on Cloud Operations / Cloud Ops. There is lots of interest in this topic and I am looking forward to the other VMworld sessions around Cloud Ops as well.

In case you haven’t heard of Cloud Ops so far, make sure to check out these resources:

Looking forward to seeing you at VMworld!