That Cloud Native Lifestyle

Episode 2 · 2015-08-18 · 41:26 · SRT · archive.org · all Tanzu Talk

Well, you know, when I was growing up, my grandparents on my mother's side lived in Austin here, and we would visit them all the time. They gave me this nice perspective on the growth in Austin because they used to live in the middle of nowhere, and now where they live is comfortably in what we euphemistically called North Central Austin, which is a funny phrase I'm sure some real estate broker came up with. But my grandfather, he had this awesome din, which I think ruined me in a good way about wood paneling. It was full of wood paneling. And so my vision of like sort of like perfection in life, the situation you want to pan out is you have, first of all, you've got a den, right? Like that's a whole thing right there. But second, it's covered in wood paneling. And I have noticed in the video calls that we've been having recently, the house you're now in there in over in the California, in Los Angeles, as they say. In the California. It's full of wood. It's got wood paneling everywhere. So I've been like waiting to ask you, has this introduced a sort of sense of accomplishment and calm for you? Or do you not react to wood paneling the same way that I do? I'm not sure confidence and calm is the thing I'm going with, but it's a nice room that I'm sitting in at this moment. Do you feel like you need to pledge it a lot or, you know, polish it? Like how does one care for all that wood? I think that the weather and the way they set up, it doesn't need a ton of care. It's kind of, it's cured, if you will. It's been, this is a house that was built in 1926. So it's going on a hundred years of this wood paneling, I believe. And it's nice. It's, I'm surrounded by wood, wood shelves. There's actually also a stained glass window on one side of it that goes into the house. Oh yes. I remember you showing me that. That's very nice. It's a nice feature. And, and does, does it also, you know, does it feel like you're, uh, you're kind of moving around in every kind of mid budgeted sort of Hollywood entertainment thing often, which is like just filmed in the area, right?

Like it seems like you've got the, uh, the ranch housing around there. Like it must be very reminiscent of lots of movies and TV shows. I'm sure there's a bunch of 90 shows that are, you know, filmed within however, however far from here, walking distance maybe. And then you were down in Orange County this week. So you had a whole Veronica Mars feel to exist. No, no, no. I went all the way to San Diego. Well, sure. You drove through that. You know, I, I lump it all as the same reason. Just like I treat like all of New England as one sort of big city. I think, I think of the, uh, the kind of like LA, Orange County, San Diego thing is just sort of like one gigantic expanse of stuff. So here's a little thing before we get onto the, uh, to the real meat of this matter. I've never seen advertisements for Maseratis on TV before, uh, but now in fact I have. Ah, yes, yes. This is, this is like, I feel, I felt like the Austin tech community had arrived when we had those grotesque dice billboards of like geeks in their, uh, jockey shorts around town. It was, it was, it was a big moment for us. Big times. The times they, they are changing. Yeah, I, I did drive down, down the way. I, it was actually the first week of school. So I dropped my kids off at school, drove from Los Angeles to San Diego, spent two hours at a Gartner conference and drove back to pick them up from school. That was a very productive day. Yeah. Yeah. Was that, was that catalyst? That was the Gartner catalyst. Yes. And I did a, I did a panel about private paths. Is the, is it ready? Ah, well, were they banding about the phrase cloud native and things like that? I mean, that's, that's been the popular thing nowadays. That's, that's a good, good launching off point. Uh, I think we said that word and a few other buzzwords along the way, there was probably some microservices and continuous delivery and DevOps mentioned as well. Yeah. But the main thing that I think is a win here is, uh, you know, especially from the perspective of what we've been trying to do is that Gartner finally admitted that there's a such thing

as a private platform as a service. And then they, they had some interesting data that they said 52% of their inbound queries about, about platforms are about a private platform as a service. So that's a interesting validation. Oh yeah. Yeah. You know, back when I was at Dell doing cloud strategy, sizing the mark, getting any information about the private paths market was really hard. And I remember Gartner has a category called CEAP, which I always inserted an R in there to make it creep because I can't help but make a joke. But you know, it's a, it'd be nice if they converted that over more into just, instead of it being middleware and application stack, it'd be nice to track that as its own thing. I think, I think, I think that the market's kind of, uh, forcing their hand in that regard. You know, obviously if you spend any time talking to me, you know, how much I like the word, uh, has and, and how, you know, I basically tell everyone to stop saying that, but, uh, you know, they're kind of, they're catching up. And, and, and, and, you know, speaking of, of trying to, uh, reframe what paths is, if you will. So there, there's, there, there's a whole lot of, uh, I don't know what you would call it fun shoots and ladders when it comes to the phrases used for this stuff. But I think, I think we, and the people we talk with here at Pivotal have come up with some good framing and we, we still use, and I still like the idea of a cloud platform, right? But there's, there's this idea of, of cloud native that we've been dividing into essentially three layers, basically the, the application framework. And it's sort of, you know, that's, that's where you have your 12 factor apps and microservices and things like that. And then you've got this layer in the middle, that's the container orchestration, which of course you can reverse engineer that, that implies there's some containers involved. And then, and then the layer below that is essentially the infrastructure automation layer. And it's, it's starting to feel like a good way to divide up what something you and I and other people have been talking about a lot is, uh, so paths is a lot more than just sort of like that first layer. It's really all, well, it's a lot more, I should say.

And it really does get to that point of why we always talk about a platform and, and the need to have all of these different layers in there. Yeah. I think the acceptable definition of paths for me is, is this sort of API driven deployment layer, uh, which you, which you definitely want to, want to have, uh, if you want to do something like microservices or continuous delivery, then you're going to need to drive down the, the fixed cost of delivery, fixed cost of deployment, uh, you're probably going to want to do that with some APIs. And at some point, whatever you build to do that starts to look suspiciously like what people will call a paths, but, but that quote unquote, as a service thing, whatever that is, uh, is an application as well. So how do you deploy that thing? How do you manage that thing? How do you upgrade that thing? How do you operate that thing? Uh, that's, that's the stuff that's, that's at the layer below this kind of infrastructure automation layer that, that I think right now there's, there's no other project that, that has anything close to what we're capable of doing right there. And then, and then above the layer where you have the, the platform or the, or the quote unquote APIs for deployment, uh, there, there's a bunch of architectural patterns that are emerging, which if you, if you want to kind of reinvent the wheel, you're more than welcome to, but the, the things that we're able to give people out of the box right now with, with spring, spring boot, uh, and spring cloud is basically like this microservices, uh, Lego pieces that you can kind of put together. Uh, and many of them have been used to build, you know, whatever, uh, Java background or, or applications that you're already using, right? Like the Netflix is famous for, for, for having a third of the internet traffic pretty much every night. And they're using, we're, we're, we're actually using their stuff and they're using our stuff, uh, to kind of build the future. And, and you might as well take advantage of that, that code that's already there. Yeah. And, and, and, you know, I think let's thinking through the publishing schedule.

Well, we, we've actually, uh, published the last two episodes of this podcast are all about spring boot and spring cloud. And it is, I think that's my, that's my boy, Josh long. Exactly. He's, he's fun to talk with. And, uh, uh, you know, it is, it is, it's interesting to sort of understand cloud native through the lens of spring cloud, basically. And then the, the kind of setting up that, that spring boot does for you. Cause it's, it's a, um, I don't know. I mean, I, I'm an old Java person. So the phrase opinionated always like feels like the, the, the old wars of the mid two thousands to me, but it's a nicely opinionated way of how you go about accomplishing all that in Java. And, uh, it's, it really, it really demonstrates the cloud native lifestyle. I believe in, in having strong opinions. Yeah. And no, that reminds me you, uh, you tweeted a little while ago, what was it 2009 or 2008 that you sort of like, uh, turned your back on Java and like, like, like, what did you mean by that? Like what, what made you give up on it? And what, what made you like, uh, start looking at it again? Uh, I mean, this, I don't know how, how deep we want to go into this rabble. But there was a, there was a period in my career where I was primarily writing a Java code, um, back in the day where, um, you know, the first time I ever wrote Java was, was right when JSPs came out and everyone is so excited because now you could put the, you know, you no longer had to embed the HTML in your servlet code. You could now embed your Java code in your HTML and that was so much better. Uh, and we, we kind of all know like where, what a, you know, crazy tangled disaster. And, uh, and then the J2E stuff came out and, and, you know, whatever's going on. And I ended up working for some startups that were primarily Java. And along the, the funny thing was along the way I was doing all this, um, kind of computational science and that was primarily C, C++ and, and Fortran. And, and, and they always had like this weird disdain for, for the Java developers, which

I, I thought it was odd. But then after, after seeing how a lot of that stuff was built and some of the things that were going on, like I, I didn't start, like I, I liked Java in a sense, but the sort of the culture around it was very stagnant and confined to me. And then when I, when I ran into, you know, I started, uh, some of the Ruby stuff and working on Puppet and going to the Ruby conferences, then it was just really easy to get enamored and kind of caught up in the enthusiasm of that community. And, and that made me never want to really do Java again. Just, you know, it's, it's one thing that the technology, but the, the community itself was, was not inspiring at least to me at the time. Um, and, and there's this alternative community that was, was really trying to, to move things forward and push the boundaries and, you know, things like, like Rails and Puppet and Chef and the rest of that are, are all kind of part of that narrative. Uh, now, now you're seeing, you know, explosions of languages and people are doing things with JavaScript and the rest of it. But when, when you look at that full cycle, lots of people that are my friends that built some of these big startups, big web applications, they, they kind of all grab it. gravitated back to Java or many of them gravitated back to Java as this reliable, uh, you know, kind of battle hardened way to, to solve these problems at scale where, where it's much harder to kind of coax the, the, the Ruby runtime to, to do that. Yeah, no, no. I mean, you, you definitely, uh, you can see that in the, the, you know, the red monk where I, I worked a while ago has always done a good job of pointing out that sort of return to Java, if you will, uh, which, which is, which is always encouraging, but that, you know, you're also touching on something I've been thinking about a lot recently as I've been, uh, I've been typing up this series of like, what's the cloud native journey look like? And, uh, most of it is like a lot of, as we would say, cultural and process and things

like that talk. Like it's not too tightly connected to the technology. Uh, and I I've been reflecting on, like, as you were just saying, like, I guess you could call it what went wrong with enterprise Java. And, and I say enterprise Java apart from Java very specifically. And, and I think it's because they didn't really, and I should say we, cause I was in that bucket, but we didn't spend enough time on the non-technical aspects of things, right? All the way from sort of like architectural concerns to sort of process and, uh, how you organize teams and how you think about all of that. And, and it also, I think it to some extent explains why in the DevOps space and increasingly in, in the cloud native space, everyone's obsessed with culture, right? They talk about people problems so much because whether people implicitly remember it, or I should say explicitly remember it, or it's just kind of scurrying around in their subconscious, they kind of remember that like the people part is really important. So we should spend a lot of time on that. And, uh, you know, it, it doesn't, it doesn't seem like in the enterprise Java space, enough time was spent on that. And so it sort of explains why we spend a tremendous amount of time on that in the, uh, the sort of current era that we're in. I think there's a bunch of things that are happening and, and, you know, obviously the cultural stuff is something I spent a good amount of time talking about. And there's kind of a pendulum that, that swings in the DevOps community where on one hand people say, oh, you know, we more need more culture than, than people say, oh, well, like everyone's talking about culture. We, we kind of need to talk about tech and it sort of swings back and forth. And then I would say, and this, this applies to the automation space and really kind of all three layers of what you just set up when we, when started the conversation that I think that the, the old mentality, which, which I'm going to say is, is transitioning in the cloud native mentality was to just do whatever, right? And so, so Java automation, that's a good way of putting it all the rest of the

this stuff from, from kind of that last generation of, of, of work is, is like, let's just do whatever. And we'll put the features into that thing. And that's why you end up with these kind of bloated, unmaintainable, unmanageable, uh, applications. And I think that at least the way I'm going to do things moving forward is have much stronger opinions, right? I was on, I was on this panel at Gartner and one of the things that was a bit of, uh, contention with some of the other panelists is that they're, they're arguing that their platforms will just let you do whatever. And I think that, and I believe this very strongly that ad hoc automation is actually a problem masquerading as a solution and that you just end up with, with more, more problems, uh, or, or at least, uh, you know, kind of proportional amount of problems going forward. If you don't look at how all these things integrate from, from the patterns of the architecture, to the patterns of the, of the infrastructure, to the patterns of the automation, all sort of in an integrated fashion, if you have, if you've given yourself the leeway to do anything, then you have to do anything to recover that, right? You can't, you can't make and enforce promises about what you're actually going to have from a behavior perspective, from the, from the scalability perspective, from the reliability perspective, from the security perspective. And, and I think that what's evolving and what I see as kind of the cloud native, um, mindset and architectures is, and, and this is actually pretty explicit. If you listen to people like Adrian Kokroff from Netflix talk, it's like, we didn't, we didn't give self-service automation to just do whatever. We automated simple patterns. We automated predictable patterns. And it's that, it's that array of predictable patterns. That's this array of kind of battle tested architectural, uh, paradigms that I think is emerging as the, as the new standard. And that's,

that's, what's exciting. That's where you, you know, you, this thing will scale, you know, this thing can be managed. You know, this thing is secure because you constrained what you're going to allow. And in return, you can keep stronger promises about that. And one of those promises is, is self-service. Uh, other promises are, you know, this long list of quote unquote abilities. And, I think that's, what's exciting. Yeah. And, and that, you know, to use my, uh, my sort of like ever, ever expanding pigeon language for understanding the world, it's sort of like, uh, I, there, there's, there's a certain amount of, of, uh, local optimization that destroys the big picture that goes on when you have that, just do whatever mentality. And I think, uh, you know, I'm not often the one who like kicks sand in other people's faces, but if you look at what a lot of the conceptual and product-based competition of ours is up to, they tend to focus on just one layer of, of that, that stack. I mean, we, we neatly sorted it down to three layers, but it's sort of like, you know, if you only focus on, on packaging or you focus on deployment or you focus on the framework that you use, you really optimize the crap out of that one thing that you do and you probably do it well, but in order to sort of like make sure that things work in the large, you've got to look at the whole system end to end. And when you start doing that, that's when you start forming opinions that may, may not make perfect sense, uh, at first to sort of like one node in that, that area. So like some operator may not want something like something or a developer may not like something or so forth and so on, but you're sort of like have that whole end to end vision, like those three things we were going over because otherwise it doesn't really work out so well. And I think there's plenty of historic analogs. Like we're just going over like enterprise Java, where there's a bit of local optimization at parts of the application life cycle. And what we're trying to do, I mean, I always look at the tech industry is like two steps forward, one step back, essentially. Right.

Just sort of like slow progress and figuring out this stuff, two steps forward, one step back, one step sideways. That's right. Right. You know, and then several steps trying to figure out where you've ended up. It's like, if you get knocked out by a zombie and you wake up late after the commercial break and you're trying to figure out what happened, but anyway, I mean, I think that's exactly the point framed in a, in maybe a little less complicated way. I think if you look at the specs on, on an iPhone today, that it arguably doesn't have the best hardware for, for nearly any component. But, but the, the, you can't argue with their results in the market. You can't argue with their experience, the experience they've created. And so I think that if you, if you look at things more holistically in an integrated fashion from, from top to bottom, then the, then the types of efficiencies and experiences you can create are, are, are very different than if you're optimizing some, some component in the stack. Right. And, and I think, I think, you know, as, as I've been writing up that, the cloud native journey stuff, that's, that's what we've seen amongst our customers is they almost, they, they, they have a view to the big picture and what the end result is going to do, but they, but they take these, these sort of like the, the kind of hockey stickish curve of small changes, small changes. And all of a sudden they, once, once they learn the process and the culture and the mindset, they can just suck in all the other technologies and do things in the large. But again, I think it comes back to having those, those three layers of the stack that look at everything, which, which I think is hopefully that's what this idea of cloud native ends up becoming is not only the technologies, but the sort of like big picture process end to end that you wrap around it. So one of the big differences in the, in the panel, and there were a lot of things we agreed on actually, but the big difference in my opinion was where people wanted to, to, to make opinions and, you know, how much they were willing to, to trade off investing in the future versus sort of optimizing aspects of the past. And I think from Pivotal's perspective in the way I want to think

about things and the way I want to build things, I want us to be much more like, like doctors where we're, we're giving you something that will, will help you be well. And this is the, this is the path forward. This is the way that you're going to, if you want to, if you want to be well, like this is how you live versus, Hey, I'm, I'm a waiter and I'm going to take your order and whatever you want, like, I'm just going to bring it to you. Right. And, and as a consequence, if someone asked me right now, how do you do this complicated thing that, you know, is it's, I want to install this thing and it's got a bunch of state and there's a bunch of steps. And then at the end of that process, this thing set up, how do you do that? How do you do that with Bosch? Then I just say, you don't, don't do that. Why would you want to do that? What I want to build here are things that are easily recovered, easily scaled. And what you just did with this complicated thing that has a bunch of water and a bunch of state and a bunch of steps is set yourself a lower bound for how fast you can possibly recover when that thing inevitably fails. Right. And, and that as a consequence of like, you know, a bunch of these other things where people are talking about their, you know, their problems with their culture, their problems with their downtime, all these other things, half the time when you look at that, you know, people are, I was just at the agile conference too. And people were talking about, you know, agile, we want to scale agile. The reason you can't scale is because your architecture is this monolithic thing. That means everyone is gated on everyone else. Right. If you want to scale your process, scale your architecture, you want to fix your uptime, fix your architecture. There's a lot of these things, you know, and, and in some ways, some of the agile narrative probably rotated people off of this, but architecture actually matters. Like the day two cost of operating different architectures can be vastly different. And that's why I think you see this, this movement. And I've argued this in some of my presentations. And I just made this statement at

the agile conference that these microservice architectures are the natural evolution of people who need to change things, move fast and move at scale. If you don't, if you don't need to move fast, if you don't need to be at scale, then it's like you have a lot of other options, but if you need those things and that's, that's the evolution, that's what people did because that's the best way to do that. Yeah. And I think, you know, the, the, the agile community had the chance to learn, uh, how, how having good architecture helps out with one of their core tenants a long time ago, which is like, uh, if you can't test your stuff, you're doing a bad job. And so write your stuff so that it can be tested, which, which sort of seems obvious in hindsight, but, uh, like I remember at the time it, it took a lot of rethinking about how you architect and divide your product out. And similarly, I think analogously, like, like, as you were just mentioning, there is, there's a lot of, let's just call it cloud architecture principles, like microservices and 12 factor apps and other things that come into play. And those are there for a reason because, because it means that you can run it appropriately and get all the benefits that people talk about. And, you know, it reminds me actually went to go look up this point in that conversation you had with, uh, Matt Curry a while ago, where you guys were kind of joking, like for years, people have been telling you, you know, high performing companies like Amazon and Netflix have been telling you how they operate and what technologies they use. And everyone's always like, yeah, but you don't really do that. What do you guys really do? You don't really have small teams and you don't really force people to manage everything. That sounds crazy. And, and it kind of amounts to that. And, and all of that stuff is sort of like a collection of opinions about how you need to operate in order to, uh, really, you know, kind of be in a cloud native sort of era and mindset. And it starts to become important to pay attention to them and have that, that larger view of things. And just sort of,

instead of myopically looking at your one little part of it. And, uh, so, I mean, the whole point is like, it's important to actually take seriously these recommendations, these opinions that people have. Well, one of the things I've come to believe, you know, being in this industry for over a decade going on almost the second decade now is that telling someone a truth that they're not ready to hear is the same thing as lying to them. Right. Right. There's just, there's no way that they're going to believe you and they'll just think you're lying anyway. So you might as well just lie to them. I think it's exciting to see the evolution. I think that it's exciting to see, and we, you know, we take for granted some of this stuff because the way Pivotal engineers is test driven development all the time, pair programming all the time, a bunch of the stuff that, you know, kind of a lot of people aspire to do. That's the way Pivotal lives. And we really try to walk our talk on a daily basis. And as a consequence of that, you know, we're, we're, we're learning and we're growing and we're, we're building these things with our, with our customers. And there, there's a lot of stuff that is emerging by necessity, right? Like that's the mother of invention. And if, if the patterns work and you can operate it, then that's, that's the, that's the real deal. Uh, I think that the, the past was sort of dominated by, uh, applications that didn't really have the need to be run at these scales. They didn't need to necessarily be changed. Like it was an advantage, but you didn't have the same kind of Darwinian pressure that a lot of these, these organizations are facing now. And, you know, this is a quote that I've made before, but someone reminded me that I made it in their, in their presentation with CenturyLink this morning, you're, you're either building a software business or you're losing to someone who is. And if you believe that they need to do everything you can to enable that. And if you don't believe that, then that's fine. And we'll go back to Deming on this. There's no need to change. Survival is not mandatory.

Yeah. And, and that's, that's almost like the, uh, the sort of first principle for why you would care about all of this is you want to become a software organization. And, and to your point, it's, it's, it's, to some extent, it's almost a take it or leave it thing. Like it's, it's obvious to folks like us on, on the, uh, on this side of the fence that that's a good idea, right? Like that's the punchline of survival is not mandatory, but it is, you know, it gets back to this point of, and therefore, if you want to be a software organization, here's how software organizations operate and what they do. And it's not like just weird window dressing. And, and, you know, I was reminded of this when I was, I was out in the, um, the field talking with, with a, uh, rather large company. And we have this, uh, RFQ that the Pivotal labs people did, uh, with the government recently where they basically, they took a pretty simple application. Uh, it would, it would test out if, um, if, uh, you know, if, if your, your medications, your, your drugs, your prescription drugs would conflict with things, right? Like I'm on this, this prescription drug and I want to have a bottle of wine. Am I going to die? Like it would, it's pretty simple, but it was scoped out to be a, uh, a small thing. And within eight days, they basically built this application and it's, it's a good presentation that you can go look over in GitHub to get a sense of like what, um, one of the better representations of what the cloud native lifestyle looks like, so to speak. But one of the, one of the things that I always like to explicitly point out to people that I was doing back in the meeting with this big company is there's this one bullet point where in the first day they're like, oh, and then we could set this all up and get it running because we were deploying it on a Pivotal Cloud Foundry, right? Like on a fully automated cloud platform. And so we could deploy code on day one and just keep deploying and do all of this deploying daily and getting user, user feedback and information and working on it and deploying something after eight days because we were using this. And then they never mentioned it again. And it's easy to kind of gloss over the fact that like the, I don't know, maybe like the, the, the two and a half of the layers we just mentioned,

they spend most of their time up in the application layer, but the other two layers of container orchestration and infrastructure automation are just like taken care of them because they've installed this platform. And it was interesting going over that with, uh, with this big customer because their first question was like, oh, but those are like highly skilled people who like know what they're doing, which is true. But on the other hand, like one, they had this technology in place that allows them to move fast. And then two, like the things that they do really aren't that like difficult. It's just like, here's a set of principles that they follow. And like, if you want to operate that way, just start doing those things too. Like, it's not impossible for you to do it. You just have to convert over to thinking that way. And, and, and I think, I think that's going back to like why we talk about people and culture so much. That's a bit of the, the shift that has to happen in people's minds is we're not really, and this is, this is a good thing that we're saying. We're not really saying just like install this technology and everything will be dandy, but you know, get the appropriate technology stack and then you can, and then it makes it easier for you to change your process around to be these sort of like, you know, like ninjas or heroes or unicorns or whatever the nomenclature of the day is. Right. And as, as you're always fond of bringing up, right. Like as Adrian Krakow said, you know, they, they didn't just sort of like birth unicorn people from a, some green vat of goo. They hired them from regular enterprises and, and made them who they are. We hired them from you. Exactly. So, you know, there's, there's a tremendous amount of hope around being able to do this. And I think, I think what's nice is that the technologies actually seem to work this time. Like, like if you have that big picture view of putting everything in place and kind of using them in the way that they're intended to be used, really all you need to worry about is culture and people things, which in comparison to some technology that's lame and not working is a solvable problem. Yeah. I think this is a little bit different topic, but the, you know,

the, the, the types of things that are happening in 2015 in a world with Twitter and GitHub make it kind of hard to sell the old enterprise, you know, legacy products that are kind of based on asymmetric, asymmetric access to information, right? Like the, the old, the old school enterprise software business was based on, you know, stake and stripper driven deals with a bunch of, uh, kind of used car salesmen on steroids, driving the, driving the marketing into a customer that doesn't necessarily, they're not sophisticated about the technology and there's no way to become sophisticated about the technology, right? When you have an open source project, when you have a bunch of other people that are building on, on the same core, then it's not a mystery, right? It's not a mystery about what, whether this stuff's actually capable of. And I think that's a big thing. And then I also kind of want to dovetail off some of the stuff you just said and plug a talk that I have coming up in London at a conference called operability.io where what I want to talk about, and this is really sort of the journey of configuration management and some of the, you know, things that I've seen and been through, but there's, there's certainly things you can automate and, and this automation renaissance that's sort of driven the last, uh, few years of this. But at the same time, the things that you're actually choosing to automate and the patterns that you're, that you're driving forward with have a, have a huge impact on that day two cost of operations. And, and while you can conceivably automate a bunch of that stuff, uh, it doesn't all, it's not all equally operable. And so I have a talk about what is operability and how does that, you know, how, how are the architectures at the application level interact with these lower level promises from a platform to give you something that is or isn't operable? Yeah. Yeah. When, when is that operability.io conference?

Oh, let me check. It's September 20 something. Let's see. Let's see what my talk is. September 24th and 25th in London. And I have the first talk of the day on the 24th. Yeah. I mean, I mean, that's, that's, that's, that sounds like there's a little bit of crossover to the, uh, uh, the talk you gave way back when at, uh, what was it? Configuration management camp. It was, it was, uh, it was some similar ideas there. Yeah. So configuration management camp, I talked about Bosch, which, you know, going back to the, the, the three layer cloud native cake that you, that you cooked up a moment ago, that's sort of the bottom layer. We're here. I'm, I'm probably going to spend a lot more time talking about the top and, and the architectures of the actual applications and the, the implications of choosing. It kind of goes to, when you think about the, the goal of having something that the meantime to recover is driven to towards zero, right? If you can get to something that you can recover instantaneously, then by definition, you're never down. Right. And so these, these patterns of architecture and load balancing and, you know, single points of failure and just thinking about how all that stuff fits together in a way that the people can make sense of, I think is sort of this emerging architectural discussion that's, uh, in some ways it's really been missing. Um, and, and part of that is because not, not a lot of people have, have had the experiences that kind of drive you to where this stuff makes sense, right? If you've never been through the pain of actually growing, uh, uh, rapidly scaling service, then some of this stuff doesn't seem to be a big deal. You're like, well, why don't I just do this thing? They seem in the small, uh, they, where you, where you don't really have to scale and you don't really have to move fast. Then, then things seem like they're roughly equivalent, right? From a kind of a autumn automation and operability perspective. And, and it's really

only under, under the load and the, and the speed and the rest of these other things that come into play when you're quote unquote succeeding that, that a lot of this stuff starts to be a differentiating factor. And so I'm just trying to kind of collect some, some thoughts and crystallize those and, and provide, uh, I don't know, just a little bit of clarity. I feel like there's this missing operability is trying to, to, to kind of fill a little bit of this, but there's this architectural discussion that's happening that's sort of focused on these abstractions of code. And then there's the system architectural discussion. This, this actually kind of missing from the, from the industry that I would love, I would love to see someone fill that out. And I mean, maybe we should, maybe we should just organize that conference. Yeah, no. And, and, and as you were, uh, as you were pointing out earlier, right, there's, um, uh, it's, it's, it's, it's hard to find a lot of examples of sort of everything in the cloud native stack. Like, like, like at the moment, you know, there's lots of conversation that's highly optimized on each layer. And there's lots of people worried about like container orchestration or containers or strict infrastructure automation. But, you know, other, other than ourselves, there's not that many people who sort of like have a studyable, uh, open example of doing everything. Right. And so it's, it starts to, it's hard to emphasize that people should pay attention to the big picture when not everyone is sort of like producing the big picture, but it, uh, I mean, even, even if you're not going to, yeah, even if you're not going to have like this fully integrated, um, thing. And, and I know, you know, lots of, lots of people, lots of places that have built deployment pipelines, they build their continuous delivery, you know, microservice deployment pipelines, even if you're not going to have like, everything is like this fully integrated vision that the cloud foundry, uh, and Pivotal are giving you right now, there's, there's a ton of value in just like studying these patterns, um, uh, of success and failure and, you know, failure characteristics

have a, have a huge impact on your operational capacity. And so being able to, to plug that in versus, I mean, one of the things that I see emerging in kind of the DevOps narrative or whatever you want to call this sort of cloud native journey is moving from a mindset where we're trying to minimize incidents to a mindset where we're trying to minimize the time to recover. If you can get your time to recover to zero, then by definition, you never have an incident where if you have, uh, and typically the way this, this gets implemented is a bunch of, uh, signatures to do change, change control, uh, that tends to lead to very brittle systems that, that maybe they don't fail quote unquote as often, but they tend to fail catastrophically. And that's why you see things like the chaos monkey, right? Like, I mean, going back to things people don't believe, believe, believe the code is there. Netflix literally destroys parts of its infrastructure as part of their day-to-day practice. They inject failure into the, into the application, into the infrastructure so that they can be certain how that stuff will behave, how that stuff will perform. And there's a bunch of patterns that come into that, that dovetail into what I've already been talking about, right? Like the way that these things are architecture, they can realistically lose a third of their capacity, uh, uh, you know, along specific failure domains and, and never miss a request and never stop, uh, serving your, your, um, business. And I think that's a big change for people. Yeah, it's, it's a nice, uh, what do we have? We have a project called the, uh, chaos lemur, if I remember that, that, that helps out with that, which is a equally funny name, but it is, uh, no, that's a perfect example of things that people think are like made up hokum that people talk about. But at the end of the day, it's sort of like, uh, you know, it's a, it's the ultimate test. It's, it's a good, it's a good safety test to have. It's

like doing fire drills and all those other sorts of things. I, it's sort of those, those, one of those things where once you've been initiated, once you've kind of gone through the veil and come out the other side, like you never want to go back. Once you've sort of been in a, in through that transition where you learn how test driven development works and you, and you start to do it and then you understand the level of confidence that that gives you, then you never want to go back to not having that. And it's the same sort of thing with a bunch of these other, other practices, a bunch of these other tools, a bunch of these other architectures. Like why, why would I go back to this thing that like inflicts pain and fire on me on a regular basis when I could just do this other thing that, you know, on face might seem, uh, you know, a little bit more work or whatever in the, in the, in the beginning, but the, the long-term operational costs, the day two forward costs are, are considerably lower. Well, I think that's a pretty good place to wrap up. And, uh, it's, it sounds like, let me see if I'm setting this up correctly. It sounds like you're, you will soon deliver the second part of sort of like Andrew's, uh, cloud musings. The first one was sort of like at the Bosch level, sort of configuration management camp. Right. And then, and then you'll move up to the upper layers of speaking about like frameworks and things like that at operability. And then eventually we'll get to that other layer and then we'll have a, uh, a little chat book. I mean, I'm just, I'm just fortunate to, to be in a position to, to watch a bunch of these things happen. And, you know, as a consequence of, of circumstances of my career, like I basically got a front row seat to watch, uh, the velocity crowd build the big web. And that's been going on for a while. And, and now we're just sort of emerging and taking, I feel like Pivotal's mission right now is really taking all those patterns that were successful, building those kinds of infrastructures, those kinds of applications and packaging it in a way that it can be consumed by, by anyone who wants to consume it. And that's, uh, that's pretty exciting.

Yeah. No, it's, it's, it's, it's always, uh, fun to be working on a stack of opinions that are useful that, you know, I, I, it always reminds me of the Thomas, the tank engine thing. You just want to be a useful engine. No, I'm, I'm also been known for causing some confusion and delay, but that's a... Oh, you don't want to do that. That's another topic. Confusion and delay, the worst offense on the Island of Sodor. Exactly. All right. Well, with that, this has been another, uh, Pivotal conversation. You can go, well, I'll put a bunch, some links into the relevant things in the show notes, which you can find at pivotal.io slash podcast. And as I'm fond of, fond of saying, if you like the plural, plural, you can put podcasts in there. Either one will work and we'll see everyone next time. Till next time.

Tanzu Talk · 🍕 Get more pizza.