Stick with Cloud Foundry

I'm from marketing and I'm here to help

(0:00) Hello. Well, thanks for having me. It's always nice of you all to have me come here into your community and talk with you. Today I'm going to go over something that happens a lot, at least for me and probably for many of you, which is: why are we using Cloud Foundry? We should do something else. I don't need to convince everyone here about this. This is more some material you can use when you get in these situations. Because, as I like to joke at these conferences, I'm from marketing and I'm here to help.

(0:35) So let's get into it. Probably what you encounter a lot is: here you are, in one of these roles here. Maybe you're not the guy who's really excited. But you're working along, everything's fine, as people have been talking about, and someone comes in and says we should replatform, let's migrate off of this thing. And you're like, I don't even know where to start with this. So let's start with it and see some replies, some conversations you can have with people. First, why don't we go over the typical things that you encounter, and then I'll get into more of the - not solutions, but the discussions that you can have.

Why does this keep happening?

(1:13) Now, this is probably the most common thing. You've got someone coming from the outside. They just moved a gigantic regional grocery store to GCP, or Amazon, or Azure, or who knows what. They've moved all the stuff over, and they were hired to come move all of your stuff over. The thing about this kind of role is that it's, as we used to say, working as designed. You hired this person to come in and change things. They got hired, probably got a nice package, as they say.

(1:47) They look around at your landscape, and if they were to say "actually, things are cool, no need to change this," that doesn't really work for what they're doing. So you've got those people coming in a lot, and they need to change things around. Now, a related thing to that, as we'll get into, is that a working platform is invisible. Everything's going fine. It's supporting all your applications. You really only are known, and get visibility, when something goes wrong. In computers we like to come up with things we call laws, which are just sort of ideas we encountered once.

(2:23) And there must be some law that's basically: only through suffering do people appreciate computers. They don't really appreciate them when things are working fine. Now, highly related to "I was hired to make change" is: hi, I'm from the Center of Excellence, we are here to help you. You can think of this as the CoE from orbit. We're just going to nuke the platforms from our astronaut architect perspective, and we're going to replace it with something much better, because we're architecting and enterprising and doing that.

(2:56) And it's apparent from our whiteboards that change is a good idea. Then the next thing, which we'll try to turn upside down at the end, is of course a new workload comes along. I'm older, so I like to say workload - you could say a new application, a new solution, a new service, a new whatever. And of course you're like, this is new, it's completely different, we're going to need new platforms. Whatever sort of ancient thing you're using over here obviously can't deal with the new workload that we have now. There's an avenue here that maybe you've noticed: this is also when you invite your friends from consulting groups in, and they're like, hey, we're going to build some Python applications, and somehow we're going to run them in a platform, and then maybe we'll leave, and you're welcome, here you go. So a new technology comes in, has new requirements, and for some reason elves are installing it. Not really sure why.

This is me

(3:50) So this is me. You can tell because there's a picture of me. I worked, I don't know, 11 or 12 years at Pivotal and then VMware and now Broadcom, or VMware Tanzu by Broadcom by VMware Tanzu Pivotal, or something. But I've been really lucky to pretty much stick with the same job the whole time, which is talking with large organizations about what they're doing with software and how they're improving the way they do software to run their business. I used to be an application developer a long time ago.

(4:23) Long, long, long ago. And then I was an industry analyst at some places, and I've been able to write some books. I do several podcasts, if you're into that. They're really great, I'm told, for falling asleep at night, if you have trouble with that.

It works

(4:40) So let's go over the first one. Again, I'm not convincing you all of this. I'm trying to give you some talking points, as we would say in marketing. The first one, which is perhaps the least appreciated, is: it works. I think that's something that's hard for most people to realize when they're considering replatforming things.

(4:59) And it working is sort of the basis of all the other replies. I often think that - I don't know whether you track specs or stories or whatever - the number one story people leave out of the backlog is "it must work." It's sort of implicit in there. So it's good to have that as a requirement. And if you remember my talk from last year - I'm sure you do, so I'll quickly go through it - what you want to do is start collecting together evidence. Which means numbers, unfortunately, of the platform working, and the scale at which it works.

(5:33) We saw Rabobank this morning. They gave you some great numbers, which I updated here. So what you see here is whatever ratio you want. What you're showing is not only that it works, that we're actually running this amount of applications and supporting these developers, but that we're doing it in an efficient way. We don't need that many operators to do it, compared to the other things you might be asked to move to. So get yourself some numbers to orient around that.

(6:10) Now, also from last year, you want to start collecting together stories. Not only of your own organization, but of others. I work at Broadcom, so I love stories about how my bills get paid, but I like other stories too. It doesn't really matter whose platform it is. We all have some harmony here. To that point, we got a brand new story this morning from Rabobank, so you can add that to your menagerie of stories about how it works and what it does. Again, you have this story talking about what it supports, the scale that it runs at, how important it is, that it works.

(7:10) A particularly good one down there, if you haven't encountered it, is over in my home country, as it were. Charles Schwab has this great story of "we help run retail trading every day, for trillions of dollars," which is a pretty impressive application workload to have there. Along with supporting Netherlands banking, and all sorts of other things that you might encounter.

Replatform to what?

(7:30) Speaking of banks, this is from one of my banking friends who runs a platform. He introduced this idea, and we'll call it what he called it: "replatform to what?" Oftentimes you've got these, as we used to call them, architecture astronauts coming in. They've done all their work, as I said, and they've got an idea that we should migrate to a platform. So the good discussion there is - as always when you're debating with someone, you could agree a little bit at first, calm them down - to say: that sounds great, let's talk about what you want. What do you want to build? What do you mean by platform? And I think one of the first things that you encounter is that a platform tends to be a lot more than people think it is.

(8:13) They tend to focus on just one layer of it. They don't focus on the entirety of the platform. Achieving all those benefits in the stories we got is because, as you all know, you have an integrated platform, all the pieces together. And I find that it's best - because really we're talking about replacing it with Kubernetes, that's the story here - to use anything from the CNCF to make your point. You want to use other people's material. So you see that on the left.

(8:43) They've got this great platform diagram of what a platform is, the reference architecture for it. So you can start with that and say, all right, let's clear off your whiteboard that you brought in from the satellite, and let's start planning out what it's going to be. And I can tell you how we solve that problem and how we do these things. Part of that, of course, is not just the technology part. There's another great CNCF thing, the maturity model. There's an update to this that I think is in GitHub somewhere. But if you look through this maturity model, Cloud Foundry is more or less somewhere in the later stages of it, in a good way.

(9:19) Now, you might be wondering, what is a maturity model? What they tell you in slide school is you should never put a lot of text onto a slide, which I always like to break as much as possible, at least with one slide. So here we go. If you want to know what's in the maturity model, this is a summary that my little robot friend and I put together. You can actually see the original. You can read it now if you read really fast. But if you look through the criteria and you cogitate on it, if that's a word, a lot of Cloud Foundry installs are at level three or level four.

The three-to-five-year carousel

(9:55) What's notable about that is, if you look up how long migrations and replatformings take - I'm sure many of you have been swimming in ones that seem eternal, that never quite end - you look across the literature, if that's a word, which is to say some O'Reilly books and conversations with people, and there's more or less two ways you think about how long it takes to migrate something. One, you're migrating the platform. Again, great story from Rabobank. But then two, as I also went over, you're migrating the applications.

(10:26) That's another thing the astronauts forget about. So, based on the literature, you can see that there's a cycle that goes through. In the first year, you put a platform in place. It's the scrappy platform, with the team that's going to be hired away after about a year because they've built up cool skills. And then you're going to enjoy running it in this scrappy state. And the whole time you're like, if we just had three months to rewrite the platform and update it, we just need the budget. And then - this is great, from the platform engineering book - you go to management, and they're like:

(11:00) Listen, we've already done the budget cycle three months ago. We'll do it next budget cycle. Can you just keep it running? Just hold on. What's great about that strategy for management is that the next year, when it's time for budget, they're like, I don't know what the problem was. You ran it just fine. Everything was great. And then eventually you do get to building a new platform, and depending on how you do it, that takes a while to build up. Then you've got to migrate the apps. So this is what you're looking at. If you look at the maturity model, if you look at the platform engineering stuff out there, you're on this fun carousel of rebuilding on a three-to-five-year cycle.

(11:34) And then typically, once you reach the end of that cycle, it turns out you've built an ancient platform that needs to be rebuilt to another platform. Which is a thrilling way to live your life. So you're on the sad carousel there. Now, that's also assuming that it works. I have a lot of selection bias from being at a vendor, but I end up talking with a lot of people who are like, hmm, I remember three teams ago when we were putting a platform in place. That was thrilling.

(12:05) And now we've got it figured out this third time. It's really going to take off. To that point, more evidence: what I tend to see in applications is that moving away from Cloud Foundry to other things has sort of leveled out. All the easy applications have moved. I was talking with someone last week who was migrating to some cloud, and they were like, hmm, now we're working on the things that are a little hard to move. All the easy stuff moves over, but then you end up spending all this time on, what is it, the Pareto number?

(12:41) Mysteriously, all of life is built around 80-20 spreads. I don't know how that happened. But 20% of the applications are 90% of the work, or however you want to put it. That small amount of applications starts to be annoying. So the point there is, it's good to go into a discussion like this and say: let's think about migrations. Does anyone have fond memories of migrations? Let's go up to the board and put it on post-it notes and talk about migrations and replatformings we've loved. Which is going to be a blank whiteboard after that.

Seeing platforms

(13:13) So the next thing I was mentioning is that success is invisible. Let's talk about seeing platforms. How do you make the platform, if you want to use a fancy word, legible? If you're into French and Germanic forest management from the 1700s and things like that. How do you constantly show that your platforms are valuable, and get some fame for them? The first thing that you're going to want to do - and by "want to do," I'm going to tell you it's not great, it's just going to be your desire to do this - is break out one of the best platforms that civilization has ever created.

(13:51) Excel. And you're going to think, all I need to do is put something with euro signs in it, and my euro signs are going to be better than their euro amounts. Now, mysteriously, whenever you get into a spreadsheeting match about what the ROI is, how much it's going to cost - maybe you have found this - whatever you want to happen, your spreadsheet looks good and the other person's spreadsheet looks bad. I've been in these meetings. I changed jobs at some point because I hated these meetings.

(14:21) You're just like, what if we made that a five? Magic. It works. So you can put together your Excel spreadsheets. Your friends at Broadcom, we would love to put together a spreadsheet for you. You can see us at lunch. We'll make 50 spreadsheets for you. We'll make the five a four, make it a six, whatever works. But more realistically, instead of messing with spreadsheets and ROI stuff - you can save that for the executives and the salespeople when they're talking about licensing costs and pricing - I would start tracking a set of metrics.

(14:52) I want to talk a little bit about how you can start tracking metrics. I'll suggest some that you can read later. But start tracking metrics that are related not so much to the technology but to, if you'll pardon the phrase, the outcome: what it's doing for the organization. What's important here is that you track it, maybe on a monthly or quarterly basis, and you have these numbers ready and you can present them - gift them, or force them, on the people who need to see this sort of thing. Because if the only thing you have is "it works, all the applications are running," that doesn't make for a great chart. No one is really going to think about that. So you need to come up with metrics that you're showing people, reporting on. Also, all these people who you're trying to convince are in meetings all the time. They'll appreciate having something to do in those meetings, some sort of chart they can put up and report on the status of things.

(15:45) Now, of course, there are also what I would call IT-facing metrics. This is for the Center of Excellence people and others. Similarly, you want to track these metrics, show that things work, the success that you have, and be ready with what you have there. Again, select the metrics that are good for your organization and just report them.

(16:05) There's a great - I know you can't click on it now, you could try - talk from Camille here, of the platform engineering book. She has a fantastic talk. And in the book, if you still read books - you can have a robot read it for you if you want - she has a great section about managing, essentially, the internal culture in favor of your platform. I highly recommend it if you find yourself justifying or discussing platforms with people.

(16:19) Now, of course, as I always like to mention, it also helps to do internal marketing. Do little events, come up with a brand. There's a whole paper on this that I wrote that we never seem to get around to publishing, but you can read my draft. You track this over time. Hopefully, in your situation, you realize: we come up with a brand for it.

(16:51) We've got a color scheme. We have events. Again, it's all about making the platform visible, not just something that is invisibly successful there.

The new workload needs a new platform: AI

(17:01) So then the last section, which is: a new workload requires a new platform. And obviously we have AI here. So you bring in this new workload. Maybe today AI is all about data, maybe over here it's about managing tokens. It's all over the place, doing all sorts of stuff. Maybe we're freaked out about hallucinations, worried about who's responsible. But surely this needs a new platform.

(17:26) So we're going to have to introduce that. And this is actually, depending on what you want, a pretty legitimate way that you bring in platforms: we have a new type of application that needs a new platform running behind it. Which can be the case. That's how AI ends up creeping into a lot of things. But as I was talking with one of our teams that works in this region, what they realized - and it's probably evident to you all - is that what you have with Cloud Foundry is a platform that's perfectly built for AI workloads.

(17:59) Let's think about the characteristics of - I think we've all been chastised for anthropomorphizing AI recently, but it seems fine - let's think about what AIs want. They want very clear instructions. I mean, they want instructions. They do want to fiddle around with stuff and look at everything and configure it, but they're perfectly fine to just be told what to do and go look at this. They want well-documented APIs and code. They also want well-known APIs and ways of doing things. Which sounds like maturity.

(18:36) The Cloud Foundry community is very favorable here. It's extremely well-documented. It's got great command line interfaces. Or you can wrap an MCP server around it if you want to be fancy, or you can just shell out and call things. But it's very, very well-structured for the way that AI wants to work. It's all based on an intention-based way of doing things, which is exactly how you want to control crazy robots. Because the alternative is you have no seams, no walls around your infrastructure.

(19:10) So instead, you load up the AI and say, I've got to deploy this big cluster. And what it's going to do - as I'm sure many of you have experienced, when you're maybe also allowing it beyond the boundaries of Cloud Foundry - is two things that are very annoying. Well, there's a third thing we've discovered that's very annoying. But the two things it's going to do are: it's going to want to go visit every single component and configure it, do it how it wants. And then you're going to do it again, and it's going to be just 0.5% different.

(19:44) Every time that it goes and configures something, if you don't have a lot of control over it, it's going to do things differently. Kind of like humans: we're always trying to improve and try something new. But that kind of inconsistency is not cool. And of course, it's going to instantly, as we found recently, find your image registries and start spreading everything that it wants throughout your situation there. Again, think about the way that Cloud Foundry is arranged. If you want to lock it down more, you can essentially say there's this one little tunnel for deploying your applications.

(20:19) There's this one little way of doing it. So much of how you all have built Cloud Foundry is about control. We don't always say that, because you want to go to the developers and be like, yay, you have the freedom to deploy self-service, whatever you want. So you don't mention it to the application developers. But a ton of it is just: in this very small way, we can govern and control and secure. And that's the kind of thing that you really want to give off to the little AI guys and gals here, to limit them going around and messing with the internals of your platform in an inconsistent way.

(20:54) Here's more of a summary from my coworker and friend Adib, who put together this notion of - if you'll pardon another old phrase - the SDLC, the software development lifecycle, and how you would map AIs to it. You think about what AIs want, and you can see that - I'm repeating myself here - the way that it wants to manage things fits very well with the way that Cloud Foundry thinks about things.

Enjoy lunch

(21:24) Whenever you talk before lunch, you always want to end early, which I am doing, by a few minutes. So you can thank me later. If you're interested in these slides, I am part of the QR code lifestyle, so you can go find them there. And I'm pretty much always interested in talking with people about their Cloud Foundry experience and things like that. So thanks for having me, and enjoy lunch.