Hello, everyone. Before we start, I just wanted to promote a few upcoming pivotal things through June, July, and August. We had the Cloud Native Roadshow coming to all sorts of cities. This is a free day-long event we do with Google that goes over what exactly Cloud Native is and how our customers are using pivotal and Google technologies and approaches. The cities, and this is a long list, so get ready. The cities are Stuttgart, Dallas, Denver, LA, Seattle, San Francisco, Amsterdam, Seoul, Hong Kong, Sydney, and Singapore. There's a big list of dates that you can look at. You can check out the show notes for a link to it, or if you just want to go and Google for Pivotal Cloud Native Roadshow, you'll find it pretty easily. We also have Spring Days Atlanta coming up July 18th and 19th. It's chock full of sessions for developers who want to learn more about the Spring Framework, Cloud Native style development, and of course, to be fully buzzword compliant, microservices. If you go to springdays.io, you can get more info, and that's the last Spring Days we're having so far that we have scheduled this year, so get that one in if you're over in grits and pork land. It'll be good stuff. Finally, why it's way in the future. We also have SpringOne platform coming up December 4th and 5th. Now, registration just opened recently for this. I think you might have missed the early bird thing for it, but that's fine. There's also still the CFP open. It closes on September 1st. Now, what goes on at this conference? Well, it's full of what I would call the suit track and the technology track. In the suit track, you've got case studies and managers and developers as well, but organizations talking about how they've transformed their company and what they're doing with Cloud Native, and their organizations, how they're getting good results by switching over to doing things in more of a pivotal way. But then there's also plenty of events for those of you out there who enjoy more nerding out and doing technical things to check out. I'm one of the chairs of the DevOps pipeline and monitoring track that we informally call it. We've already got lots of excellent talks queued up from the likes of Home Depot, Express Scripts, Allstate Northern Trust, and of course, plenty of pivotal people. I'll be speaking in that track if that's anything. So come on there. Again, it's in San Francisco, December 4th and 5th. And if you just go to springplatform.io, you can check it all out. And with that, enjoy the episode this week.
2:04Well, today, I think Richard is gallivanting around Europe. I'm not really sure what he's doing. Hopefully, he's getting some good pastries. I had someone tell me recently, he's actually a classically trained, as he said, French pastry chef, who was driving, well, this is right before Uber came back to Austin. But, you know, I guess that doesn't like preclude you needing to do a little gig economy work every now and then. Anyways, he was explaining how the water they use and the amount of gluten in the bread makes the bread much more better over in Europe. I don't know. It's sort of like people from Jersey saying the pizza tastes different. I'm not really sure if there's anything up with that. But anyways, so hopefully, he's loading up on delicious bread. We'll get a full recap. But this week, I've got two people on. Why don't you introduce yourself first, Tony? Hi, Tony Hansman. I work here at Pivotal as a platform architect. But I spent all of my career in operations. So, mostly, I see myself as someone who goes to our customers and tells them how to do operations with these new tool sets. And yourself, John? Yeah, John, I work in product marketing, work very closely with Richard and have a lot of fun in that. And at Pivotal, I've been looking at the ops story and particularly Bosch, how that wonderful technology does all kinds of magical, unicorn things to your infrastructure. Yes. Yeah. And it's a clam thing. Do they have like quarterly meetings where they try to come up with a new logo? Or has it become like ironically awesome that they use that clam? So, it's funny you mention that because the kind of creepy clam seems to have been moved into the back room. And now we have a shiny rainbow-colored Bosch logo, which got left at the Cloud Summit last week, much to all of our surprise. I like it. The creepy clam. You know, I'm always a fool for alliteration. So, that works out well. So, Tony, like you said, you spent your lifetime in ops, or I don't know if lifetime. You spent many years in ops. I'm sure there's other things you've done with your life. Although maybe not,
4:07that would be a fascinating story. Yeah. I feel like I got dropped into the Unix pool at age of around 24 and have been there forever. Oh, yeah. Yeah. Just a little, I don't know what an analogy for a latchkey kid in the Unix world would be. But that's fine. Yeah. Yeah. Yeah. Definitely a latchkey kid raised by Phil Donahue for the most part. That's good. Yeah. I used to love it. I like the style where he would run around the audience and stick mics in people's faces. I feel like they should do that at conferences more, right? When there's a, maybe next time I'm at a talk and they have one of those dreaded two lines of mics where they ask people to, as they say, queue up in a place where you can get good bread. I'll just grab the mic and run around. That'd be fun. So let's see. I seem to have lost what we're talking about and thinking about bread. So tell me, like, let's start from the end. Like, what are the concerns or the questions or whatever, as you say, when you, when you go out and talk with people who are customers of ours? Like, I mean, I encounter these a lot, but I'm curious to hear, like, if you were to get like the top three or five, depending on how they are, like, what are the ops questions they have? Like, what are they, what are they wondering about? Well, so it's, it's less about ops questions and more about org questions. What I've found in my ops career is it's really an org problem, not an op problem. And so the very first thing is like, oh, we're going to, we're going to push a lot of code really fast. They're like, oh, our organization won't let us do that. And like, literally the top one through five questions are all about, well, I would, but you see the person who's upstream of me won't allow that. And the people downstream of me won't allow that. So we can't make any changes. Nah, that, that seems a pretty astute observation that lines up with a lot of what I encounter. Yeah. And, and so, I mean, like, uh, I've been, I've been running Bosch based systems at Cloud Foundry since 2012. And I know that you can definitely do much better than what people are doing. And so,
6:13I mean, I've searched and searched and the most recent metaphor that I've got is that, um, the, the pivotal tool thing here is really like an ultra high precision machine. And what most people are doing at their, at their own ops shops are like very, very low precision machine with tons of human error in the middle and all this sort of thing. And so to start with as a, you know, kind of controlling metaphor, I talk like, Hey, this is a very high precision software machine. Like if you get it set up with ops processes, you as operators can get out of the deploy chain. And that is probably the thing that interests them most. Like, did you say we could get out of the deploy chain? Yes. Right. And that, right. And that, and that starts to give operators an inkling that they could get their life back. And so that tends, when I go talk to customers, what I really want to leave them with is it is possible and it is work. And I mean, it worked on the order of three to five years for a lot of organizations. Um, but it is work and you will be improving all of the time. And so that mostly what I talk to them about is the big giant picture. How do we get operators out of the deploy process? And then like the teeny, teeny micro picture, like, you know, in QA, they will not accept this kind of thing. Like, okay, we're going to have to go talk to QA then about what they will and won't accept and how they, you know, their testing methodology and automated testing and things like that. And so those are the big, you know, those are really the big things I talk about. So I hammer CI because continuous integration is, is actually the warp engine that you can hook to, you know, our, whatever fusion nacelles. I'm going to get lost in the start technologies pretty quick, but, um, you know,
8:13Bosch and Cloud Foundry allow you to do really amazing things. Uh, but there's no transmission. You need continuous integration. And we always recommend concourse because it's purpose built for this. Um, you know, you have to have those three pieces. Otherwise you cannot make your organization go fast. And so there you go. There's the, there's in a nutshell what I tell our customers. Yeah, no, those three are good. Cause they, uh, uh, I mean, they're interesting. One, I mean, just to summarize them. So it's sort of like the first, a huge problem is sort of like the, uh, if I look to the, you know, I forget that old song, I can look to the left and the right. And then these people are holding me back from doing stuff or holding me back as a cynical way of putting it is like, I would like to do the right thing, but all of us have to do the right thing together. And the way we're currently set up, it just will not allow for that. And then, and then, uh, you know, there's this, there's this, uh, uh, the middle one you talked about is this very, um, specific direct benefit that I think unless, unless you're in an ops role, you don't really appreciate, which is sort of like, Oh, I don't have to spend so much time releasing software now, which, which I, I imagine for most ops people, maybe like, I guess you have a whole group of security people who freak out about other stuff, but I, you know, between like security and doing a release, those probably seem like the things that ops people would, uh, have nightmares about the most. And then, and then the last part is a good, like, uh, you know, I, I've been trying to think a lot recently about pacing out enterprise transformation to use a phrase. And yeah, it seems like two to three years is, uh, that's what it takes. Like I always, I always kind of like, uh, I don't know, I should be less negative in general in life. Uh, but like, you know, it's, it's not like all the like Spotify and, and unicorn talks you see where sort of like every six months you can switch things around. It's like, you're in a large organization. You should pace yourself. It's going to take a couple of years and like, that's totally okay. Don't freak out. Right? Like
10:15it's, uh, there is the old aircraft carrier mentality. So what, you know, what's the aircraft carrier mentality? Oh, oh, it's, it's, uh, that, that reminds, it's, uh, back when I was, uh, working on, uh, strategy at Dell, uh, a couple of jobs ago, I think I was getting frustrated about how slow things would take, you know, to do all these things. Exactly. Exactly. And, and, and one of my, my mentors there was like, I know it's frustrating, but just imagine you're one of the hands on the wheel of this big aircraft carrier and it may take a long time to turn, but you know, it's, uh, which it'd be interesting to look up how long it actually does take an aircraft carrier to turn. I have a feeling it's like one of those Mussolini trains running on time things that probably aircraft carriers can actually turn really quickly nowadays. But anyhow, you did, you did say a magic word transformation. And so one of my goals at Pivotal is never to have this word said without giving an operative definition. And so since I am, what is your operative definition of transformation? I, I, I think, I think it gets to, to that first thing you were saying, which, which is, is, it's nicely the next, uh, I don't know, one of the topics I want to talk about, which is, it's just a very like literal version of it, which is like, um, the way you're operating now. Well, if we narrow down to like, you're, you're writing your own software, large organization that you use for whatever reason to do your daily, weekly business or your processes and the way you're doing it now, all the way from the, uh, the operations, lower level operation stuff to thinking about how you figure out what to put in your software. And then thinking about having the business side of people think about how they use software to, uh, decide what they're doing. You pretty much need to change a huge amount of that around. So it's change and transformation are more or less the, the, the two things, uh, that I mean with that. And to your point about, uh, as you're opening up with like organizational stuff, uh, you're going to likely need to change around or transform
12:19the shape of your organization and what people do. So, I mean, to, to the point we're talking about with, uh, whether aircraft carriers can turn on a dime or not, I think ideally you want to transform the business, right? Or, or whatever reason you have for existing, but probably at the moment, we're mostly focused on the, I should say the bulk of, of work is transforming how it operates. So that to your first point, when you look to the left and the right, your, uh, your jokers and your whatnot, like they change how they operate. And, uh, so that's, that's what I'm always shooting for when, when I use that, uh, that phrase. And yeah, I mean, as I was caveatting, like there's all these words like digital transformation and organization, and I don't really know what else to say. That's what I hear. I'll, I'll give you the operative definition. So here's the deal is an operations person, when people say transformation and I'm like, what does that actually mean? And they can't give me a operative definition. Then I just shut down sort of like Korba. Korba was going to solve everything in the nineties. Exactly. And then like, I'm just going to duck this Korba thing. And people right now, I think try to duck the transformation thing. And so from an operator's perspective, here's what I say, which is transformation is adding enough dimensionality that problems that seemed intractable become trivial to solve. And so in the real world, what that means is I, I, I walk into a customer meeting. First time I've ever met them, there's usually executives in the room. And I say, if you care at all, and I mean, just barely, if you care at all about switching around, you will push four to 10 times as much software. Yeah. That is on a year over year basis, four to 10 times software, more software go out the door. And frankly, for the people in that room, that sounds crazy. That just plainly sounds crazy. And the, the real, the real thing here is, is that if they care at all, they will push 40 to a hundred times more software, but I can't even say that in the room. And so the, so this question is like, well, how is that even possible? It's just because pivotal,
14:24all the pivotal stack is ultra high precision software. And it adds so much dimensionality that it allows you to do things that seemed like impossible, pushing four times as much software that seems impossible. But if you actually see how the cloud foundry works and everything like that, it's not even surprising and like, Oh yeah, it's actually more like 40 times. Well, to, to, to, to interrupt you there. So to that end, uh, like I, I, I, I want you to come in and go over a little things here, a couple of things here, John, because one of the things that, um, to, um, to Tony's point that I always find missing in, in, uh, brief conversations of it, right. Is the, uh, like, well, that all sounds great. But so, uh, like, I always, what do you actually do? Like, I call this, the computers are awesome marketing anti-pad, which is like computers, you know, you're sort of like, hold on, isn't that always what computers are supposed to have done? So, uh, I, you know, you have a series of blog posts that you're doing and I was, uh, as so often happens when you have questions about content. I read the first one and I was like, Oh, uh, but yeah, how does that actually work? And then I read the second one. I was like, Oh, I should have just been patient. And so like, like, I think, you know, you, and you, you, uh, you divided up a few like features and things that in, in the cloud native world, the actual technologies that enable this and, and, you know, obviously it'd be good to hear from both of you, but like, what's your idea, John, of like, what are the actual enabling technologies? Like what is in the creepy clam that, um, does that sort of freeing up of resources or transformation or whatever? Like what's different that you've been tracked? Well, that's something I wanted to speak to is the, um, is the casting the IT and operations as the bad guys. Um, you know, the guys that are going slow and they're just kind of in the way of transformation. And, uh, if you're the other side of the fence, you, you know, you feel like you're the custodian of things like reliability, security. There are a lot of, um, a lot of things that you are trying to keep those best developers in.
16:24And, uh, I think, but in terms of transformation, uh, I think the, uh, IT and operations are on board as much as the rest of the organization. Um, and they kind of see that the current mode of operation is unsustainable. You know, every part of the business is now trying to find digital ways to engage with customers. And, you know, guess what? That results in more, more apps that need to be operated. Um, and just by adding more people, you're not going to scale. So I, um, I think they see that they also see the kind of rogue IT. They see developers getting frustrated with slow timelines and just putting down their credit card for, you know, external AWS or other IAS. So I, I, I, and I'm interested in what Tony thinks, but I think the sense is that they, they know this is unsustainable, but they don't know what the solution is. Um, it's not more people. Um, and so the, the answer that kind of arrived in my, in my blogs is it's about automation abstraction. Um, it's about moving the level at which you as an ops person, um, moves up and starts using that high precision technology that Tony talks about. Um, so we start, we start looking at that in terms of Bosch, which does a whole range of things. Um, and we talk about day one, which is if you familiar with configuration management, maybe chef puppet, it's how do you, how do you deploy the software? How do you set up the environments, the operating system, but then on day two, once it's all set up and deployed, you know, day two goes, is more than one day. That's every day apart from day one that continue, uh, you continue to operate the software. And you know, a lot of the things you created on day one, a lot of the metadata, the things you know about the application actually just need to propagate into day two and beyond. Um, because you, you know how that thing is supposed to work and how the environment system look. So if it starts to kind of drift out of configuration, how do you bring it back? If you lose services, how do you bring them back? Um, how do you do things like, like scaling? So the, the,
18:24the first kind of technological piece is just elevating the, the level at which as an ops person operates. So it gives me a force multiplier. I'm, I'm bringing a level of automation that is kind of looking after things, um, monitoring them rather than meeting a console doing that. It's just got that. It's just kind of got my back and I can think more about, okay, what, um, incremental improvements can I make to this that I can then build into that platform. But we're using, I have, there's this, there's all, I like to define terms. So the same way I want an operative definition of transformation, we've got to get an operative definition of automation, which if you go to a lot of customers and you say, Hey, do you use automation? They all raise their hands. And I'm like, how many steps are in doing X and how many people have to touch things in those steps? And they're like, Oh, there's eight steps and people touch all but one of them. And there's like this one script that configures things like, well, that's not really automation. And so I got, I got in trouble, but I think we need to introduce a new term, which is, uh, taken from the driving car thing, which is autonomization. Uh, I'm not going to get that conjugation correct, but we want things to be autonomous, not automated. Uh, and so one of the big things with Bosch is it is autonomous. It is like you set it up and it says, okay, well, you've told me I need to keep these things going. And I have many levels on which I autonomously keep your software running, your VMs running the components that are, that make up a pivotal cloud foundry and keep all of those things running. Same thing with services. And so the, uh, you know, automation is insufficient right now. I hope that in 10 years that we can go back to using that perfectly good word. But right now, if you go to a fortune 2000 customer and you say automation, they think that they have checked the box. And they have not. And so autonomous is where we're looking for. And so, yeah. And if you, if you think of automation is really, Hey, I wrote a script to do the things I used to do manually,
20:26um, then you're missing a trick because with the autonomous system, when they start operating at the kind of scale that we're talking about now, um, you can watch that system and all the individual things that an autonomous system does, and it makes no sense. Um, but you, that's because it's kind of elevated the way it works beyond the way your brain could process so much information. And, you know, at the end of a lot of these things, you see, Oh, it got to the right result in a very, in a way that I, I would never have been able to do because I just can't keep that many things in my, in my head at the same time. Um, so I think that's the distinction. It's not about just taking the old steps and making them run, uh, making machine run them. It's about giving that machine more, more control. So that, that does seem like, like one of the, uh, um, I don't know, maybe the number one core technology enabler of, of transformation to use our, our word. Um, well, and, and, and before we delve into that more, I mean, are there, other, other, other sort of like, uh, whether they're without getting too sort of like spacey, uh, to reference Star Trek again, like, uh, whether they're like actual, like software or hardware technologies or, or sort of like thought technology, sort of like processes of operating. Are there other things that, that you find in the toolkit that enable all of this that you've written about John? Yeah. I mean, so I'm looking, I mean, we've talked about software defined data center for, for a long time, but those, those technologies really are, uh, uh, in a, in a, in a great state of the art. And, you know, we work with, for example, with VMware on NSX, um, their networking layer and the way that integrates with Bosch to really, uh, um, to make the, the network rather than it's hardwired, um, kind of mess, um, a very fungible software thing. Um, it just gives us that dynamic edge. It's something like Bosch can, can run across that because it's software just calling APIs other than, um, you know, people running around,
22:26having to hardwire networks. And it's kind of, there's a, there's a lot of detail that we don't have time to go into here, but when you start wanting to do things like, um, be able to audit, uh, your security arrangements for compliance, things like NSX have got that built in. They have a lot of the, internal security firewalls built in. So you can, um, where, where just your regular software defined infrastructure maybe doesn't have, um, all the, the traceability back to what happened. Um, NSX certainly gives you that now so that as an operator, I, I don't have to be, um, concerning myself with that level again. And another layer of software has got my back. So on, on that topic, this is something, uh, I was curious to talk about and, and, and given the joking about being a, uh, a Phil Donahue Unix latchkey kid, Tony, uh, it, it seems like one of the, well, at least in my experience, one of the areas like, like I haven't really like explored and talked enough about is like, so if we didn't have, and John was just alluding to this, if we didn't have all that infrastructure as a service stuff, like we wouldn't really be here like, and, and, and, you know, in all, in all the diagrams, uh, that, that we use around here, there's always this little bit at the bottom. That's basically like, you know, the data center, like, like all the hardware stuff. And, and especially in going out and talking with customers, like if, if you can start with like kind of what's the state of the raw infrastructure that you see out there and where do, where do people need to move to as far as that state to be in, in more of a cloud native way of operating? Yeah. So I, so I do not give short shrift to the IaaS because it is the key enabling technology here. Um, it is API driven, which is, you know, the first thing, but I often say what people miss about what's valuable about the IaaS is persistent storage. The persistent storage metaphor allows us
24:28to just treat all VMs as disposable. And that was, that was one of the key enabling just metaphors, like, oh, you can just throw what you can, you know, you don't have to update a VM. You can literally throw it away and put in the new version and reattach storage to it. And so, yeah, I don't, I don't give short shrift to the IaaS. Um, what I, what I actually say about that is what a PaaS does, it's a ratchet for the IaaS. With a PaaS, you can use the IaaS in its most mechanically advantaged way. So, you know, if you're using a ratchet on a, you know, an actual by hand, you just use that place where you can use gravity to maximize your force and then you turn it back, right? You don't try to spin that thing all the way around. What I would say is the best way to use IaaS is, is with a PaaS, because all of the other contorting and handwork that people do on IaaS is, you know, we go to customers and it still takes, it'll take three months to provision a VM. And that, that's all, they've got some goofball process that, that makes them take three months. It's not that the IaaS takes three months and it's going to ship anything. Um, so the best way to get IaaS cloud native is to put a PaaS on it and then talk with your hardware vendor about drip or utility computing or integrated or hyperconverged or whatever, so that you're just being delivered a rack of IaaS, essentially. And then work operationally to be able to accept, you know, some reasonable number, but a fairly high number. If you need to rack 30 racks at a time, because you know, you've got a Pivotal Cloud Foundry and it's running all, you know, 10,000 applications and it tells you like, hey, the IaaS is starting to run low on IaaS. Like, great. When you get that message as an operator, you want to know exactly what to say to your hardware vendor so that they just deliver what
26:29you need to your dock. You get that rack and it becomes integrated immediately, becomes online and available for the IaaS to use, for the PaaS to use. I mean, that's, that's what to do from behind the firewall. And you know, this, this brings up another topic, uh, that, that I, I don't know, I, I fiddle around with when I wake up at like 3 AM in the morning and I'm not otherwise freaking out about my life as too often happens. But like, it seems like a lot of what's going on in, in this space, as far as like, uh, doing cloud native ops or whatever is, and, and, and I know this is intentionally wrong, if you will, is there's a lot of homogenization of the technology up and down the stack? Uh, maybe not so much at the top layer where you want to be all like polyglot and so forth, but it seems that like the lower stack, it's essentially the, uh, I don't know from, from our, our latchkey days of the late nineties and early two thousands, like the Microsoft and the, and the, the Unix pitch of like, if you have the whole stack, everything works out well. And you know, then there, there was always the tension about a lot of the issue in addition to like, just, uh, what were you saying? Goofball process stuff, uh, that, that it has an aggregate, not just as customer written software is like, I got all this heterogeneous stuff, right? Like I got all these things to manage. And it seems like, and I'm interested on, on, on y'all's take on this is like a lot of what's been happening is to word this very carefully within one organization. It is more acceptable and maybe even cost effective. It's not, it's not expensive to go by from one big closed vendor, but to have a pretty homogeneous stack at at least the lower levels of things. And that enables a tremendous amount of automation and just reduction of variability. But I don't know. I mean, does that, does that seem to comport with what, what, what you've been seeing over the years or, or how does that all fit in? Yeah. Yeah. I mean, so just to be really, you know, put all cards on the table, I take Google as the
28:33guiding light and Google is just like, uh, commoditized to the max extent possible, centralized to the max extent possible, uh, autonomized to the max extent possible. So these are the, those are the far edges of where I look for, for, so I'm going to depart a slight bit from this because I think it's useful to, to pick this up as a metaphor. If we all three decided to start a company and we were, I don't know, selling the golden eggs, geese lay, we would be a commodity business and we would choose the accounting model for commodity businesses. If we instead sold golden gooses and took a percentage of all eggs laid, then we would be a, you know, whatever, a delayed revenue recognition model. We would choose that generally accepted accounting principle model. But if I said, you know what, we need a totally new accounting model. We're going to off road it here. We're going to make up our new accounting model. What you two should say is like, that sounds pretty crazy and doesn't take advantage of, you know, extensive regulatory structures and legal precedent that would allow us to operate much more smoothly. So I think this metaphor applies directly to operations. We have for the last 40 years off-roaded it to the, this is a, this will take a little while to develop. So if I go too long, just tell me, but I think where we should get to is a generally accepted operations practice set. And it should be testable. I mean, literally have tests and assert things and things like that. What we've got now and what we're seeing in customers and why we're seeing customers come to us is because the old school polyglot to DYI model has all the problems of a vendor lock-in model. And worse, it has the problems of the, when you get that DYI thing out, that's essentially the last major feature set that ever goes into it.
30:35If you get a major feature out of your own DYI paths at year two, you are some kind of miracle worker. And so I want to, I want to step back from an operations point of view and start trying to optimize for the organization as a whole instead of for the kind of narrow optimizations that you might do in any one group. And I really, I think starting at choose an IaaS that's consistent, has a consistent API. Choose a PaaS that's consistent, has a consistent API. Let the, let the world be your research engine. Like what I do, I'll go tell our customers, like, look, you can go look what, you know, who our big customers are and they're public, right? So the big finn services companies, they drive our security research. And so if you're a little finn services company, but you would like the resource of a big finn services company driving your research, guess what? There's a way to arbitrage that. And I think when you take a look across the industry at that, what you can see is that it starts to make sense to have a broad base of solutions coming into whatever you're going to run internally. And it does not make sense to do a DYI. These DYI things are always designed. I used to be an operations consultant and I would just go to wherever they did a DYI when the people who did it left. And I had to clean up, right? And so I have seen this movie many, many times. Wow. That was a long answer. But the summary here is how to modern, the modern world. And it is standardization with an eye toward optimizing for the whole organization, not for IT, not for developers, not for security, but for the whole org. Yeah. And to add to that, I think that's a good answer there in the sense of, it seems like the
32:38very tangible advice, you know, given both from your DIY janitor days and like the actual state of affairs nowadays and everything is like, to use a slightly old word, like your infrastructure should be commodity infrastructure. Like there's not really a lot of reason to like vary it from, there's not like the IEEE doesn't, or whoever, I don't know, some data center group. There's not necessarily like reference architectures. I mean, you can go look up like a few things here and there from Facebook and Google and stuff like that. But in general, as, as sort of like an anti-example, if you look at, if you were to, uh, put the portfolio of all the different types of infrastructure an organization has on the wall, there's probably some number, like ideally it would be one, one type that they have. But as probably as you get over, like, I'm just wangling it out, like four or five different types, there's probably something terribly wrong. And it's almost like, you should start working on that first. Like, I often joke when I'm talking with people, like, uh, when you're dealing with legacy problems, one of the major sources of legacy problems is just like this variability we're talking about. So like, if you haven't more or less virtualized everything and consolidated, you should probably call us back in six months and, or, or however long, like, like work on that. Yeah. I mean, the great news is, is that you can do that if you're, if you're determined, you can do that very quickly. Uh, but determination and, you know, it runs into organizational concerns rather than technology concerns. Yeah. And so we're, we're back at, you know, there are no technology problems. There are just organization problems. Um, yeah, yeah, I, we have seen customers, you know, we love to talk about the Home Depot. Um, but when we talk about them, I'm not sure that we tell everyone what the deal there is, is, which is a CEO is like, Hey, guess what? We are all moving today. Exactly. Like all of us,
34:40right? There is no option. Nope. But one of my favorite things we hear in different variants from our customers is no is not an option. I'm not saying you have to take my option, but you better come up with a really good one. And no is not an option. And, you know, I imagine that a CIO is saying that to their staff because their board is saying to the executives, Hey, no is not an option on digital, digital transformation. And, you know, I'll tell a, I'll tell a dirty story by way of pointing at this for everyone. Most people do not know that at Netflix, that when they made this transformation to AWS, they abandoned in place around 60 operations people. And the development teams picked the ones that they liked and could work with well. And then they just left all of the rest of them sitting there. And one day they fired that VP and laid off all those people. And so there are dirty, dirty stories from this side. What I tell customers is don't be that, don't be that, right? This definitely happens. And you want to think about when a board is telling executives, no is not an option. They're serious. And so don't attempt to duck this like Corba. You, you really had some, uh, some scarring from Corba, didn't you? Just some, some terrible times. There's just some hot searing orbs were thrown your way and, uh, things didn't pan out. Yeah, that was, that was definitely a case where some executive went to a party and some other executive said to them, Corba. And they're like, Corba, I don't have Corba. And they came and told me, Corba. I'm like, uh, uh, this doesn't actually do anything. They're like, Corba. Like, okay. That's funny. Tony, what, what, what's your advice then for the ops folks, um, uh, as to how to get developers to like them? Cause that sounds like that's, um, that's the place you want to be. Well, yeah. So here's, so here is, here's what I actually see in the real world that when I talk to,
36:45you know, fortune 10 executives, I say, I laugh at them a little bit and I say, look, I know something about you. I know that when there is a very large, big problem in your shop, you call something like 12 people. And no one of those 12 people has the answer, but that is the 12 people who have enough context to your whole organization, network security, everything else to actually solve a really big problem. And it's the same 12 people all the time. And so what that means is that in any organization like that, there's something like a dozen people who actually know how to think across the whole, all the technology. And so what it turns out is that if you can talk to 12 people in and talk to them about digital transformation in a way that they just, you know, don't hear it like Corba, like, Hey, we're just adding a lot of dimensionality with robots to solve all of your problems. And you get this very high precision, very high reliability, very high certainty system. And so you captured those 12 people and you tell them like, look, here's what it really is. Here's what's really going on. We'll show you those 12 people are the ones who are thought leaders for their whole org. And so they can start getting that back out through the operations organization. And here's where you end up. The operations organization has the most global view in an organization for a whole company. And so if you drive from the center, hey, we are trying to globally optimize for the whole company with these new tool sets. That's how you get, you know, that's how you become friendly with everyone. Because now when you understand that you can do things very fast. And when you understand CI, you can do something that no one has ever done. You could walk to the security team and say, I want to help you, which no security person has ever heard ever.
38:45And so you start talking like, hey, if you have these constant set of things that have to be asserted and audited, let's just write those in CI pipelines and we'll assert them every hour. And you can produce an hourly report that says you're in compliance. And when you walk into QA, security, networking, and any other compliance kind of team, and you start giving them tools that also allows them to operate in extremely high precision, they become very friendly to you. They're like, oh my gosh, I got this whole book of regulations. Like, you know, you say, wake up at 3am in a cold sweat about you're like, yeah, let's audit all those things out. And they're like, great, but my organization won't let me. Right now we're back to the organizational problem. And so that's where the operations teams can be really helpful because they're very good at dealing with emergent problems. And so they use the skill set they've built over years that seemed worthless until now to help people get around, like if the organization is just doing something dumb, like let's just go talk to the people who think we should do it. And maybe they want to do the right thing too, but just don't know how to do something different. And so that's, that's what I would, operations is the most central organization. And if they change their attitude about how to do things, they can be incredibly effective and help other people leverage this technology. And things are great. So, so let me, let me try to like boil down, uh, uh, a little bit of leftover questions into, uh, some, some last is strange last potion to go over here. Um, so, so, so the one thing we've alluded to a lot, uh, is the, uh, you should use platform as a service or paths as the standard layer on top of all the standard stuff, so to speak, it's, it's like standardization all the way down. Um, and I think what, what we try to do in pivotal cloud foundry, I mean, I don't know if we use this phrase so much anymore, but we used to talk about being highly opinionated is we try to embed in our paths layer,
40:51a model of operating and thinking, if you will, the, the way you would do it. And so to, to, to go back a little bit, I think the last large model of thinking about it that we had, uh, was basically like I tell, or some people would call it it SM, it service management. And, and I feel like, I feel like the idea of that was that there's maybe like three things. One, well, you start off with like it is complicated, right? Like there's a lot of moving parts and you got to do a lot of stuff. Two, there's a lot of people involved who have to like approve things that happen and have input on it for all sorts of legitimate and non-legitimate reasons. And then, and then three, uh, you're going to have people requesting that it does stuff. Hence the service management part and the, the, uh, tragic obsession on ticket management that occurred. And so like, to me, and I just go over that, like that is an example of a model of it, which is basically like people come to you it and they want you to do something and you do it. And you know, the part of that planning, not to, not to short shrift, but part of that planning is what we would call day two thinking or, or to John's point earlier, uh, day in plus one thinking. Cause it's, you know, every, every day after day one of what is our plan for operating this and what's our run book and like, well, let's set up how we're going to do it. Um, but the model ended up being more about like, I guess a project way of looking at it. So there's that as an example. And you've kind of alluded to this several times. Like if you were to come up with like what the model of it thinking is for this precision stuff. Right. Um, and I think you've hit upon it a little bit with things like, let's make it testable and we should have continuous integration. Like I just, I'm interested to hear what you think. Like that, that model is like the cloud native model that, that having the standardized IS and the pass on top, like what's the way people
42:54should think about the, the it that they're doing and how they kind of like manage its life. Yeah. So it's incredibly straightforward, but you have to get over something. If so, I'm going to introduce a weird term here. If you're in a Turing mediated environment, that is computers are doing what they're doing. There are no untestable things. You must first accept that if you're dealing with computers, you can always test, you can always test an assertion. And so once you come to accept that, then everything I tell can be entirely subsumed. I tell does not require a person to validate. Like if you have to have X, Y, Z process. Great. Just write the assertions for that process or automate that process. You can keep your I tell, no problem. It's not, it's, you know, the thing you have to watch out for when you get the new tool sets is arguing about motor oil for an electric car, right? You don't put motor oil on electric car. So don't argue about it for electric cars. That's probably the right way to think about that. But everything, everything, everything can be tested, asserted, watched, audited, known. You just move into a, you know, a highly discoverable environment. And so, like you pointed out, there's all these checks and balances and processes. And often it's because all these resources are getting used incorrectly and, you know, we don't even know how that got in and blah, blah, blah. And you do want to manage to that. However, if you can know, if you can say, hey, I trust my organization within these guardrails to do the right thing. And if something goes off the rails, we actually have really good audit process and we can switch things around. So you can loosen some of the, you know, operations is a business of scarring. It absolutely is. And so the modern cloud native thing is like, start, start automating worrying about your scars. And you make everything autonomous. And eventually,
44:56what you find is that the whole thing floats. Cloud Foundry floats when you run it. It's very hard to knock over. And just that experience will change the way you look at operations. Well, I think the upshot of that is you're, you know, the 12 people, they can be doing one of two things. They can be running the system or they can actually be looking at, looking at the way that they're going to improve the system, you know, and automates additional processes. And so you want the balance of that to be doing the continuous improvement rather than just doing the stuff which keeps the lights on. And what we see in some of our most successful customers is they become a platform ops team. They pretty much have a product that they offer to developers with all those features. And they keep making it better because they keep making developers go faster. So that they change their thinking from being operating to kind of managing a service or a product. And that's very transformational for the organizations we've seen pick that up. Yeah. You know, to kind of continue the idea of the new model, it's almost not the opposite of like an ITAL model, but it's a huge difference is sort of the, to some extent, the take it or leave it approach that ops gives with something I'll go over as a change. But it's sort of like, here are the things we provide here. Here's the standardized things we provide. You should figure out how to fit what you need into that. And if it doesn't fit into that, then we have a remediation process that will do a couple of things. One, like you could ask for something new on the existing platform to some extent, but not, not necessarily a new platform. And then two, I mean, and you read this and things like our own internal conversation and Google SRE stuff is if we encounter something that isn't automated, step one is automated. And step two is
46:56if it's, if you think it doesn't need to be automated, see step one, right? It's, it's just like automate everything or, or, uh, to, to use the, uh, uh, what was the word? Uh, uh, not automate, uh, atomic, but you know, whatever, whatever the autonomous, the intelligent, the smart, the wise automation is. And essentially like anything we don't have wisely automated, we're probably doing something wrong. And, and then our job, and I think this is where the, uh, an interesting shift of, uh, having ops people think in a more product mindset comes from is if we feel like we can't like wisely automate it, then let's make a new product that does, right? Like, cause at the end, that's what we need to do. Like our job is to wisely automate as much thing as pretty much everything possible. Yeah. So, uh, go ahead. Yeah. When you said, if it's not automated, automate it, think, you know, and then see step one. I, I think, uh, think of our brothers and sisters who sacrificed themselves at Netflix for this model and just don't beat them. Don't let their sacrifice go in vain. That's right. Make, make, make sure you have enough, uh, in your compensation package before you decide to sacrifice yourself. Take on, take on a big risk appropriately. Otherwise you should just focus on like your, uh, work-life balance, you know, don't, don't be a hero. Like they used to say in those kids, we would watch in the latch K date, latchkey days, be safe out there. Well, do either of you, do either of you have anything, uh, you want to add on before we wrap up about, um, I mean, especially on the, on the topic of like, like what is, what is, what is the, the sort of life and the thinking of, of, uh, of a cloud native ops person look like? Well, I will tell you, I'll wrap up for with a teaser for the next time, which is, I believe that we're going to see app counts, you know, fortune 1000 app counts somewhere between 700 and 3000 apps just on, you know, in general, uh, outliers being much higher, 15,000. Um, I think that we are going to see,
49:01you know, two, four, 10 X app counts at customer sites. Uh, and with the current tool sets and the current thinking, it's not possible to manage that. So I believe there'll be an emerging engineering, uh, practice probably called app ops because the platform ops is trivial. You can do it. I mean, our customers show at a 10,000 AI system requires eight people worldwide to run 24 by seven. It has no, it has no work involved in it. It's just, you know, 40 hours a week, daytime work. It's just not a problem, but managing 10,000 applications, plus you're going to have to start thinking about whole new structures for that. And so that's probably something to talk about next time. So yeah, yeah, no, that, that, that would be good. I mean, cause we, we often distinguish between, uh, let's call it two and a half operations roles, or I don't know who we is, at least in my mind, I do. And one of them is what you're talking about, sort of like the physical infrastructure, which, you know, someone's got to manage that, at least make sure that something's plugged in. And, and then, and then there's the, the platform operators who operate the platform as a whole. And then I think there's this other category that is not super well-defined and, and application operations make sense. Like if you got all these wacky microservices things running around, like someone's got to make sure all that's working. And, and, and that whether, whether it's people, a role or a team or whatever, that, uh, that function needs to be served. And I think is, uh, uh, uh, evolving, interesting area. How about yourself, John, you got anything you want to add building on the, uh, the Lego bricks that you just set for me? I think, you know, there's app ops and plat ops. There's, we know there's app, the guys that build the apps that then get operated. But what about plat dev do? And this goes back to Tony's comments about DIY. You know, we see kind of platform development as a shared responsibility between the, the new breed, the new breed of kind of IT operations. So you're automating stuff, you're building that into the platform, but also a pivotal, we build the platform. And so it gets us into interesting discussions about,
51:05um, using things like concourse pipelines to continuously deliver updates to your platform that you're operating. Um, but also, uh, more of a, uh, kind of a development, uh, side to the operations role that feeds into plat ops. So, you know, it's, we, we're still developing the theory around this, but, uh, our customers are really kind of leading us by the way a lot of this works. And, uh, uh, uh, so, um, I'll be actually posting a blog fairly soon of talking about how customers are taking concept up from pivotal and deploying those through, uh, through concourse into, uh, into their, uh, operating systems. Yeah. Yeah. It seems like an interesting aside. I mean, uh, is, uh, if, if, if, if you're in an ops role and you're not familiar with like, uh, CI tools, that's probably some after you virtualized everything, at least that's some good homework to work on next. If you don't know what's happening there. Cause that, that, that seems like a core, uh, a core service that, that operations people will be responsible for providing. It is the next iteration of cron, like operations people live and die on cron and concourse is the next version of cron. That's perfect. All right. Well, on that note, we always like to end in perfection or at least, uh, you know, just abysmal confusion, which is a certain amount of perfection if you like chaos, like I do. Uh, but I think we did the first. So as always, well, thanks for being on first. Uh, both of you, uh, I appreciate it. We, we've been planning this for, for a little while here and, uh, it's nice to have it done. So, uh, it's great time. Yeah. Yeah. So if people want to, uh, follow up or with you or, uh, you know, see you online or something, Tony, do you have some sort of a Twitter location or RSS feed people should subscribe to? What, what do you do there on the internet? You can find Twitter. I have an X and what, what was that that you broke up there?
53:05Nine, nine, seven Unix, like the prime number nine, nine, seven and the copyrighted AT&T term Unix, UNIX. Yeah. I always like, uh, there's, there's some person that, that, uh, likes a lot of podcasts and stuff I do, and I'm pretty sure he's, uh, some obscure chipset is his Twitter name, which is always exciting. How about your, how about yourself, John? Yeah. So you can catch me. I I'm Johnny a so J O H N N Y underscore a on the Twitters. Perfect. Well, as always, this has been Pivotal Conversations. If you want to get the most recent episodes, you can subscribe to it in your iTunes or your, uh, overcast or whatever a stitcher is. You can just search for Pivotal Conversations and add it there. If you want to go find us, uh, I post the most recent episodes. I mean, obviously, but I post them the fastest over in SoundCloud. So if you go to soundcloud.com slash Pivotal Conversations, no underscore space in that, you can see this episode and all the previous ones. Uh, there there's, there's some good interviews there. Uh, speaking of, uh, of, of some customers, one of the more recent, uh, customer ones there is with, uh, Opal Perry from all state going over, I guess you could call it transformation outside of the ops area on more of a IT as a whole and on the business side, which is pretty good. And, uh, uh, the, the most recent other episode we did is talking with, uh, our very own Justin Smith about security, which, which is a good episode. I think as with this one and with most pivotal people, uh, there's a, there, what turns out to be a nerdy conversation about nerdy stuff, but in a very non nerdy way. So hopefully it's, it's approachable. One of, one of the more, uh, nicer security people you'll ever talk with just as, as, as we were talking with Tony, uh, you know, on op stuff, not someone who's just telling you you're doing it wrong and you should go re-evaluate your life choices. Uh, so, uh, with that, we'll see everyone next time. Bye-bye.