KubeCon + CloudNativeCon - if you build it, your customers might not come. Why?

Chris Middleton Profile picture for user cmiddleton March 22, 2024
Summary:
A leaders panel in Paris found that even developers and platform teams need to think like a business in the cloud-native world.

Creativity, idea and innovation concept with light bulb and blank paper © Alejandro Ramoshots - Shutterstock
(© Alejandro Ramoshots - Shutterstock)

KubeCon + CloudNativeCon Europe 2024 – the biggest so far in its ten-year history – was generally shortened to ‘KubeCon’. But this left the cloud-native elements feeling a little side-lined in the Paris Spring.

A panel on Day Two sought to put that right, by bringing together four leaders at the tipping point between business and technology decision-making. The aim was to answer a simple question: Where next for cloud-native development? 

And that answer was: platform engineering. But not, critically, as solely a technology discipline. In the real world, internal platform teams need to begin thinking like business people, so that their customers – the organization’s developers – are not gifted an environment that has little practical use.

First, Thomas Graf, co-founder and CTO at networking and security provider Isovalent, suggested that cloud-native processes will, in effect, reach out to every part of the network infrastructure:

I think there will be more standardization on platform engineering [the discipline of building toolchains and workflows that deliver self-service to software engineers] that is outside of the cloud. 

The early phase of platform engineering standardization has happened on public cloud, and the main adoption of Kubernetes has been in public cloud. But in the next few years, we will see these concepts being applied more broadly by being brought into the data center, and brought to the edge, to hybrid cloud and multi-cloud. 

It will become more generic, and these principles will be applied to fields that have not been touched by cloud-native.

Paula Kennedy concurred. She is co-founder and Chief Operating Officer at start-up Syntasso, which makes an open-source framework for building developer platforms. But she added:

Somebody described 2023 as the year of platform engineering [rather than AI]. It felt like there's this huge momentum and buzz. 

But what I think is going to happen in the next couple of years is we're going to come out of this hype cycle and hit a real trough of disillusionment, where people are going, ‘Oh, I've done all this platform engineering. I've built this platform, but it's not delivering what I expected.’

So, I hope that people will share their experiences and learnings, because I think people have got to get to grips with platform engineering and understand what it means.

But what might that trough of despond be? Kennedy told diginomica:

There's this meme, ‘if you build it, they will come’. But you hear these stories over and over again of people saying, ‘We've built the perfect platform, but nobody uses it’. So, they build it, but no one comes. 

I'm in an echo chamber where people would be like, ‘Ha! No one would do that!’. Apart from everyone. They keep doing it! We've seen the pattern over and over, and the problem is that people aren't understanding user needs; they are building something for themselves. 

I meet people who used to be developers, who say, ‘I know exactly what developers want. So, I'm going to build that.’ But we're going to hit this peak of all of these platforms being built on Kubernetes, built on great technology, but if they're not delivering user needs, then people are going to be frustrated. And they've spent time and money, so they will be super-frustrated with the outcome.

Chuck Dubuque is Senior Director of Product Marketing for OpenShift at enterprise Linux distie Red Hat. He added:

Five years ago, every CTO was saying, ‘We're going all-in on the cloud, we're going to move everything to the cloud by next year.’ And that led to a very big trough of disillusionment. But now we have CTOs saying, ‘We're going to do everything on AI. We're going to embed AI into all of our products!’ 

So, how are they going to do that? Well, then it’s ‘We're going to do some platform engineering! We're going to do some cloud-native development!’ So, there's that real possibility again [of disillusionment]. If the experience is not informed by empathy, not informed by doing it in a collaborative fashion, then that is the biggest risk.

Kennedy picked up her theme again, saying:

Your internal platform is there to support your internal customers, so it has to be good – whatever good means to you. But that means understanding users’ needs, building something they want to use, and making a good developer experience – onboarding, good documentation, all the things that you want for your [internal] customer-facing products.

So, for me, platform engineering and the developer experience are the same thing. Platform as a product is really the mindset.

More democratic, but more chaotic 

That process can be adversarial, cooperative, or – ideally – collaborative, said the panel. Chairing the discussion, Jeefy Sica, Head of Projects at event organizers the Cloud Native Computing Foundation (CNCF), added:

There really is a difference, in that distinction between cooperative and collaborative, because those are two completely different paths, two completely different approaches. One is you're falling over to just do what you're told, but the other is actually giving meaningful feedback to try to produce a better outcome.

Justin Dustzadeh is Chief Technology Officer at datacenter giant Equinix. He said:

A platform, and all these tools, technologies and practices, should be in service of developers and users, that’s number one. But I think there are different metrics to measure the success of that mindset. 

First of all, with a platform, it should be faster and easier to build new capabilities every time you add something new. And the incremental cost and effort to build new products and services should diminish over time. 

And externally – I mean inside a company – let's say, if you're an infrastructure builder, then you need networking, you need data center capacity, you need bare metal or storage, and it should all be done at the speed of software in a true platform environment.

And externally, as a customer, developers should not go through a painful process to put these things together. That's really where the platform mindset can enable developing new capabilities at the speed of software.

Can you guess what Equinix’s hook line is? That aside, this does not mean that the platform team is, or should be, in charge of the process, cautioned Kennedy:

The platform does not need to be wholly controlled by the platform team. There's this concept of democratization or inner sourcing, where the platform shouldn't be one thing that serves other people, or is just given to them. 

Application developers should be able to add their own capabilities, if they've got a tool that they've developed or a capability they need other teams to use. The framework should be more like a marketplace of consumers and producers, so you can allow other teams to share their capabilities.

She added: 

That also helps with continuously evolving the platform. Some people mentioned [on Day One of the conference] about platforms going stale. But if you've got an easy way to allow new capabilities to be developed, for teams to be able to collaborate and contribute their own tools into the platform, then you've got a way to modernize it. That's the way that you can then go faster.

For Isovalent’s Graf, platform engineering is, in some ways, the middle ground between infrastructure as a service and application platforms in the cloud. But he warned:

The platform is becoming more democratic, yes, but also maybe more anarchic and chaotic. 

You used to just decide on a platform [for development], whether that was Heroku or vSphere, and that was it. But now we have Kubernetes. And we have dozens, hundreds of other projects that surround it, that you can mix and match to create your own [environment] and optimize heavily for your particular use case.

But then you also take on risk. And I think the other thing that we see with customers [developers] is they're realizing that the platform is also part of their application when it comes to things like their supply chain, their bill of materials, the experience they're delivering to their own customers. 

So, it’s deciding how much risk you want to take on yourself, versus outsourcing that to a partner.

My take

If you build what your customers actually want, they will come. Got that?

Loading
A grey colored placeholder image