00:01:40 · Chase Roberts
[00:01:40] S1: Yeah, that's a good question. So let's start with what PaaS got right. And the thing that PaaS or the Platforms as a Service got right was fundamentally the focus on developer experience. What are developers actually here to do? They just want to ship workloads, get those running in cloud infrastructure, and not have to worry about the underlying complexity. And some of the pioneers, you know, like, Heroku and and Cloud Foundry, think, really nailed, like, that vision. But the place that a lot of passes didn't succeed or the thing that they got wrong was the ability to support multiple different types of workloads, so workload complexity. And then, you know, as you... You know, for a lot of these companies, as they think about like adopting a PaaS, they have this trade off that they have to contend with, which is, hey, on day one, this is great because I can just get going really easily and, you know, trust that the solution is just gonna kinda hide some of the complexity and make it possible for me to ship workloads. The... But they but they do so knowing that, you know, in kinda the back of their head, there's this other trick... There's this gonna be this day where they're gonna have to graduate, quote, unquote, off of the PaaS and, you know, rebuild everything and kinda build their... You know, adopt cloud infrastructure, lower level cloud infrastructure from, AWS or GCP, etcetera. And that's largely what we've seen with a lot of PaaS players. Right? Companies adopt them, you know, to get stuff going very easily, but then they outgrow them. And then I would say the other thing that PaaS solutions, like, you know, failed to get right was the idea of bring your own cloud. AWS and GCP and Azure and Oracle and all the managed cloud providers have piled billions of dollars of resources into making, you know, very scalable, resilient infrastructure. And so trying to reinvent that and and kinda take the nice economics of of being able to contract directly with them away from customers, I think is a bit of a challenge. Most companies want workloads running in their own clouds. And so I think that the other thing that a lot of past solutions missed was really just this idea around bringing on cloud.
00:03:38 · Sylvain Kalache
[00:03:38] S0: What's interesting is that you you you went directly with the the term workload versus application. And I think also one of the things that PaaS focused on and did well to a certain degree was to us 12 factor apps. But there is actually way more than that, right? Like its path was like failing because once you wanted to run more than this, like there were simply no options. So what type of workload do you see your customer are running today and which one do you think should add the same frictionless deployment that you wanted to offer?
00:04:18 · Chase Roberts
[00:04:18] S1: It's so interesting because if you think about how people approach PaaS or framing that people have for PaaSs in their heads are these are the solutions for my federal workloads. And whether that's a PaaS that they're buying off the shelf or whether it's something that's built internally, they think about it as like, oh, this is what I use to deploy my services. And you double click in a lot of companies and you ask like, okay, well, do deployments work Yeah. Depending on the workload type, it's usually something like, well, you know, for these services and these cloud endpoints, it's this set of infrastructure or this deployment path. But then if we're deploying it to this cloud or or if it's like a database, you know, we file a Jira ticket and someone does that for me, and I don't really know how that works. And realistically, an application is not just the ephemeral workloads. It's, you know, some combination of my services, my databases, my scheduled workloads. And, you know, from my point of view, and then why I use the term workload, you need all of those working together and deployed and running in the cloud. And so it makes sense for us to treat all of them equally. So And really a workload is just anything that can be containerized, which includes databases and obviously includes scheduled workloads as well. So jobs.
00:05:30 · Sylvain Kalache
[00:05:30] S0: Coming back to the point where you say that this giant cloud company builds infrastructure to efficiently deploy workload at scale. I think the platform engineering is a lot about this golden path, which are becoming increasingly complex, right? It's not just scalability and reliability, but today we're adding many layers like security and data compliance. You have more and more compliance law after Europe started GDPR. So how do you see this web of complexity playing out for platform engineering teams?
00:06:09 · Chase Roberts
[00:06:09] S1: There's not a perfect answer here because realistically, the tools that they have to manage this complexity is... Aren't, like, aren't the best tools. And if you look at what's available, let's think about what it means to build up, like, a path of production. It means I need something for CI. I need something for my deployments. I need something for my day two operation. So, you know, when I'm scaling my workloads and I... You know, turning on backups and server redundancy and things like that. The challenge is that all is, you know, made up of a bunch of different tools and a bunch of different open source technologies and then a lot of YAML, a lot of Terraform, a lot of custom code that only the authors who wrote it understand. And so when that is a set of building blocks that you have, like, the complexity is always gonna exist. And then, you know, and and then to layer on top of that, if I'm a, you know, if I'm a DevOps team or a platform engineering team and I build this platform and I get everything starting to work, then I have the problem of giving my developers that quote, unquote golden path that they can make sense of. So, yes, I have this automated deployment path, but is it the right abstraction? Is it the right, like, interface for my developers? Probably not. Like, whenever we're talking to teams, you know, that we... You know, if the platform initiative is is somewhat mature and they're actually, you know, getting all these tools working together nicely and, you know, not too many people have left the companies and they always have... Know the one person who understands the technology and how to make sure that, you know, this YAML file works a certain way. When you get to the developers, you're like, well, is it working? And they're like, well, I don't understand it. It's too complex. Yeah. I I spoke to an enterprise this morning that that said to me, they're like, we've built the platform. It's amazing. We're so impressed with ourselves. We can't believe we pulled it off. It took us three years, but it takes six months for a developer to get to the point that they can use it because it's so complex to use. And you're like, what happened here? Right? And and so fundamentally, it's a it's it's an impossible task. You know, it's almost a a forlorn hope, which is a term that my CEO use...
00:08:09 · Chase Roberts
Uses to describe this a little bit, which is like, you're kinda doomed from the start because the tools that you have just aren't great. And so then it, you know, it it raises the question, why are we trying to reinvent the wheel every time with a platform by starting with all of these low level primitives and trying to assemble them to build the platform, and why not consider buying a solution? And so I I think that that turn is starting to happen when we're talking to buyers. They're like, look. Our customers don't pay us to build platforms. We don't get to charge more for our banking app or our, you know, our AI app this or our construction app or whatever. We don't get to charge more by investing, you know, millions of dollars or thousands of dollars into a platform. We get to charge more when we ship great features. And any dollar spent on growing the platform and expanding that function just hurts margins. That's it. And it would be easier to justify if it wasn't such a big tax in our organization and our developers loved it and it worked. But realistically, that's not often the case. Know, way, you know, And, coming back to the idea of golden path to production, the problem starts to compound itself a little bit too, because we're also hearing more about multi cloud. And I think for years, we'll call it, you know, maybe if you talk to anyone, you know, call it sooner than four years ago, and you say multi cloud and people kind of laugh like, yeah, no one's really doing that. Now people are, right? And they might have one cloud that's the one that's most favorable, but they generally will have workloads running in multiple clouds within an organization, and some of that might be on prem. And and if you're building the deployment path and and focusing on building the platform for all the different clouds, it's actually different depending on the cloud. And you make a change to, you know, one... You know, the logic in one of your platforms, and you just have to go and redo that over and over again for all the different, you know, deployment endpoints. And that's kinda crazy. And it just becomes like a really, really hard task for teams, especially if you're trying to create a consistent golden path to production.