Welcome to the Cloud Native in 15 Minutes podcast. If you haven't listened before, the goal of the podcast is to explain some strategic and sometimes complex enterprise IT subjects in about 15 minutes. This episode runs longer than that, so I'm going to keep the intro brief and just say I'm Derek Harrison Pivotal. My guest this week is Cornelia Davis, Vice President of Technology at Pivotal, and we talk all about platform as a service, containers as a service, even touch on functions as a service, aka serverless, and how and when it makes sense to adopt all of these things. I think it's a really informative episode and I hope you do too, so stick around and listen to Cornelia Davis educate you on platform as a service and containers as a service. Okay, Cornelia, so to get started, can you define at a high level what we're talking about when we're talking about PaaS? I always take like, I take it to mean like a cloud foundry level of platform as a service, right? Not some of the kind of subcategories that I've seen thrown around. Yeah, and even before we get to the subcategories, I think the place that I would start is that, you know, platforms have been around forever. We have the former platforms were things like WebLogic and WebSphere and JBoss and, you know, maybe even Tibco and things like that. But I think that where we moved to when we went to PaaS was, I think the as a service part is really important because platform as a service was all about enabling a certain class of people, we sometimes call them developers, to be able to get the things that they needed to be able to get those platform capabilities as a service. So it's all about autonomy. It's all about enabling those, that group of individuals to get what they need to be able to deliver value through software with minimal friction. Okay. I mean, and how would you, when you look at this, at this, at this space, right? You're right,
2:02because application platforms have definitely been around for a long time. And I think when Heroku and Google App Engine and some of the, and even Microsoft Azure, I think early on, right, they were kind of focused themselves around this idea of platform as a service early on. But how have you seen that space change, I guess? I mean, it's been around since God, probably a decade at this point, right? Yeah. Yeah, I think it has been. And, and you know, it's, it's really interesting. I'll share with you my personal perspective on that. So I started working with platform as a service, but gosh, more than seven years ago, I was at EMC working in the corporate CTO office on architecture and emerging tech. And while platform as a service, you know, from things like Heroku and stuff have been around for 10 years, really getting entrenchment in the enterprise, really getting broad adoption beyond the, maybe some startups who were a little bit ahead of the curve, didn't happen 10 years ago, that really started happening later. And so when I first started working with this, what I found that was really interesting, because I didn't know what PaaS was, and I started Googling, and I started reading things. And it was all about enabling the developer, which is kind of what I just said a moment ago. But I was super confused, because I was thinking, okay, there's all these predictions of this massive market for PaaS. And are they really just trying to make my life easier? Because I come from a development background. So I'm like, really? Is it just about making my life easier? And I think initially, that was where our thinking was. And I think that to a large extent, the offerings that came out was initially from this perspective of it's all about the developer. And the funny thing is that we still talk about the developer. We still use the term developer. And if you could see me, you could see that I'm actually putting air quotes around that. Because what I think we've learned, and so what has really changed is that our understanding of the potential value that
4:08something like a platform as a service can bring, goes so far beyond making Cornelia's life easier, making the developer's life easier, and takes you all the way to the entire life cycle of the application. So it's not just about development, but it's actually about deployment to production, operating in production, resilience in production. And even the developer workflow is considered a production activity, because as soon as that environment goes down, then you can't be shipping features anymore. And so I think that understanding that it's not just about making the developer's life easier has led to a maturity in PaaS that now allows us to focus on things like security and operational effectiveness and resilience, which when I first started studying this seven plus years ago, nobody was talking about it. It was all about making the developer's lives easier. So I think that that's one of the big differences. So what are some of the pros? I mean, you referenced some of the pros, obviously, but what are some of the pros and cons of PaaS relative to managing applications from the server on up? I assume a big perceived drawback is that a PaaS platform, they're perceived as too opinionated, right? But correct me if I'm wrong. Yeah, no, I definitely think that PaaS platforms, some people think that they're too opinionated, and others are actually delighted by that. I mean, I would say, honestly, a lot of Pivotal's most successful customers are delighted by that. But I mean, I think perhaps one of the best examples right now is Capital One, right? So the Capital One breach from a few weeks ago, what that was, was an IAM rule. So an identity and access management rule that was misconfigured. Now, I actually don't hold the person who configured that rule that way responsible for that. Because honestly, that's one of those things where IAM rules in an environment like AWS, where there are so
6:12many moving parts are extraordinarily complex to configure. And that's the risk, that's the tension that we've gotten into with PaaS, or with more, actually, maybe not so much with PaaS, but with, you know, developer empowerment, is this, we've gotten into this notion that, well, okay, we're going to enable the developer. And so the developer is going to be this full stack developer. And they're going to know everything that they need to know to properly secure, to properly deploy this in such a way that it's resilient to regional outages, and et cetera, et cetera, et cetera. And while I do believe that the developer has to take on responsibility, for example, some responsibility, for example, they do need to know how to build their application architecture so that it can be deployed across regions and operate across regions so that if a region goes down, things are still up and running. So that set of cloud native patterns, they need to understand. But if we, for example, if they're doing that deployment on IaaS, or in an environment where they are given the responsibility to configure complex IAM rules, it's really our fault in making that assumption that that can be done in a reasonable way. And so what I like to say is that we have to partition the set of activities that need to happen to run, to develop and run an application into, in production. We need to partition that in such a way that the experts that know about security and compliance and, you know, HIPAA doesn't go away because we've, you know, enabled developers, but we need to partition that platform in that space so that the X, that we, we give kind of a surface area to the experts in these various fields. It's not that I'm suggesting that developers don't care about security. They care. But do we want them, do we require that they be experts? Well, that's just asking
8:16for a world to hurt. I take what you're saying to be that security, at least in the IAM part of it, right, can be something that's enabled at the platform level and not, not at the, at the developer level, the application level. Yeah, that's right. And those opinions are in fact, exactly what not only makes developers' lives easier, or in some cases they think harder, but it is actually what makes the overall, remember I said, it's not all about the developer. It is about the entire business. It's about making sure that we can operate these things securely and effectively and all of that stuff. And so those opinions aren't there to constrain the developer. They're actually there to, for example, enhance our security posture. And that's hugely valuable. Okay. And I mean, this might get into some of that, but I mean, how, so, so how do you think, when you think of PaaS, you know, in, in relation to some of the other things like, uh, IAS infrastructure as a service, IAS, I guess, or containers as a service or microservices, there's other things where it tends to get, uh, kind of grouped together. I mean, how do you, how do you think about, I guess, that relationship between, between these various things? Yeah. Well, I mean, of the things that you listed, so microservices, for example, I think that microservices and PaaS really do go hand in hand. Um, it, could you have a platform as a service that isn't optimized for microservices? Yeah, maybe. And maybe it's just, I don't think it's coincidence, but I think actually the emergence of microservices required that we have a new set of platforms to be able to enable those things to be deployed and effectively managed. Um, and then I think the emergence of these platforms has also kind of, uh, accelerated or ramped the emergence of microservices. So it's a bit of a chicken and egg thing. Um, I think that they, they're very synergistic and I think that therefore they have, um, kind of evolved at the same time. Um, the IAS thing is, is interesting
10:21because, um, I have been in the EMC VMware pivotal family for gosh, almost 20 years now in some way, shape or form. Um, and, um, I always like to talk about the fact that it was VMware that really was at the forefront of virtualization technology, but it was Amazon that changed the game when they added the, as a service. So VMware was not a, you know, IAS company, they were a virtualization company. And then Amazon is actually what made us all realize that, holy smokes, I can actually get infrastructure as a service. So to some extent, clearly this, as a serve a service model that kind of started in the IAS space. And I mean, it, one could argue, I I've, I've studied a little bit of the history and I think that Google's foray into the, as a service actually came with app engine. Right. So they didn't start with IAS. They started with app engine. So, um, but I think that Amazon was arguably the most successful and they started with infrastructure. Um, so I mean, they're very different because IAS is compute storage and network. It is an infrastructure abstraction. And so when it comes time to secure something while you're securing against machine boundaries, not against applications and those types of things. But I do think that the, as a service part really helped inform that. Um, okay. Do you think, why do you think, I mean, I think actually Microsoft Azure initially started as a, as a platform as a service thing too, at least the original vision was. I mean, why do you think it's, it seems natural. It seems like a natural thing for developers to want. And yet they had, they both had to go back to IAS. Do you have a sense of why? Yeah. I mean, I, I actually think that they were maybe just too far ahead of the game. Um, I think that, that, that remember when we talked just a moment ago about microservices and PaaS
12:22platform. Um, I think that, uh, initially there wasn't enough of an understanding of what are the new architectural patterns for things that are going to run in an as a service environment. Now at, when I say run in an as a service environment, what do I mean by that? Well, I'm actually kind of talking about these new as a service cloud-based environments where, um, where things are always, they're in constant flux. I've been in the industry long enough. I worked for Documentum for a while. Documentum was a piece of software that was built expecting the infrastructure that it ran on to remain stable. And if the Oracle database that you depended on for Documentum to run went belly up for any reason or needed to be upgraded for any reason, or, you know, needed to be migrated from one data center to another, well, that was a major event. There is no way that the software running on top of that database could survive could stay running during that transition. And so that's the way we've been building as developers. That's the way we've been architecting our software, building our software. And so if you'll permit me, I'll just mention that I recently published a book with Manning called Cloud Native Patterns. And the subtitle actually, I like even better than the title, which is designing change tolerant software. And so back to your question of, well, Azure and Google started with these app engine metaphors. To a large extent, those had an expectation. It had some of these opinions we've been talking about built into it. And I just don't think that there were very many apps that were ready for that. And even today, I still find lots of interest for an
14:23understanding of what actually, what are those cloud native patterns? That's why I wrote a book on it. I think you're onto something too. I used to ask that question a lot. Like when cloud came around, it was, when are we going to start building new types of applications to take advantage of this? Because for a long time, it seemed like same application running on Amazon and somehow we expected things to be different. And so I think we're catching up finally. One thing we haven't talked about yet is containers and probably more specifically container orchestration. So I want to get to that because I think that that captured over the past few years, some of the paths, mindshare, and maybe there's been a conflation of the two, right? Like there can be only one or the other. Can you talk a little bit about that relationship between containers and container orchestration and platform as a service? Absolutely. So I, that's where I've been spending most of my time for the last two plus years is in the Kubernetes space. Having had kind of a long background with, with our, you know, PCF and our paths and cloud foundry platform. So this is an area that I'm very, very passionate about. So you are absolutely right that containers and container orchestration has captured the mindshare. Now I'll tell you, it's interesting. We need to kind of separate those two because I was working on paths a number of years ago, you know, four or five years ago when Docker and containers became really big. And there was this wave where everybody thought that the days of paths were over because we now had Docker and we now had containers. And I'll tell you that that petered out pretty quickly. We did have, I would say maybe six months where we had, you know, that was kind of quote unquote competitive, if you, if you will. But because it was just containers, it very quickly became apparent that you needed more than just containers. You needed a whole bunch of stuff around the containers. And in fact, that's what a paths is. So certainly the cloud foundry paths has been container based all along. It predates Docker, but it's been container based.
16:28So I actually believe that containers are a prerequisite for being able to build a modern paths like we've been talking about here. So that, that, that came and went and people kind of got the difference. So, but one of those things that you need around that is container orchestration. And now with the advent of Kubernetes being so popular, and there's a good reason for it being popular. Kubernetes is crazy cool technology. It is, it's a set of primitives that you can just build so many awesome things with, but that's the key is that you can build awesome things with it. People like Kelsey Hightower and Joe Beda, two very, very influential people and knowledgeable people in the Kubernetes community, both talk about Kubernetes being a platform for building platforms, not a platform itself, not an application platform like paths. And so CAS is really interesting. And there are some use cases where you might want to use CAS. And I'm guessing that we'll probably go there and talk a little bit about those. But the main thing that I think I would love your listeners to understand is that CAS is essentially an infrastructure dial tone. So when you are dealing with Kubernetes, you are dealing with things like pods and you are dealing with persistent volumes and persistent volume claims and load balancers. They call them services, but a load balancer is a type of a service. So you're still largely dealing with infrastructure abstractions. Yes, it's an up leveling from compute storage and network. It isn't just those broad things. It's not a machine in the same way that we've always thought of machines. It used to be a physical machine. Now it's a virtual machine and it has
18:29every single thing that the physical machines had. We're starting to break those things up into an abstraction layer where we can compose them in interesting ways, but it's still fundamentally an infrastructure abstraction. So PaaS is all about bringing that abstraction up to a level that lets the infrastructure details fall by the wayside, that lets you apply controls to those, but then they aren't first-class concerns that's already built in. And Pivotal offers both a PaaS, which we call PAS, not P-A-A-S, right? And a Kubernetes-based product. I mean, so why is it that, like, yeah, I'm curious, as you mentioned, like, why would someone opt for one over, given that choice, if it must be a choice, and maybe it doesn't need to be a choice, why would someone opt for containers over a PaaS offering? Yeah. Yeah. And I think that it comes back to, there are definitely cases where you aren't going to want to run something on the PaaS. And I think it takes us back to this conversation that has, kind of theme that's been running through our conversation, which is around cloud-native apps, or microservices, we sometimes call them, and about these patterns for applications that are designed to allow for the infrastructure to be moving, to shifting around. So I always say that cloud-native apps are highly distributed and constantly changing. The environment's changing, the apps themselves are changing. And so there are a certain set of patterns. And platform as a service is, to a large extent, playing a big role in intentionally trying to up-level us into this next wave of application architectures. But there are a lot of workloads out there that don't fall into that category, that are existing workloads, that maybe are not as resilient to changes at the infrastructure level, maybe require a little bit less opinionation than a PaaS typically has, yet they can benefit from
20:37containerization. I mean, for example, one of the benefits of containerization is that you, what we in the DevOps community call shift left. So a lot of the things that you typically would have done and configured at the time of deployment, you can actually make those decisions and start to put some of those things and go through some of those processes of verifying that even things like compliance can be met while you're building the container. And then you sign the container and you to ensure that it's never changed. And so you have this abstraction that allows you to say, okay, I did some checks when I signed this container and nothing can change since then. That's one of the benefits of containerization that applies whether you've got a cloud native app or not. So containerization and then orchestrated containers around that can actually benefit existing applications that are not necessarily cloud native. And so there's a category of workloads. But the interesting thing is, is it's not, I always like to point out as well that it's not only workload. It's not only the application architecture that determines where, whether you want to run on Kubernetes or you want to run on something like Cloud Foundry or some kind of a PaaS. It also depends on things like your skill set or whether you already have containers. So there are organizations out there where they have tooled up processes for creating trusted containers. And so if they have cracked that nut, which by the way is not a trivial nut to crack, that's a big part of what PaaS offers is it actually helps you create, it provides a trusted container pipeline with which you can actually go through this process of creating these trusted containers
22:37built into the platform. But if you've already tooled that up, why not continue to use, leverage that investment that might've been a two-year investment in an organization. So they're already creating containers. And so they want to continue operating that and they need a place for orchestrated Docker containers. So if you've already got investment there, or we're also seeing independent software vendors are taking advantage of some of those advantages that I just talked about. They're saying, hey, gosh, you know, it used to be really hard for me to deploy, for my customers to deploy my offering because there were so many configurations that needed to happen once they got the compute storage and network that they needed. Well, we can start to apply some of those configurations in a set of containers that work together cohesively as a whole. We're going to start using containers as a distribution mechanism for our software. And so there's another use case for maybe running on something like a container as a service as opposed to a PaaS. And then finally, Cornelia, I wanted to ask, like, you know, and we could probably lump even something like functions or serverless into this discussion, right? But if I'm an IT exec and I'm looking at this collection of abstractions from infrastructure to application to whatever, and then, you know, that may or may not, you know, merge and converge as the years go on, like, where does it make sense to jump in today? Like, what's my guideline for? Okay. Well, like, even where do I, I hear about Kubernetes all the time, but maybe, maybe, maybe I, maybe I need to jump in there. Maybe we need to jump in a PaaS, like maybe it's functions, right? Like how do I make that decision? Yeah. Yeah. So I, I think actually at the highest level, the answer to that is super simple. Where are your biggest pain points? So this is all about value creation. And I think that's one of the biggest challenges in an industry, and especially right now where there is this crazy cool technology
24:40that everybody's in love with, like I said, with good reason, is to jump into it, you know, based on FOMO, fear of missing out. And that right there is not the best way to go into a new technology space. It's look at the problems that you're, that you need to solve to generate value for your business. If you are, let's take functions as a service. Functions as a service, I consider that just a flavor of PaaS, if you will. It is, and, and what's, what's unique about FaaS over the PaaSs that have been around for the last several years are really, I see it as two things, the economic model. So it's this, like, you only pay for things as the compute is happening. So only as the function is executing. So there's an economic model, but let's put the economic model to the side. The other thing is events. It is at the core, kind of the, the, the spinal cord of FaaS are events. So if you are a company that has, that is generating value for your consumers based on things that are naturally represented as events and the event stream is the primary entity and you need to do things against those events, then perhaps FaaS is exactly the right place for you to start. If you are taking legacy client server desktop applications and building a set of web, you know, web apps for that, then my recommendation would be your best thing is PaaS. If you want to, you know, take legacy workloads and just get them running, you're having struggling with infrastructure and you just want to get them running in a container environment because you can do things like, um, at least put image scanning against container images for some level of security, then perhaps CAS is the place to start. So it's really
26:43to do that evaluation of where do you need, I ultimately think you're going to need all of those things because every enterprise has all three of those problems that I described, but where do you start? Look at where you're going to get the biggest bang for your buck in terms of value creation. All right. And that seems like a great place to end. Thank you so much, Cornelia. Okay. And there you have it. I hope you learned something. I certainly did. We're going to keep this brief because everyone's from Pivotal. So if you want to learn more about Pivotal and what we're doing in the platform as a service and container orchestration space with Kubernetes and functions, et cetera, check us out at pivotal.io. And if you like this podcast and you want to read blog posts and highlights of the podcast and, and other type of, you know, vendor neutral yet, uh, hopefully informative, uh, content regarding your digital transformation efforts and cloud computing and the like, you can visit pivotal.io slash intersect. Thank you very much.