Keynote: From Cloud-Native Apps to Cloud-Native Platforms - Abby Bangser, Principal Engineer

This talk explores the concept of platform optimization in software engineering, focusing on the bottlenecks that hinder organizations from delivering value efficiently. The speaker emphasizes that every system has a bottleneck, which must be identified and improved upon to enhance software delivery. Drawing parallels between commuting in Amsterdam and software delivery challenges, the speaker highlights the importance of horizontal scaling through microservices, enabling independent developers to work more effectively. The discussion then turns to the need for platforms as a service to facilitate faster deployments amid increasing constraints. Additionally, the speaker introduces the eight platform capability factors developed through collaboration with industry experts, aimed at creating coherent and operable platforms that meet organizational needs. The call to action encourages participation in the technical community to develop community standards that support platform evolution.

Hi everyone. We're going to be talking about platforms today, and we all know that what platforms goal is to help the builders in your organization move faster, safer, and more efficiently by providing them the tools and capabilities that they require. But too often as we build platforms, the people building them don't feel fast or efficient in that process. And as an organization, we have to think about

the entire system when we look for optimizations. The thing is is when we're looking at delivering value to our customers as organizations, we have to think about system optimization in the global. And when you're thinking about that, there will always be one bottleneck that is actually setting the scale limit for your system. That bottleneck is where you need to put all of your energy because no matter

how many other constraints might exist, the bottleneck is what's going to make the biggest difference in changing your ability to deliver. And unfortunately, like taxes and death, we always will have a bottleneck. We can always go find that bottleneck and continue to work towards improving it. This is what we need to think about when delivering value as an organization. And right now, platforms have a bottleneck in

their ability to deliver the tools that our organizations and builders demand. We are not getting the safe and scalable and performant capabilities into the hands of our software engineers fast enough. And we need to scale their impact. So, I want to talk about system optimization in the context of today's software engineering, but for some this is a new area. So, I want to first step back and

look at how system optimization works in other areas of our lives. And thanks to our beautiful host city of Amsterdam, we've all probably seen how many people commute to work by bicycle. It's a great way to get to the office, but nobody likes spending time commuting even if you get to do it in a beautiful city and on a bicycle. And so, what you might have noticed

is a really big increase in kind of fat tire and electric bikes to try and improve and speed up people's commutes. Problem is is that commute isn't speeding up. And that's because when you have to wait for a ferry to go across one of those beautiful canals, or you have to wait in tire-to-tire traffic in a jam, you aren't optimizing the thing that you need to. Scaling

the power of that singular bike up vertically into a higher top speed might reduce a constraint in the system, but not the You actually have to be looking at how to scale out horizontally to increase the throughput. Stepping into our world of software engineering, we need to look at the software delivery life cycle. And we're always looking to optimize this. This is And when uh few years

ago in the early 2000s, we were having a constraint on being able to deliver software fast enough to build it. And so, we as an industry started to grow. We saw expansion to the number of developers building software in organizations. But just like the commute in Amsterdam couldn't be improved by just scaling up, we were getting stuck with queues in trying to change software at scale. The

more software developers, the more pull requests into singular codebases, the more challenge at actually delivering value out to our customers. So, as an industry, we had to look at how to scale out horizontally. And one of the many benefits of introducing microservices is that we unblocked builders to work independently and produce software more effectively. Now, we know that systems continue to move the bottleneck. So, all of

a sudden, we had to think about how to deliver and deploy software more That became our bottleneck. And I'm going to talk about how platforms as a service helped us solve that, but first I want to apply those same system constraints to the software delivery life cycle today. And when we think about those truths, we have to think about them in the context of AI. It's just

a truth. We are creating more constraints in our system than ever before because of the speed at which we can deliver software. We are seeing issues with needing to train and deploy models, with how to uh teach our teams how to prompt and get valuable outputs, and of course how to review code. But we have to think about the system as a whole, and one of the

biggest constraints is still getting the tools into the hands of the builders. I mean, think about your agent going to your platform as it stands today to get a compliant and performant piece of infrastructure. I can open the ticket. I have that MCP server for my ticketing system. I can go open the ticket, but 84 years later, it will take time to get that information back. We

are not unblocking our builders. And this was never okay when it was humans, but what AI does is it multiplies the impact by tens and hundreds, and we're seeing that impact today. Now, many of you in the room have probably seen lots of power behind AI both this week and before and say, "Well, then don't bottleneck the AI. Give it access to the cloud and let it

build what it needs to." And what I would say is that's not new. That's shadow IT. And we know what shadow IT does to our organizations. It increases risk in com- in compliance, in security, and operational overload, and we are not able to sustain at pace. The platform engineering principles that we've talked about before are what allows us to um to let individuals build quickly today and

organizations continue to build quickly in well into the future. Because just like that puppy you get at Christmas, it is not just about today when we're building our platforms and our software. I've added some of my local puppies. I can tell you they are rascals, and it takes a lot of rainy walks and a lot of vet visits to be able to take care of them over

time. And we need to build our platforms with the same mindset of long-term support. In my keynote in Atlanta, I introduced these principles, strategies, and tactics as the way to achieve this through a marketplace-style platform architecture. And these resonated with a lot of people, and I've had some fantastic conversations over the last few months. But organizations are struggling to implement them in isolation. If you try to

apply these as a project to improve your platform, you quickly run out of both budget and patience because there is just too much to do, and you're not thinking about the constraint in your system. The constraint in platforms continues to be access to the capabilities that your teammates and your organization requires. We have to focus on the bottleneck in platform engineering of extending the supply of capabilities.

Now, the question is is how do we unblock this? Do we scale up vertically or out horizontally? Vertical scaling would look a lot like that in the early 2000s of software delivery. We could increase the number of platform engineers. And that's great for job security, but we all know that it wouldn't be very enjoyable even for all of those new platform engineers because we end up in

queues when we work with architectures that are monolithic and can't be worked on by any more humans. So, what does horizontal scaling look like in platforms? It looks like allowing the capability providers and the experts in your organization to independently deliver value out to users. Allow your data specialists, your compute specialists, your networking specialists to independently work and deliver value on the platform while your platform engineers

are removing all their restrictions and enabling them go to go straight to the users, but to do so in a coherent way. This is where my keynote back in Atlanta left off. We need the architecture of a multiplayer marketplace uh platform that allows for people to self-serve both producing capabilities and consuming them. But what I've been hearing is that while this is an agreed approach, many organizations

are struggling with how to approach it, how to succeed. So, we can step back to that world of software delivery into microservices and see how that worked and see if we can take some of the learnings. So, if we return back to the early 2000s when we have all this explosion of new software and we need to think about how to operate it and deliver it, we

have to think about what it means to put a piece of software on top of infrastructure. We had platforms as a service coming out and taking a lot of that heavy lifting for us, helping us deploy that software faster and more scalably. But they were doing a lot of heavy lifting because all of the software was really unique. We challenged with managing state management and um you

know, telemetry and all these operability aspects of delivering software. Each application was unique, and the platforms were struggling to make that a coherent experience. That was until 2011 when Heroku sat down and said, "What would it mean to have a application that was a good consumer citizen of the platform?" And that's what they codified in the 12-factor app. These 12 factors, you may have seen, you may

not have, but a lot of them will feel familiar because the operability that they allowed for in the early 2000s continues to be the base of how we deliver software applications today. This list doesn't guarantee that you're going to be profitable, doesn't guarantee that your applications are going to be useful, but it does give you the opportunity to iterate until you achieve that. It gives you a

way to quickly and effectively deploy software. And when you adhere to this good citizen list. Now, if we apply this to platforms, we might need to think about the fact that we now don't just have consumers of platforms, we have producers of capabilities on the platform. So, what does it look like to be a good citizen as a producer? I'd argue that we're in the let a

thousand flowers bloom phase of that work right now. We have a number of projects that actively encourage contribution models, but what looks good there? Some are pull requests, some are plugins, some set standards, some allow anything to happen. We're all trying to figure it out just like the platforms as a service were in the years past. So, if we want to introduce this idea of a producer

API that allows people to build operable capabilities to scale out our ability to provide value to our what a good producer citizen looks like. And just like in the in 2011 when Heroku wrote that down, we have plenty of knowledge across the industry right now to solve this. We just need to have the conversation. And a couple months ago, I sat down with my team at Syntasso

and we did just that. We captured our learnings and reached out to our network and found out that this resonated. That organizations around the world were trying to build marketplaces and they were each building their own uh definitions of what it means to be an operable capability on a platform. So, since then over 30 different people in industries around the world and within this community have reviewed

and helped refine these. They've been generous with their time and their experiences. And we've landed on these eight platform capability factors that help make a coherent platform that is unblocked to allow multiple con- contributors. That QR code leads to not only more information about each of the factors, but also a way for you to contribute. Because now is the time if you're building platforms to get involved

in the technical uh the platform technical community group because it is active as it ever has been. This group has released a white paper in 2023 and an uh platform engineering maturity model in 2024. And of course, we've learned so much since then. And so, we're working on a version two to codify that learning into new uh releases that can continue to help the community while also

extending what we work on including the platform producer factors. So, please come get involved because we've been talking about platforms forever. People are probably sick of them. They're they have their own hype cycle, but it's 2026 and we know that we need to unblock our organizations because whether it's humans or agents, we are building software at a pace that we haven't seen before. And they it we

still need to worry about keeping that software secure, scalable, and performant. So, we need platforms that codify what that means in our organizations. So, I encourage you to come into the conversation and build a marketplace architecture for your platform that allows your organization to be unblocked. I've seen this work across the world. And while the future is here, it is not evenly distributed. And I have every

faith that as a community, we can make it easier for organizations to apply these ideas by having community standards that support projects across the ecosystem. Thank you so much. >> [applause]