Can ”PaaS” Be Saved, Or Is It Gibberish Now (Ep. 23)

Episode 10 · 2016-06-13 · 46:12 · SRT · archive.org · all Tanzu Talk

Well, we've hit our third episode, so that means we have Stanima. It's actually going to happen. I think the next benchmark is episode seven. Then you have episode 10, and from there, it's just pure glory, just like chariots and roses being thrown in front of you. We've proven we can commit. That's right. We've figured it out. I've been moving the old podcast stuff to have a little administrative meta talk here from Libsyn to SoundCloud. Man, it's just, you know, sometimes I wish I could get software developers and be like, hey, you should start being a user of the thing you're writing and do that. I mean, you know, to be fair, SoundCloud's right for musicians. But I think they have enough of a podcast audience that they've got like RSS feeds and stuff like that. But one would think that if you wanted to have customer acquisition, you would find maybe like the top 10 or top five other podcast hosting companies and say, why don't you give us your RSS feed and we'll import all your stuff? No, no, no. Of course they don't do that. That's, you know, between WordPress and Tumblr and Squarespace over in blog land, they're all pretty good about that. But, you know, podcast land, not so much. Like we talked about last week, lock in and migration is a thing. That's right. That's tough. That's right. There's a regular first world problems there. But anyways, it is always fun to also see the stats, how they're differently done between the two hosting things. But the whole point of that, other than me just having something to talk about, is we've got this stuff hosted in SoundCloud, which really shouldn't affect you that much at all. It's got more interesting visual stuff, if you like that. But also, I finally, don't tell anyone, but I never actually added this podcast to iTunes. So I added this one, Pivotal Conversations to iTunes. We have like the catch-all thing for Pivotal Podcasts and iTunes that has every podcast that we do,

but not an individual one for this. So now you can subscribe to just this if you really want to. It's a glorious day. So what have you been doing this past week? That's right. The world breathed a collective sigh of relief. That's right. Yeah, luckily I was in the San Francisco office last week, so it was fun to hang out with my folks. And the common question is always, what are you doing here? Which makes me feel welcome. So we've got some time with, watched some customer briefings. We had Forrester in for half a day talking about our space and trying to learn a little bit and just listen a little more than talk. So good chance to get a little refresher on what our real positioning is and how we help our customers best by trying to define a very muddled space. Indeed. Indeed. Well, this morning there was big news that Microsoft is buying LinkedIn, which is just so strange that it's worth talking about. I mean, I would have never thought about those two hooking up with each other. No, I mean, I guess they endorsed them for large acquisitions. I don't know. There's a million dumb LinkedIn jokes going around. I know. It's terrible. I didn't involve Clippy, which at least upgrades this conversation a little bit. But no, I mean, they've obviously flirted with Salesforce in the past. You know, there's all kinds of different talk about this. Twitter get acquired by someone like this at this point. So, yeah, I don't know if LinkedIn was on the radar for that stuff. But if you take a deep breath and look at it, ignoring how much they paid, there is probably an interesting play with what they do with Office 365. They highlighted a lot with Dynamics. So when you're trying to, you know, do real CRM and have links to a very impressive social graph and LinkedIn, that's interesting stuff. Now, are you going to monetize that additionally? Or does that just make you stickier? I guess that's what we'll have to find out. Yeah. I mean, as you're alluding to, having worked in M&A a little bit in the past, as Coté podcast bingo players will know, you know, it's always important to go read the official words that people say about this stuff, at least for what the deal rationale was.

Like, what happens like 12, 24, beyond months out? Like, who knows what's going to go on? But like you mentioned, the two things that were mentioned on the Microsoft side the most were basically Office and Dynamics. And Dynamics is, you know, I don't know if I've ever actually seen it, but it's like their CRM, small to medium business, back office product line, as I remember their Great Plains acquisition from long ago. No marketing, in terms of like, nobody knows it. Right, right. Good product. Yeah. And, you know, so that's the first thing that sort of makes sense is essentially, and this is all sort of like, as deal rationale usually is, or public deal rationale, happy path thought. But like, you know, basically, if we assume that the, I forget however many million, but that most of the white collar workers or a huge amount of the white collar workers you would want to sell to are our users of Microsoft software. They're in LinkedIn, mildly active. I'm sure there's some, I don't know, medium chubby tail of activity or things like that, but it's basically a huge channel that's kind of bi-directional. That is a group of people or eyeballs, as we used to call them, to sell stuff to. And, you know, you could sell more office and more dynamics and all of that sort of stuff. And, you know, sure, that makes sense. There's a company here in Austin in the systems management space called Spiceworks that has a similar kind of channel business. Like, you look at it as a user and it's basically this free network management, systems management asset thing, right? Sysadmins use it to like scan their network and find everything that has an IP address and check the overall health of it and then do some basic diagnostic stuff. And it's like free. So you're like, how do they make money? And the way they make money is because it's free. They have, I think it's pretty legitimate that they have millions of users of it. And that's like a channel that people would want to sell stuff to. So vendors come up to them and sell stuff to them.

And, you know, it's blatant banner advertising. I mean, maybe we'll see this in Office. It would be interesting if there was a free version of Office 365 supported by, ads or whatever, but, or maybe there is already. Anyways, shows you what I know. But, you know, so there's banners for, you know, like, I don't know, backup your servers to the cloud. And then there's more clever things that Spiceworks has, like Intel has these plugins that they somehow pay for that if you have their Intel chips and the servers you're monitoring, you get this extra functionality. So, you know, whatever it is, their V pro or I don't even, I don't know what Intel has, but, you know, you get this extra functionality, which is a little, well, it's a lot easier to wrap your hands around because you have detailed reportings, but it's sort of like, it makes your Intel customers want Intel more, hopefully. So anyways, all sorts. And, and then the classic two examples are like, they know when you need to buy a new printer ink, so they can refer you to that and collect some, some payment. And they know when the warranty on your servers is running out, so they could have you renew that. So using that as a structure, I could see that you have the social network of LinkedIn and there's all sorts of stuff you could sell to them that might be interesting, but, you know, who knows? Yeah. And don't forget some of the aqua hire part of this too, is, you know, they have a lot of data scientists on staff. They did all, they originated Kafka. So they have a lot of very smart distributed systems people. So clearly 26 billion is a lot to pay for people. Clearly that's not what they were just buying, but you know, from all accounts. And if you read their engineering blog, LinkedIn does some pretty cool stuff. So it's nice to pull that at the house. Yeah. I've, I've, I've been collecting a lot of, uh, reasons or that you, you know, synergies if you will. And, and I, I do it for one of the other podcasts. I do software to find talk because I'm sure we'll talk about it then. But I, I listed out some raw notes in, in, uh, my, my semi-weekly, uh, newsletter that I said, I'll put a link to it here. But yeah, I think, I think there's sort of like both of these companies have lots of cloud

competence, competency, both at, well, I assume LinkedIn has it at the infrastructure layer, but definitely at the SAS layer and infrastructure layer, uh, collectively. So that's nice. And yeah, I, I mean, it's, I think the other one that's worth mentioning is the idea of identity, which, which, um, as I was noting, uh, in my newsletter, like, I think for as long as I've been in the space where people talk about M and a back when I was an analyst and when I was actually doing it, like everyone always kind of fantasizes about owning identity and it's never really panned out this. So, so the idea, for example, of many years ago, one of the potential threats was like, Oh my God, Salesforce, they control all these identities. So they could be like your active directory in the cloud or something like that. And, you know, that's interesting to think about. I mean, there's things like, if you look at the, um, built-in accounts you can have in, as we call it now, Mac OS and iOS, like LinkedIn is one of them along with like Facebook and mysteriously Vimeo and Flickr and other things like that. But so it's, it's, it's a way of logging into things. And then, but what, what makes it more credible to think about is that, well, Microsoft owns active directory, which is more or less the king of identity in the business space. So I don't know, that could be something. Yeah. No, no. Very interesting. I know it's, it's easy to go look at the number and say, they paid a 50% premium and all this kind of stuff. But you know what? Microsoft had a ton of cash sitting around, not doing anything. Yeah. At some point, maybe it's worth investing it on some flyers. Yeah. And no, I like, I like the way you, uh, you started off. It's like, well, putting aside if they overpaid or not, cause that's, that's, uh, making that judgment always takes a lot more than the, uh, the time you have for all these little hot takes about it. Like you've got to put together a model and figure out revenue and IRR and like all this stuff that really becomes like, cause it was like, what was it? Like 26, 24 billion or something. I mean, that is, I don't even understand numbers that big.

That's no, it's not digging through the couch money or anything. No, it's legit. That's, it's one of those big couches. That's like in an L shape, not just, not just a love seat. That's right. Anyways, it'll be interesting to see what, I mean, it still has to close and everything, but, uh, I, I think, uh, you know, in addition to my genius raw notes about why it's good, the, um, the, uh, the deal rationale PDF, which I mean is PR stuff, obviously since it's public, that's, it's actually a pretty good one. And, and, uh, it's worth checking out if you're curious about this stuff. Yeah. I'll have to take a look. So also, uh, I, I, I think you, you sent over an article, uh, from our, our, our coworker, uh, Peter is interviewed in it going over the recent release of spring. And, uh, you pulled out one of the things that we pay close attention to that is that there's like 4 million downloads a month of spring boot. And this is, this is a point that, that we like to make a lot is, you know, in, in the cloud native space, this is one of the major ways that people, one of the major components people are using to, uh, basically start off and package and manage their Java applications and, and maybe other types of applications that they're doing. But there's a huge amount of momentum by download around that, which, which is, uh, an interesting one to track. And so I w I would, you've been around here long enough. I was curious to hear your explanation of what spring boot is. Cause it's always, everyone always has a new, uh, I remember when Josh long demoed it to me, like the first, I think the first week when I was on the job, I went out to that Howard street office and he like, he captured me for like two hours and demoed stuff. And I mean, along with this thing called initializer is it's a pretty, pretty awesome little package, but I'm curious, what's your take on it? Yeah, yeah. I mean that 4 million plus is, I think it was 22% over the last month. So there's this weird hockey stick that's gone up from, I think it was a couple hundred thousand this time two years ago to well over 4 million now. So you're clearly seeing devs and teams realizing that spring is the way you build modern Java

microservices like that. I think that is no longer under debate. So with spring boot, it's about, I mean, from my understanding and I'm learning spring a bit myself now coming from a.net and JavaScript background. But, you know, when you look at spring boot, it's how do I value convention over configuration? I don't have all these XML files. I don't have all this stuff. Instead, I have a very opinionated framework that says this is the way to do a lot of things. And I can plug in using some smart dependency management of spring and boot to be able to do some really complex stuff super quick, whether it is all these Netflix OSS libraries and things like spring cloud or real config management, external config stores and things like that. Really powerful stuff for quickly accelerating. It's not meant to either be kind of the just kick the tires, play school microservices. It's meant to be like this is the Kickstarter for your enterprise class service or your Internet of Things service that's going to sit somewhere. So it's not just starter kits. It's meant to be this gets you up and running with spring boot. But the framework itself is clearly powerful enough and scaled well enough to run. Gosh, it seems like a heck of a lot of stuff when we listen to our customers on stage at CF Summit or other places really powered on this. So it feels like if you're using spring, as you mentioned, the initializer site is pretty ridiculous and an awesome way of going in saying, I want a little of this, a little of that. I get down this starter thing. I open it up and now I just do business logic. I spend no time on boilerplate stuff. And that is really powerful stuff. Yeah. You know, the things I've liked about it that I've seen since I've been here is one is that initial selection and packaging and what I would call wiring together of all your stuff, which, which at least way back when, when I was a Java developer was not fun. It was probably spend days or hours or days just getting started. Yeah. Just tracking down your dependencies and, and even beyond that, configuring all of your various frameworks and libraries to work with each other. So, you know, that's one of the things that spring as, as a whole has always been good

at is I used to always think about spring as, uh, uh, they were like Java API and library developers who cared about users. Like all their stuff was like much better usability than the default. So, so that's nice as well. And, and I think, I think one of the, uh, enterprise, if you will uses that I think is interesting. And I think it was Kroger who talked about this a little bit at the last year CF summit is that when you set up an internal version of initializer and spring boot, that you can basically use it as a point of governance, which sounds awful to some people, but it's basically a way of controlling and tracking what various people inside your company are using. And I, and I think long-term, even medium term, like that has a tremendous amount of benefits rather than, uh, as our butter and as our buddy, Andrew Schaefer would say, rather than YOLO governance, like it's a, it's a lot more control of over what companies are using, which, uh, is, is, I think that's a lot, uh, a large part of what we see Pivotal customers using it for. And, and it's, it's, it's a good, again, like you can think of all these negative phrases like choke point or gateways or something, but it's, it's more of a governance opportunity that, that you can, I mean, there's, you know, it doesn't feel like dependency management and dependency detection is going to be the problem for the next five or 10 years as we now scale out to tons of microservices and look what NPM goes offline for no JS and then the internet goes down because you all of a sudden the register, I mean dependencies and management and services and distributed systems, that is the problem we're now creating for ourselves. And maybe it's a good one because it means we're building scalable systems, but I can sympathize with a company that says, look, I want to know which boot modules I'm using. I want to understand which third party services I'm using. So if I can, you know, if I'm doing circuit breakers, great. What am I preventing from cascading failure? I need a bigger picture for running my stuff. So as much as I, you know, we all cringe and shudder at the term governance or management or registries, at the same time, I think as we keep doing more of these things with more

non-encapsulated dependencies, we're depending on more and more things. I don't know. There's a necessary evil there. Maybe we just haven't found the best solution yet. Yeah. I think, I think maybe what we need to get to, and there's, there's some people in the Cloud Foundry community who are scurrying around with the YAML files on this is automating governance, essentially that, that, I mean, it's good to have, it's good to know what you're running and, and how that happened, uh, because things break and, and you have to do stuff. And there's also like, you know, one of the, it's gotta, it's gotta be one of the, it's gotta be one of the top three or top five, uh, concerns of, of, of cloud native people. But basically like compliance and governance is a big deal. And so much of that, not all of it, but a lot of it is basically what we're talking about here, having an accounting of what's running and who authorized it and all this stuff. And one of the major reasons why it's such a headache is because it's not automated. It's like, it's, it's almost, it's not an analog loophole, but it's an, it's like analog leaking where there's almost this instance of governments where all of a sudden your, your software development goes into an email hole. It's like this, it's like terrible ETL. It goes into this email hole and then it goes into the, the Microsoft office hole. And somewhere in there, it probably goes through an analog hole and a bunch of meetings. And like, so instead of automating a whole bunch of cataloging of what's happening, people are doing it manually. And that's why it takes so long. And also why it seems like such a waste because everyone kind of knows it's not accurate. So the more, the more of these governance opportunities you have, the more you can automate governance and hopefully keep doing things that are good ideas, but just speed up doing it. So, uh, there's a rare sell for governance, pro governance movement. That's right. Not noted down this time and place that we were selling governance as a good thing. That's right. Well, you also, uh, you also noted that there's a, uh, migration service or competency over in

AWS land. What's going off with that? Yeah. Maybe think of it after last week, our discussion about, you know, again, refactoring and migration and legacy. And, you know, it was interesting to watch last week, Amazon spin up an actual competency program for their partners, for migration partners. So, you know, who's good at doing some of the delivery things or consulting things or some of the planning and architecture things. Actually moving the bits from, you know, bit barn A to bit barn B, you know, so it's interesting to see them do a real discipline where these people have to be certified, prove they've done this successfully. And you just wonder if, again, you're going to see that trend a little more as instead of everyone trying to run their own platform, some of the smart niche offerings are for, you know, let me help you get over there because that's not going to be dead business for decades, isn't it? I mean, as people move into these cloud platforms, companies are going to need help for years, either refactoring or designing or moving their legacy stuff. So interesting to see Amazon again, realize it's not all born in the cloud. It's about things that are also going to move over there. Just like we talked about last week, that's maybe a good maturation point for cloud that it is for more than just the new hotness. Yeah. And looking through the, they categorize the type of partners they have, but there's a, there's quite a few in there. It was interesting to read over there. And, you know, it makes me think that, you know, I feel like the cloud conference scene hasn't been too awesome for a long time. I mean, there's like our own conference, which of course is the most awesome. And then the Cloud Foundry Summit conference, and then there's like AWS. I mean, there's a lot of vendor driven conferences, but, and the O'Reilly ones are always pretty good. Although those are all kind of starting to run together into the same conference that I've noticed agenda wise recently, but casting aspersions or whatever that word is, dispersions aside, like it seems like a good use of cloud conferences would be like migrating to the cloud types of things. Cause just the generic like cloud conferences, it's just like, Hey cloud is like not really

too interesting now, but I think there is there's, I mean, we see it and I think other, everyone else sees it. And obviously Amazon does, there's enough interest in just like, how do I migrate my stuff that that would actually be a, uh, very interesting targeted cloud conference. And there you go. Conference organizers take note, but I think you're right. It's something that's again, not a super sexy topic, especially in this modern world as I know we're going to talk in a few moments about, you know, paths and containers and whatever, but you know, in reality, sheesh, now that we've proven cloud is a good model, we've gotten past that as they, you know, I don't know about this cloud thing. All right. So now we're getting into the actual interesting stuff of helping companies start using it, you know, and not just for their new stuff that's 10 projects a year. I went to 3000 apps sitting in their data center. Yeah. I mean, I mean this, I always think of this point of conferences because I remember the, the last time I went to a service now conference, which is a, uh, as exciting as this sounds hosted service, like a SAS service desk company that would like to be, you know, basically a case management company for everything, including driver's license renewals and stuff like that. But most of their money is in poaching away like remedy and, and other like service desk, uh, customers anyways, uh, and doing what we used to call ITSM. I barely even remember what that stands for. It's IT service management, isn't it? Indeed. Along, along with another favorite BSM business service management. Lovely. Yeah. So, uh, uh, you know, what was, this is probably two or three years ago now, but what was interesting about the, their conference was a huge amount of the people who are on the show floor were system integrators. And it was exactly, it was a very specific instance of what we're talking about here, where they were migrating from their on-premise service desk to the service now SAS service desk. And as you can imagine, there's a lot of customization in that with all your rules and logic and just

the hard work of moving all that work. So there were, I remember having drinks with several of the SIs, the system integrators afterwards. And they were like, I just bought a new boat. Like they, like they were all, they were making, that industry was making so much money that personally people were just, you know, they had piles of cash they needed to burn. Like some kind of Miami vice stash where they're, uh, just going into warehouses. Of course it was all legal. There was, and they were probably all wearing socks as well, but it was just a, it was a booming business. And I imagine there's a similar booming business for SIs who are just in this space and have the competency and have figured out not only like the advertising, but how to, how to, uh, do SI work in a lean way that's profitable. And, you know, I'm sure their margins are like five, 10, 15% like bad by software margins, but that's pretty good work. If you can, uh, line up a high volume of it. Right. Right. So good. Well, this week, uh, I think, I think it was published last week, but, um, one of my, uh, long ago, former bosses, Stephen O'Grady at Redmonk, he wrote a, a pretty short piece on, uh, basically what does PaaS mean platform as a service. And, uh, I thought, I thought that would be a good little, uh, topic for us to have in our, uh, discussion section here. Cause it is, it's, it's another, it's an, I've noticed this is another ritualistic Pivotal hazing thing, which is like, oh, it's the new person. Have them say what they think PaaS is. So you can, you can just totally screw with them. And, and, and I, and I think, I think, uh, and so, you know, you know, more, more seriously, it is, it is always interesting every few months to contemplate what, uh, what we do with this word because to, to summarize, uh, Stephen's post, which I think, I think hit upon, uh, oddly enough, he doesn't actually reference the NIST definition, which, which I think is, uh, their, their stuff is pretty good. I haven't read that in a while, but I remember the write-ups being well. And as I always like to point out, whatever happened to community cloud, that would have

been fun. But, uh, like he, to summarize his stuff, I think hopefully fairly, basically PaaS was a term that kind of evolved out of, uh, Salesforce and probably some other people at the time trying to figure out what to call their, as I would call it, their plugin mechanism. So Salesforce, the CRM system was out there and you could go in and like write and deploy code that customized it as you would need with any CRM or ERP system. And so they had, uh, what do they call that? Uh, they, they had some variant of Java that, uh, you could write stuff in and then you would have access. Yeah. Apex. There you go. And you, and you would basically, you could just extend their platform. And then at that time, I think there were all sorts of other people who were kind of like, it was a mixture of kind of like the, uh, the limping people from the ASP era who were letting you do stuff. And then there was also like jigsaw. There was all of these things. There was a whole other bent that was like the wiki companies that had kind of expanded into like the pseudo Lotus note companies. Like all this stuff that I think of as kind of like, uh, beyond FileMaker and Fox Pro, like your rapid application development stuff on the web. Yep. And, and, and that kind of got mushed together with some of the very early thoughts, I think of, of what the next era was, which was, let's call it kind of like the Heroku early Google app engine era, which was a little bit more like programmer friendly. And it was, it was something, it was something beyond go to a host Gator and like buy your own servers and install a lamp stack on it. Like, you know, and, and, you know, what, what you would see in this era was a fair amount of, of what you see as a developer with Cloud Foundry and, and contemporary passes, if you will. Uh, which was, uh, you basically write your application and you give it over to the thing. Let's, we'll just say paths and it figures out how to run it and does everything for you and auto scales, which is still something people are always fascinated with.

And it's kind of like a, uh, a thing about paths. And I think at this point in, in, uh, in, in O'Grady's writeup or Steven's writeup, what's interesting is that he's like, so it was basically what we call serverless nowadays, which I think is kind of legit, like this, the same, the same goals people were going after. And then, and then sometime, like, I remember when I read this writeup in Wired about the original team at VMware that had been, uh, uh, poached, I guess. I don't know if that's a dangerous word, but it had been hired from Google to basically come into VMware and be in a garage. Like, I think Cade Metz wrote this up and there were pictures and everything. And they were basically going to work on a paths that became Cloud Foundry. And then, and then there was a strange era where paths was not a big deal for a while. I don't really know what was happening. Then I think, I think everyone got up the way I always make up at this, this history is everyone got obsessed with, with mobile basically. And no one really cared about, uh, infrastructure. And then, uh, and then starting maybe a couple of years ago, um, uh, like I remember this is back when I was still an analyst and you had a whole bunch of small past vendors and Pivotal of course. And then eventually larger people like IBM and HP and then HP also bought Staccato, which was, which was a Cloud Foundry thing. All of a sudden, all of a sudden, all of these vendors are talking about paths all the time, except they don't call it paths, which is the point of his writeup. In fact, they almost have like, uh, something I'm all too familiar with at the moment. This like allergic reaction to, uh, to, to paths being around and, uh, they really don't want to use that term. And so people, including us will use terms like, uh, platform or cloud platform or cloud native or whatever there, there's even there's a, there's a writeup I'll put in the show notes from, uh, Brian Graceley, who's over an analyst over at Wikibon. And he makes a distinction between a structured and unstructured platform, which, which I think is nice. So that's pretty much the layup.

And then also Docker is in there as well as, as a way of doing things, but you know, there's really no major conclusions, uh, that, that Steven comes to, but it's a good kind of very pithy rounding up of like, so what do we call this thing essentially? Yeah. I mean, that's a good history lesson. I mean, I would just argue, I guess paths was too early for itself. You know, the early NIST days of IaaS and paths and SaaS is fit beautifully into a slide presentation, but you had people who were just maybe finished virtualizing their data center. They were starting to look at cloud and kind of giving everything up. Cause this member, I mean, as you described those early gen PaaSs were super constraining on purpose, but you know, you could deploy two languages to Google app engine or Heroku. You could only run these in their data centers. You had to have almost a, you know, it's a, no, it's joke about the sort of app engine. It had to be very aware of its environment in order to run successfully. So it was a very much an extreme lock-in and it was such a step so far for someone who's just starting to get into cloud. So fantastic model. And then, you know, Microsoft came out with their stuff, but then in 2012, you had, I think within a month of each other, Google and Microsoft announcing an IaaS layer saying like, Hey, we were probably too early with PaaS. So now let's actually make real money by offering infrastructure. And so I think, as you said, you know, there was that lull there where I think it was either mobile or people were kind of just figuring out infrastructure. And then, you know, as infrastructure became more and more automated and it became easier to get all of it, then all of a sudden, I think it returned this idea to how do I treat infrastructure super stupid? Cause it doesn't matter. I just want to build up using config management, Terraform. I just want to build stuff with no humans involved and deploy my apps. And almost, I think it gave you a second look back to shoot. Wasn't that what PaaS was? Like why am I building a PaaS? They already have these things. And by then, you know, go to 2014, 2015, when you did have projects like Cloud Foundry that had moved beyond that 2007 definition of PaaS where, you know, now it's open source.

Now it can run on premises. It supports a half a dozen languages plus another dozen with other build packs. It, you know, uses a number of great things under the covers that don't feel like it's a black box. So it was doing all these things, adding governance, adding ecosystem that if you were still stained with this definition from, you know, eight years ago, you thought, you know, PaaS is old and, and old and crusted. I just want to use my new container platform. You may, you may, you know, obviously just be jumping too far ahead and not realizing what's, what's evolved. So I think, you know, PaaS was early. I think it was a great model to talk about, but everyone just kind of nodded at it and patted it on the head, like the three-year-old at the Thanksgiving table. You're, you're, you're cool, PaaS. Someday you'll be here with the big boys. And now I think it deserves to see it at the table. Yeah, no, you're, you're, you're also, you're making me remember I left out Azure, right? Like that was originally launched as a, uh, and you're probably even more familiar with that than I am, but it was originally launched as a big PaaS and it kind of just, I don't know. I don't know what happened. They were fighting for use cases. Yeah. I think it was one of these where like, Hey, you can run your website here. I'm like, all right, well, how am I going to connect it to the rest of my stuff, which is sitting behind nine layers of firewalls. So I got, it's really interesting, but it's, I can deploy like only my siloed, you know, independent static website stuff or only my clouded sitting in the cloud stuff, which then wasn't a whole lot of stuff. Yeah. Yeah. Really interesting stuff. And maybe now in this whole serverless thing where most of these serverless frameworks are running in the cloud, it would make even more sense. So hopefully those things were precursors because they really got people into a mindset, which now feels commonplace, which felt super alien again, eight, 10 years ago. Yeah. And I, I, I, I like the way you frame it up that, uh, that essentially despite good intentions that we still have in the not PaaS, PaaS world, which is basically to make, uh, the act of, of, of developing and then running an application easier. I mean, you know, there's all sorts of things, but it's sort of like, you shouldn't have to

worry about all this infrastructure stuff. You can just be able to focus on running, running your software. Um, like we still all have that goal, but this, you know, what ended up, I think the, there's two things I think I remember that people used to think about PaaS, which, and maybe still do, which is what the problem is that it's too limiting. Like there's, it's too limiting. And like we talked about last time, there's too much lock-in, right? And like, well, what if, what if I want to do something it doesn't allow, right? And, and this was the big discussion I remember way back when around Apex and, and Google app engine is like, you know, it's, it's 95% Java, but what about that other 5%, right? Like, like what if I need to use that other 5% or like call out to the file system or like all this stuff? And, and that, uh, that kind of thinking, um, I think, I think somewhat rightly so always turns off programmers, right? Like I, I was, I was driving around today and thinking like, well, if you have a situation that's like 99% accurate, then hopefully you don't have to do that thing a hundred times because it'll fail the hundredth time. I mean, you know, not exactly on the hundredth time, but you get the idea. And so, you know, when you have small, what seem like small percentages like that, if you're doing it a lot, then there are issues that come up. So there is that idea of it being too limiting. And, and then the other idea, and this would be in specific to Heroku is I remember all my development friends at the time would be like, it's so expensive. Like I could just do it on my own and not have to worry about the expense of it, you know? And this is, you know, cause developers never really think about the long-term cost of something and, and they don't really do ROI stuff in their head. They're kind of one-time payers for stuff. Usually, I mean, I'm broadly generalizing there, but I, I think, I think, you know, both of those issues have been addressed to a large extent, right? Like as you were going over, you were cataloging all the different ways you can run. One of the things you just mentioned there is, and, and, you know, like there's a huge amount of flexibility that you have in passes, right?

You've got lots of languages supported in Cloud Foundry. You can add in your own services. Like we were just talking about spring boot earlier and like all the stuff that that has. So there is an actual, uh, broader array of functionality nowadays that you have. And I think, I think there's a better understanding that the cost is actually like worth it, that the ROI pans out. And you see that when it comes to the speed that you can achieve when you're doing things like the, the, the way that you figure out if it's too expensive or not, it's like, well, what are the alternatives? Like, how is it currently going for you essentially? And, you know, it is very expensive currently and doesn't really like deliver on, on all these great promises. Whereas if, if you have a functional it system in place, it's cost is the least of your concerns or, uh, things you worry about. Yeah. I mean, you, you, you hit on like a few good things there. I think, you know, one thing we've, I've heard us talk about a little more, frankly, we needed to do even more of it is systems need to be opinionated, but extensible. I mean, I think that there's this place where it says, look, just giving you a completely green field saying do whatever you want is too much. It's this paradox of choice. You end up spending too much time just getting things figured out. So I want to opinionated helps, but then you want to, as you say, you want to cover that 5%. You want to be able to do things that maybe still feel unholy to us, but we should be able to support it. So there's, I think some mix of that. I think it all comes down to this whole conversation is there's terms, but the point is, I think organizations are trying to ship faster and it's an agility thing. It's a speed thing. And so are you using the technology, whether we call it paths or cloud native or whatever we call it, are you taking on technologies or helping you do things faster, learn faster, fail faster, discover things faster, ship that, whatever it is. That when we spent the day with Forrester last week, and one thing they mentioned is, you know, arguably companies like Pivotal and with Cloud Foundry, we're actually in the continuous delivery market, not the cloud market. Like that's really what we do is help organizations ship software faster and better, like quality

software faster, not just ship garbage faster, ship quality software faster. That's the problem we're solving. I think that's the problem most companies are trying to address. Yeah, I think that's an interesting framing and it's almost to be a super big picture again. I think there's a lot of companies converging on that. Whether you want to, to use the old terms, as I always like doing, whether it's the software delivery lifecycle or development, SDLC or ALM or, you know, app dev or whatever, or CICD. Like there's a whole bunch of companies, like I think, I think HP just kind of, they came out with some new things that fit into that. And so it's, and, and companies like Chef have a, a CD product and we've got a, we've got one that we're working on. Like everyone basically has lots of opinions already and has for a while and is either working on or has a product that's sort of like your delivery pipeline management thing. And, and so, and, and I think that's a reaction to exactly what you were just saying that I guess that the, you guys were discussing with, uh, with the Forrester folks is like the problem you're solving is like delivering and running software. So you should solve that problem. Not just, not just worry about the servers or whatever, but like solve as much of that problem. And, and the critical pot, the critical thing in there is the pipeline. And so that's a important thing to pay attention to. Yeah. And to be, you know, maybe even more provocative if I were channeling our own, uh, James Watters, who I watched him twice last week, mentioned both to customers and in this briefing, you know, his belief that opinionated configuration management will never unopinionated configuration management can never win. That all it ends up being is just a dialect question as he says it. So chef puppet Ansible, you know, CF engine, these are just different ways of saying the same thing. And it's just this abstract kind of do whatever versus a Bosch or a Cloud Foundry, these systems

that are, this is how we think you build infrastructure. This is a specific thing we're solving instead of you can do everything. And even with awesome tools like Ansible, I still have to configure each app differently or each server environment. It's not right. There's no opinion. It's just a, a, a dialect question. So this idea of, I want to use platforms that give me a best way to ship things, lets me extend it when I need to, but gets me back into the business of shipping, interesting software, not being great at patching and updating servers. Yeah. Yeah. I mean, I mean, it's almost like opinions are expensive, especially to maintain. So, so be careful about having your own opinions too much. Like it's, it's, it's good to pull those together with everyone else and, uh, kind of go with it and, you know, to, to use my favorite joke, right? Like a file system is an opinion and, uh, it's not cheap to make if your opinion differs from, you know, the way most people do it. Although, you know, sometimes it's worth paying for, but not often. Well, when Forrester's, you know, predicting that about 40% of it is actually automated today, that, that means should I be spending my time trying to automate the last 60% or have something that does it for me? And that, that's always going to be the age old build by question that, that never will be solved. But when you look at that thing, what's it going to take me to get to 50%, what's it going to take me to get to 75, you know, a three-year project to, you know, do a container oriented data center with config management or an alternative. I think those are good questions to ask. And you may have a, you know, some shop may be totally set up to do something themselves or they're close to that tipping point where they're doing it the way that makes sense to them, but at the same time, I think we're seeing, that's why some of these large companies and mid-sized companies pick a platform because they don't want to work to move that next step. They want to get in there and then start going back to shipping software. So, so what do you, what do you think we should say? Do you think we should say cloud platform or PaaS or like what, uh, what, what word do you, let me ask that a different way. What word do you find yourself using by default? Yeah.

You've all ruined me since I got here on cloud native to some extent. And I, you know, but you know, the other thing that screws me up with PaaS and I don't want to throw our friends at Gardner under the bus, but you know, their taxonomy is 20 different classifications of PaaS covering everything from mobile to like, I think machine learning and key value store. Like they've hyper segmented so much that it's meaningless. Yeah. So that, that's part of the problem too, is a, everything somehow is a PaaS now, whether it's service now or Salesforce or Google app engine, somehow they're all PaaS, which is seems insane because how, you know, what is that overlap? But in the, you know, this race to kind of classify things, we've put everything in the PaaS bucket, meaning it's more or less made it meaningless. So it's not the fault of any one thing. It's just probably because there's a lot of these platformy things out there, but I think that's where these sort of cloud enabled platforms or microservices platforms are things that focus more on what am I putting on it versus just platform as a service. Sheesh, Uber has a platform, you know, where the heck do I classify that? Right, right. So I think I like pinning it a little more to the workload, which is where things like cloud native or microservices have meaning, right? I can't overload that to my guidance for cloud native. We've also coalesced a little bit on microservices, even serverless. So hopefully we focus a little more on that instead of just PaaS. Instead, it's, it's, it's always, there've been platforms for, you know, at least my whole career, if not before and yours as well. I think now we're trying to be a little more specific on what type of platform it is. Yeah, no, I, I think that's fair. I mean, the other, the other, uh, constant annoyance for me and, and, uh, and some other people with it, with the Gartner categorization, it's usually only public PaaS or not. I think it's always public PaaS they do, which is, you know, given the amount of, uh, uh, I mean, to be a little biased ranting here, given the amount of private PaaS that we sell is just sort of a little, uh, you know, little shruggy as it were, but, uh, yeah. And the amount of public and private infrastructure, right? Yeah, yeah, yeah, exactly. It shows everyone's investing a ton in public and it's not stopping on private. So whether we think it's dumb or silly, private cloud shouldn't exist.

None of that matters because that's what customers are buying. Exactly. And they're going to run private platforms on top of it. If the goal is to say, look, I don't care about the infrastructure. What is the point of running a private cloud? If you don't put a PaaS on it, you know, I would argue there's no point you should never install a private cloud. If you don't put a platform on top of it, because otherwise all I've done is build up an infrastructure stack. Yeah. Yeah. It's, it's as, as another bingo thing. Like I always think of that as the blinking cursor and I, and I would see people doing this with OpenStack a lot is they would, they would spend a year building a big IaaS and then there's a blinking cursor and it's just like, we hope now the real work begins. We need to actually do something with this and application centric platforms are where it's at. And it seems like the smart companies get that. Yeah. Yeah. No. And so I think, uh, I'm, I've always, I've always been, I don't know if it's one of those people, maybe the only person who like always wishes we would all just keep saying PaaS because I feel like it, it has meaning, but, but like, I don't know. I think, I think, uh, I think you and the continuing debate has kind of persuaded me that it's, it's, uh, it's not really that, that term has to at the very least be, uh, what's the word when you, uh, you, uh, send someone off to reform school, it's gotta be fixed up and, and, and the, the public perception of it has to be changed before we can, before you can use it in a way that doesn't require a bunch of footnotes afterwards, so to speak to explain what type of PaaS, where it does. And, you know, it's a, it's a word like democracy. It's like, well, what kind of democracy? I mean, maybe we're getting better in technology. It seems like people, you know, now DevOps is arguably watered down to nothing because now it just means people like each other and somehow that's DevOps. Like it's lost this whole spirit of like, no, you know, it's automation and it's continuous delivery and it's integration. And like, that's DevOps. Just the fact that you put people in a room together, you don't have DevOps. So cloud kind of got watered down a little bit. DevOps almost. I wonder if that's why there's such an argument over serverless right now, because they don't want to fall down that path. Yeah. And maybe we're getting better at it saying, let's define things that actually mean something upfront and not wait for every marketer to jump on it and quickly rebrand their site

with whatever the cool word is, even if they don't do it. Yeah. No, I, I think, I think that's probably fair. Well, before we wrap up, I just saw some late breaking news. There's also the big Apple conference going on. I haven't confirmed this, but apparently they will let you delete the default Apple apps off your phone now, which is just like, wow, that's amazing. So, so much productivity will be had. I want to. That is, uh, yeah, no, that's, that's game changing for, I'm sure, plenty of people. So, so there you go. They eventually listened to people and, uh, take things off of there. I can finally get rid of that tips and stocks application, which I never use. Awesome. So good times. Well, as always, uh, this has been Pivotal conversations. You can find, uh, the show notes that we've referenced. If you go to pivotal.io slash podcast, it'll, uh, show you where you can find them. There's a, there's a little fun picture of us and everything there you can click on. And also, like I mentioned earlier, we're in sound cloud and iTunes. If you just search for Pivotal conversations, I'm sure you'll find it. And if you have any feedback, you can send it to podcast at pivotal.io, or you can write to me at Coté in Twitter. And what's, what's your handle there? At rsirotor. And, uh, with that, you know, it's, it's always nice now that we're in iTunes, if you go in there and, uh, give us a star or a rate or a view, but what's really nice is if, if you recommend it to someone that you think would find it valuable or just write a little note to us to say that, uh, Hey, I'm here. You should keep doing this. That always, uh, helps, helps stroke at least my ego about things and makes me feel better about myself. See everyone next time.

Tanzu Talk · 🍕 Get more pizza.