When it comes to cloud native application platforms, we’re at an important evolutionary point: will the best practice for platform strategies be to build or to buy? Should you choose the components you need for a platform and integrate them together, or should you buy a pre-integrated platform? Unless you’re a handful of organizations, the practical answer is that you should buy the platform.

Before I get to why, what even is a “cloud native platform”?

Defining a cloud native platform

The Platforms Working Group at the Cloud Native Computing Foundation (CNCF) has a great paper defining “platform.” They’ve got a real swell burger-diagram, above. Trying their best to boil down 13 pages into one paragraph, the authors summarize a platform as:

Platforms curate and present foundational capabilities, frameworks, and experiences to facilitate and accelerate the work of internal customers such as application developers, data scientists, and information workers… A platform for cloud-native computing is an integrated collection of capabilities defined and presented according to the needs of the platform’s users. It is a cross-cutting layer that ensures a consistent experience for acquiring and integrating typical capabilities and services for a broad set of applications and use cases. A good platform provides consistent user experiences for using and managing its capabilities and services, such as Web portals, project templates, and self-service APIs.

Platforms support the software you’ve built to run your business. A platform not only runs that software, but it manages the services your apps need. Typically, the platform also specifies how your apps are packaged, configured, and deployed to your platform. The platform usually has opinions about your app’s architecture. For example, a cloud native platform really wants your apps to follow the 12-factor best practices and use a microservices architecture. You know: containers.

Avoid accidental platforms

Platforms are the interface between your application developers and the cloud infrastructure and services their apps use. To me, that’s the key thing that makes it a platform instead of just a pile of clouds or catalogs full of “services” that developers have to find, learn, and integrate into their applications.

All apps need a platform to run. Developers will create that platform if one doesn’t exist. This leads to the spread of “accidental platforms” across the organization. All of these platforms need to be managed and cared for, and since they’re all different, staff spend a lot of time managing each platform.

In a large organization with thousands of developers and applications, teams don’t get the benefits of scale when they have a bunch of different platforms. This creates a huge amount of drag on IT: an IT manager, for example, and his staff could end up spending between 70% and 80% of their time on maintenance just keeping all the platforms running, with little time left over to improve those platforms or add new functionality developers need.

The main issue here is that it drags down the actual business because an organization’s apps are increasingly how the business functions, and even what the business is to customers. Think about how people interact with businesses, government agencies, schools, and even their hobbies and entertainment. Most of that is done through an app, through software as the primary, if not mission critical, component and “storefront.” And it’s not only that, software is how businesses get better, grow, and innovate.

Is Kubernetes a platform?

Over the past few years, there’s been a lot of confusion about where the line between a platform and infrastructure is, mostly driven by everyone’s interest in Kubernetes. Kubernetes is more focused on standardizing how infrastructure is used and managed, and how apps are configured and run.

That standardization is the goal of Kubernetes: wrapping an industry-standard API around all the different cloud infrastructures. It’s removing variability, which is always good in large IT shops. But, as said long ago, Kubernetes is a platform for building platforms. You use it to standardize your infrastructure across clouds, across on-premises, and even “edge,” so that you can then build your application-focused platform. On its own, Kubernetes just delivers a blinking cursor: an empty cloud that’s ready to be filled with useful services and apps.

But if you stop there, things go poorly. Many organizations are much too quick to hand over that blinking cursor to developer teams who have to first understand how Kubernetes works, and then, second, build the platform they need on top of Kubernetes. The result is a backslide into a mess of accidental platforms.

So, is Kubernetes a platform? Not the kind we’re talking about here, a platform for application developers. It’s the foundation for a platform. You still need to add the services, interfaces, and tools that application developers use. There are also all the usual operations, security, and compliance services you need.1

Pitfalls to building a platform

This is all to say that if you’re building a platform, you have a lot of work to do. You need to select each of the components, integrate them together, keep them updated, and improve them as you learn what works and doesn’t. In short, you now “own” a full product, including supporting it. And you need to run it and manage it. Ongoing, as new capabilities come along you’ll need to add those into your platform, for example, AI, new versions of programming languages and UI frameworks, databases, and so forth.

This is a lot of work. There used to be a quip that “all companies are software companies now.” which always seemed weird to me. No matter how good at software my favorite fried chicken restaurant is, if I order some Korean fried chicken, I want to find some fried chicken and fried cauliflower in the box, not software. But, once you start building your own platform, then you are a software company with the responsibility to build and maintain a software product. That requires a lot of corporate resources like time, money, and attention.

Whether your business is fast food, insurance, manufacturing cars, collecting taxes, or whatever else, you’d probably rather spend time being good at your business than good at platform building.

Benefits of buying a platform

For most organizations, a platform contributes very little to a business’ differentiation. You need a platform, but like electricity, email, ERP systems, and even analytics, the platform itself isn’t what makes a difference. What makes a difference is what you do with the platform and how you use the platform. The more time you spend building and maintaining your own, homegrown platform, the less time you spend focused on your actual differentiation, including your applications.

So, unless your customers buy from you because of your unique platform, you should probably buy your platform instead of building it. This frees up your resources to focus on your actual competitive advantages. '

Things like: how do they get that cauliflower so crispy and keep it so crispy as it cools off on the bike trip to my house?

You’ll also benefit from the platform being an actual, evolving product. For example, at the Tanzu, we build a platform, and we spend all of our time adding new features, improving it, and integrating it with as many types of infrastructure and services as possible.

The feature-set isn’t static like so many homemade platforms in large organizations end up being. You can see this with the AI services we’re adding to the Tanzu Platform – that’s become a priority for many organizations, so we’ve been adding it to our platform. The comprehensive integration with the Spring Framework is another example. If you have enterprise applications, you likely have many Java applications, and if you have Java applications, you’re very likely using a lot of Spring. If you use the Tanzu Platform, you can update your Spring apps quickly and easily, benefiting not only from new features in Spring and Java but also getting the performance and cost savings improvements.

What that means is that you have more time to focus on what actually matters: your own software and applications. That’s enough work, and hard enough, without having to worry about how you configure and deploy software, manage security, handle data, and otherwise do all that stuff below your apps.

To the question of whether it’s ultimately better to build or buy: buying a platform means you can focus all of your effort and resources on making your business better by perfecting how you make your software.

If you’re interested in how a platform fits into improving how your organization builds and runs software, check out the discussion below I had on that topic with Purnima Padmanabhan and James Watters. We of course talk about the VMware Tanzu platform, but you’ll also hear how large organizations are thinking through this build/buy decision.

This was originally published on CIO.com as a VMware Tanzu sponsored post (“BrandPost” they calls it). But, don’t worry, I did actually write it, all by myselves! Well, I mean, with some suggestions and copyediting from my work-pals, sure. I made some slight changes in the above.

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Atlanta Executive Dinner on Enterprise Software Dev, etc., May 22nd. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne/VMware Explore US, August 26–29, 2024. SREday London 2024, September 19th to 20th.

Discounts. Cloud Foundry Day (May 15th): 20% off with the code CFNA24VMW20. SREDay London (Sep 19th to 20th) when you 20% off with the code SRE20DAY. And, if you register for SpringOne/VMware Explore before June 11th, you’ll get $400 off.

🪵 Logoff

That’s it for today. I’ll save up the fun links and strange things from the World Wide Web for tomorrow.