Process, Automation, and Continuous Everything: Analyst Report Insights

Episode 169 · 43:08 · SRT · archive.org · all Tanzu Talk

Okay, well, welcome back, folks. We've got another episode of Tanzu Talk. And with me today, I've got Rita Minacci, who leads analyst relations for Tanzu and Derek Harris, who you may know and love from the Cloud Native in 15 Minutes podcast or the Intersect blog on Tanzu.vmware.com. Derek, Rita, you want to say hello? Sure. Hi, gang. Yeah, Rita's definitely been on this podcast before, sometimes just getting us up to speed on what's been going on with the analyst community. And today, we sort of have a way of summarizing and recapping a little bit of some of the content that is currently available on the Tanzu.vmware.com content library. If you go there, there's a couple of Gartner reports that we currently have distribution rights to. And so, you know, somewhat limited time. But if you go on, it's a great way to get access to some of the research from some folks, some of the analysts who are out there talking to a lot of different organizations, and sort of identifying some patterns in what they're noticing across both the technology landscape as well as what is driving change inside enterprises. So what the three of us decided to do is sort of divide and conquer a little bit, and each dig into one of these reports. And now we can actually, we're going to educate each other and any of our listeners here on what kind of takeaways did we find from our different readings. So let's see who wants to go first. I'll go first. And then, and then we can go from there. You know, mine's definitely the report that I chose to, to read and kind of, and discuss is from Forrester. It's written by Charlie Betts.

He's also on Twitter, if you want to follow him. He's been covering DevOps and the like for a long time. He was one of the reviewers on the Phoenix Projects. And the title is top 10 trends that will shape modern infrastructure and operations in 2020. Well, who doesn't love a top 10 list? I mean, this is like the buzzfeed of Gartner. Yeah. I got to be honest, like 10 was a lot in this case. I was like, oh my goodness. I mean, but there were definitely, there were, I mean, there were, there were definitely some areas where I got a little bit lost. But the things that stuck out for me that I think were also probably coming through in some of the, some of your reports are, uh, that, um, uh, process is how we think about process changes. Um, how I know folks need to think about collaboration has changed and the need for automation, right? How automation is going to change their, their jobs and their roles. Uh, and one of the things that it talks about here, and it's kind of this elephant in the room thing, it's like, okay, so with all this automation and things changing, what is the role of I know, right? Is it becoming unnecessary if you think of things like in terms of product teams and the like? And the, the point he makes is that no, it's just now you have denser work, right? It's not as much work, but the work you're doing is perhaps more strategic, more value at, and more aligned to the business. And I've also heard this from, from other analysts. You know, there was one analyst who talked about how he automated himself out of a job when he was at a big financial firm. He said, oh my God, what did you do? He said, I worked on more strategic things. So finding that and finding a path to do that, you know, and this kind of gives you some ideas, I think, and refining how you can take all the skills you have, all the, the learnings that you've had as an I know pro understanding the systems and, um, and really, uh, bringing that to the, to the table, if you will, or to the party. Yeah. I mean, that's, uh, that's cool that he's, he's calling out the elephant in the room, uh, for, for what it is, because I think that that's one of those unspoken things that sometimes

comes up when, when folks are looking at a lot of the cloud native, uh, technologies and people get really married to their process, whether it's conscious or not, but they just, they start to focus in on, well, it's like, this is the way we've always done things. And whether it's because they, that process allows them to feel safe in the face of, uh, past experiences without that process where things were insecure or, uh, they went down or they were out of compliance. And those experiences feel pretty yucky. Um, and so, okay, now we have this process and then everyone gets really invested in the process and they're not always willing to, to revisit it. I know I'm kind of blending, um, your first point a little bit, but I feel like automation and process are like two sides of the same coin. Yeah. It's interesting. I mean, he, he, he goes into this whole kind of vicious cycle of, of, of, of process and productivity. Right. Um, and he quotes, uh, uh, Jeff Bezos and as well, where he says, good process serves you so you can serve customers. But if you're not watchful, the process can become the thing. Um, and that can happen easily in large organizations. You know, he has, again, this vicious cycle of like, okay, you're not showing your productivity. So let's add more process, which detracts from your productivity. It's got a little visual there too. The process vicious cycle is called. Oh yeah. Who doesn't love a visual of, of a vicious cycle? I'm expecting like there'll be dragons and maybe a squagger or a squagger. Isn't it supposed to be a virtuous cycle or a flywheel? This is the, this one goes counterclockwise. Yeah. Well, except if you're in the Southern hemisphere, then the virtuous cycle goes clockwise and the vicious cycle goes counterclockwise or something like that. Yeah. So our, our friends down under sometimes experience things a little differently. Oh, where was I? Um, you distracted me with the squagger. Squagger, I feel like does beg

a little bit of explanation because we, we all just recently got exposed to this concept of a, of a hybrid animal of a squirrel tiger, uh, combination, really a beautiful creature that exists only in, um, you know, Photoshop, but, uh, you know, if you can imagine like the, the tenacity of a, of a squirrel and the, the power of a tiger, that's, that's a fearsome beast. Um, even if in a small package. So yeah, like, you know, what, what that reminds me of kind of the idea that, that Bezos has this quote about process becoming the thing, it reminds me, you know, about, uh, maybe nine months ago or so we had Len Hardy from, uh, Northern trust on, on the, on the podcast for, for listeners may remember that one. And he, he really talked about unwinding the folklore. And this was particularly around compliance and like having to revisit how, you know, the highly regulated organization, they were in compliance as they were deploying to, uh, new platforms, um, preparing to move more workloads into the cloud, but also really just seeking, you know, that automation, um, uh, experience, right. So that, that they could get to production faster, but so many of the blockers along the way, you know, we're sort of held up by this notion of like, well, this is how we stay compliant. And if we don't do this, then we're not compliant. It's like, well, actually you can just find another way to be compliant. Like being compliant is really just, you have to understand the underlying regulation. So, um, that comes up a lot. And I think a lot of people, um, it takes, it takes some fortitude to, to spare down those processes, particularly when there's kind of the, the gravitas of things like the compliance and security, um, where it, yes, we of course want the same goals, but we can approach this differently and we can change our process.

And then the other thing that reminds me of was a couple of weeks ago, um, we had Neville George of Comcast on the podcast. And I really liked this, this concept that he talks about where, um, it challenged, I think a notion that we have about how processes change, um, and really brought to, to, to light the, the role and the power of the individual to be willing to work, uh, differently. And that, you know, process change sometimes gets associated with, you know, we brought in some consultant and they analyzed everything and they made recommendations. And then we had a, you know, the whole process takes 18 months from analysis to roll out. And it's all very top down driven. And, and he pointed out how there's also just a lot that individuals can do when they're just willing to, to reach out across the aisle, um, to teammates across different silos. And then they're able to actually change the way things get done because they've taken the time to understand what a counterpart is trying to accomplish. And that sort of grassroots approach, um, I think it's been really powerful, uh, for, for some of certainly our, our customers who've been able to accomplish a lot of change. So yeah, really like that, that connection between process and automation to me is, is really interesting. And it's, it's interesting that both of those are covered in this top 10 report. And, you know, and we can probably, I'm sure we'll get into this a little bit more later. There are, at least, I mean, the concept of product thinking and product teams is in there in two different, uh, two different trends. So that's something I definitely want to, uh, make sure we discuss because that's, uh, really important. And it's a core tenant of a lot of the stuff that, that we espouse, um, you know, in Pivotal Labs. Yeah. Well, I mean, and that, that's actually an interesting segue, um, into the, to the report

that I was looking at. Um, but you know, I want to make sure Derek has a chance to chime in on the, the process and automation question and then, yeah, let's hear more about the, the product mindset stuff. Process and automation question. That's right in my sweet spot domain. I mean, yeah, I mean, and I think this is just a process to me. It's one of those things where like you mentioned, and I think you're referring to Len Hardy, but like you have to understand the rationale. I think it's important to understand the rationale, the reason that the process exists and then figure, yeah, like you said, figure out a different way to be compliant because it's not, it's, it's never like these things are set in stone or, you know, if a process has been in place for a decade, there's probably, probably the reason that that process was originally in place as, has evolved as well. And the idea that you see here, it's about moving to the cloud. For example, it's a cloud is insecure because you know, our, our, the compliance requires our data centers to be, well, we know whatever the rules are, wherever, you know, stuff had to be located, right? But stuff changes and then the world moves around you. And the idea that, you know, you're, you were, that you could not be compliant operating in the cloud as you know, Ben, and sometimes sure, maybe take some legislation and that sort of, if you're a big company, you can push with some stuff, but like, or regulations changing, but like, there are things happening around you that you have influence over that. Yeah. The idea that, I mean, getting stuck in a process because it's there is probably historically a very foolish way of going about things. Yeah. I like that point you've made about understanding why the process is there and, you know, no one's saying process isn't necessary. In fact, you know, it's a, as, as Charlie puts it, it's a, it's a powerful tool that you can use to empower people or, uh, it can lead to, uh, over managing or, uh, you know, complicating things. Right. And I, I imagine that, um, a process that allows empowerment is one, like he talks at some point in the report about change management,

right. And getting rid of change management, management boards. And that would mean you'd have to have a process to allow teams to make changes themselves. So they are automated. They can automate the, either automate the process or they're empowered to make those changes and not have to go to this change board and all that stuff. So. And I think that in order to introduce automation, you do need to define processes because that is, if you don't have a process, you don't have anything to automate. Everything is ad hoc. Exactly. It's only when things start to become repeatable that you can introduce automation. And so the repeatability of a process is exactly what looking for to automate. But I think that the challenge is then also, you need to be willing to revisit processes. And as people are trying to introduce automation, that's where they run in, at least in my experiences, they're running into friction because the current process doesn't really allow for automation. It's not, it's designed in a very, you know, uh, analog world. Like, I mean, if you go back not too long ago, or certainly in plenty of, uh, organizations, government entities today, right. The process involves paperwork. Right. And it's so the perfect example of where it doesn't lend itself to automation because it's literally the DMV has a form. Right. But if you start to understand to Derek's point, why do we have these things? Why do we need to capture this information now? Can we start to digitize and then automate, et cetera? But, um, even processes that, that aren't paper-based, right. Can still be very manual. If it's like a certain, like there needs to be a change board review or certain people need to sign off. And, you know, the classic example is, you know, listening to, to Kyle Campos, uh, uh, you know, over at Smarsh talking about how, when he went back and, and actually interviewed all the people who were on the review chain, a bunch of them were like, yeah, I don't

know. I just, I get these things. And I, I, I click this button. They were, they were approving things. They were part of this chain, but they weren't really adding any value. Um, it was just part of the process. So classic example of like, maybe this process should be revisited. All right, let's, let's switch over to, uh, the, uh, the, the product thinking point that's in this I and O trends piece. And then I'll jump off from there because that, that dovetails really well with the, the, the report that I looked at. Yeah. I mean, it's all the rage, right? Product thinking is a new black. Um, I mean, I was the case, but I feel like it's, it's, it's still too niche, but maybe I'm wrong. I don't know. Um, I will say that I, the first time I heard this concept, I loved it so much because it gives life to the platform if you will, right? Cause you think about platform teams and it, and it, again, I think it speaks to people feeling more connected to the work that they're doing. So I'm getting a little, I know I'm getting a little wishy-washy or maybe a little touchy feely here, but, um, I know there's more to it than just, you know, really recognizing your platform as a product and such requires care and feeding and managing and iterating. And I mean, if you think of it, if you think of it as a, as a product, you're going to be constantly improving it, right? Cause you don't just do a product and throw it over and be like, okay, now it's it. And this is it forever, right? You're going to, you know, make it better, um, either make it more performant or add more features or whatever, more secure, whatever it is. So I love that idea. Um, and then I think, you know, that also lends itself to the notion that, you know, of, of developers being your customers, uh, in terms of an internal perspective. I just think about, um, conversations with, with, um, Brendan A. from T-Mobile and he's like, oh yeah, our customers. And like clarify that, right? He kept using the term customers, meaning they're developers. And I just, I really liked that. I love this idea. Pride is a powerful motivator. I mean, anyone who's, uh, had to deal with, you know, small

children, get them motivated to get themselves dressed and do their homework and, you know, get potty trained or whatever, whatever milestone you want to pick. Like so much of that tapping into, you know, that individual sense of, of pride is, uh, is a really powerful way for them to, uh, take on and, and push themselves to the next level. But also, you know, when you're looking at a team and how they're structured, like, yeah, let people have a sense of pride in their, their work and having that product mindset gives people, I think that opportunity. And it seems like a really powerful motivator. And I think it also just taps into that, that entrepreneurial spirit that many people have, you know, even if they never packed their bags and went to Silicon Valley, uh, to play that, you know, play that game. Um, you know, those folks are, are all over the place. And, and when you can tap into that, then that's like, you really bring out a lot of the best in people. So that was just to, I'll, I'll jump off there. Well, you know, Derek, feel free to chime in, um, disagree. Uh, but that's, I, I, I don't think that we're really at the point yet where the, the product thinking is the new black. I, I feel like we still have a long slog before folks have really internalized that in its main, it's true. I know. I think product thinking is the thing that's been down the Paris and Milan runway. Can I make a maybe off referral, like not exactly accurate fashion reference. And that's very good. People on the cutting edge are aware organizations on the cutting edge, but for everyone else, it's, it's very, I hear, I hear it thrown around and it took me about 10 references internally to finally start to wrap my head around it. But like a lot of things

that I hear internally, and then when you try to apply them, when you look for them in the outside world, you're just not seeing it as frequently. So. Yeah. Yeah. Yeah. I mean, it's like, you know, I've been working in product marketing, which is actually pretty aligned to that thinking. And so it was easy to get, but I also have to remember that like, I'm already in some ways doing that job. So, uh, it's, it's easier for me. And, you know, I don't know. I'm a, I'm already a subscriber to the women's wear daily. If I, if I'm going to bring you back to the Paris and Milan runway reference, I'm trying, Derek, I'm trying. Those are like, I read the devil wears Prada like 15 years ago on a beach. And that's what I learned is that the people who are really in fashion read women's wear daily to know what's going to, what's going to be showing up in the magazine six months later. Yeah. Clearly a lot of deep learning from that. Mm-hmm. Um, I was going to say one of the things that he, he, that they're talking about in this report that I saw come up in both of the reports that you, uh, you folks have took on is like kind of the makeup of a product team. Like what you might, you have to, you know, somebody from dev, somebody from line of business, you know, somebody from security. Um, and again, the, the C word collaboration in this case, uh, comes up a lot, uh, in all three reports, I believe so. And in literally every discussion you have with anyone who's thinking about, uh, I mean, realistically, I think anyone who's working in the, let's call it the cloud native world broadly is, I mean, I had a guy Pajarni, um, the co-founder of sneak, uh, on, on my podcast a while ago. And we talked about it like on the security front and it was just a matter of things are changing so fast. And then open to between open source and cloud services and, and the, the, you know, the ephemeral nature of containers and all these things like all security processes need to be, he was like, the security processes need to be readjusted. It's security can't be a

hindrance anymore. It has to be like you, you security teams and developers or whatever. They need to work together and to figure this stuff out because this is, this is the world you're living in now. There's not, there's not a choice really, if you want to do this right to sit in, these silos and everyone is playing gatekeeper to everyone else. There really needs to be fluidity is, is kind of the, the key. Yep. Well, yeah. And I mean, I think of security, not being the gatekeeper, this is reminding me, Rita, of that conversation we were having with, with Fint and Ryan, also of Gartner and, you know, asking him about during the pandemic, how he's, he's seen sort of, you know, a bifurcation of what's happening with people's digital transformation efforts. You know, some folks who've just kind of had pet projects and centers of excellence, but not really anything that's, that's meaningful change. Those are all getting shut down. And then folks who have been making progress are actually accelerating because now they're able to see how, Oh, we pull in this, this thing that was maybe going to take six months and we try to get it done in the next, you know, six weeks. Yeah. We're going to realize those benefits faster and we need that now. And so, you know, when we pressed him on like, okay, well, that's, that's interesting. That makes sense. Tell us more about the people who've been doing the right things. And the first thing he said was the people who have been, have made progress are the ones that engaged security teams early and often, and, and worked with them to guys point that, that you were, you know, recapping Derek is that, you know, they can't be a blocker. Security can't be a blocker. You need to engage security early and often, and then you really pave the way for being able to make more change. And that's where that's, those are the folks that are doubling down and, uh, and reaping some benefits. Um, if you can, if you can say that at all in these times, just to, to kind of jump off that product thinking, um, also showed up in the report that I was looking at, uh, which is

application motivation should be business centric, continuous, and multi-platform. And this one is from, I'm going to probably butcher these names, but, um, written by Thomas Klenect and Stefan van der Zeiden. Uh, I believe that is correct. Yeah. Yeah. The Gartner titles, they really know how to pack a mouthful, uh, into those, into those titles. But, um, it's like, I think they really figured out that like most people like don't really read past the title or past the first page bullet. So they've structured their reports in this way where it's like, if you just read the title, you kind of actually have 80% of the point of the entire report. Like they're really just telling you like, this is how you should do it. Um, and if you're willing to actually read the next page, you'll get a little bit more detail and to read the whole report, then you're like now an expert. They're like newspaper editors without the space constraint. Right. They got a little, and they can put in some of their, their graphics and, you know, this one like also touched on that, that kind of, that product mindset, um, and, and the team structure, because one of the things when you, when you tease out the, you know, it should be continuous. They, they, they sort of advocate for the creation of a modernization team. And I think this really lies in the face of a lot of convention, which is that app modernization. Um, and this is in the report as well, where they talk about how past approaches to modernization have really failed in so many ways for a couple of reasons. One is they get treated as a project. Um, and so if, if they haven't properly scoped the project, then, you know, they get into it and then they don't, they don't get the outcomes that they're looking for. Um, they also talk about them failing because

what I call the boil the ocean effects, where they're trying to take almost like a, an infrastructure or platform up approach to modernization, where it's like, we're going to sweep across and we're going to do everything that's running on this particular platform, right? Like, you know, this particular, uh, web server, all of those are going to get updated and it's a boil the ocean approach. And, you know, they're almost inevitably going to run out of money and resources, but they haven't then shown any value to the business. Everyone's just like, okay, great. You swapped out some stuff and, you know, you made, you know, you took away time from delivering new features. No one's really happy with it. So then that gets to the last point, which is that the modernization really needs to be driven around what is the business outcome? What is the capability that you're trying to add that some kind of tech debt is in the way of being able to deliver? And then you focus your whole modernization effort. Instead of looking broadly, you're focusing it on, ah, okay. In order to be able, like, here's a classic example is, you know, we want to be able to do some cool machine learning, blah, blah, blah, on some of the data from this application. And it's like, well, great. Then you kind of need to really rethink how the data from this application is going to be able to flow through a machine learning image, uh, uh, sorry, machine learning, um, uh, you know, algorithm. And that is going to require probably modernizing and teasing apart parts of this application, particularly if it's a big monolithic application. You know, supporting a lot of other functions. So classic example of, all right, we know, we now have a North star, which is we want to get to the point where we can add in, uh, you know, uh, being able to call out to some machine learning API, you know, that some cloud provider has, or adding some virtual agent, right? So there's a chat bot or something, right? Something that the

business actually wants. And then you just map out everything that you need to modernize in order to get to that point. And you don't modernize any more than that. So I thought that that was a really interesting, um, you know, sort of approach and, and thinking. Um, but the other thing that, that idea of like, Hey, don't treat it like a project. To me, anytime you kind of like, you folks are calling out the project approach to me, the other side of that coin is having a product approach. So there's actually a great diagram in the report, uh, that, that sort of illustrates three layers of, uh, let me see if it's, yeah, sort of three layers of, of how teams are organized, um, across modernization platforms and product, the actual software development. And, and so to me that, you know, they're, they're kind of, it looks like this is maybe some graphic that was developed that supports a lot of different research. Cause there's a big, big red circle around the modernization team. And it, it resonated with me immediately. Cause I think I was fresh off of learning about how this, this European banking customer that, that we'd been working with had wanted to do some really large scale modernization and they, they needed some help, but they, they, they embraced this notion of we're going to need a team that's doing this and basically going from product team to product team, helping them do whatever refactoring was necessary. And they were really the in-house experts on modernization, uh, cause that expertise can then be brought again and again and again. And that helps you do this continuously, right? If you want something to get done, you make it someone's job. But what was interesting was under the cover, they, to get this sort of team off the ground, they were bringing in, um, uh, Tonsu, uh, or sorry, VMware Pivotal Labs and

the, the sort of the app modernization specialists there. They knew they needed to scale it over time. So they were also bringing in, uh, Cognizant. Uh, so, you know, a large SI partner, but there were also people who were from, you know, a staff staffers from the bank who were on this team. And one thing that they, they learned to your point about kind of pride and identity Rita was that they, they had to give this modernization team, uh, its own little brand, um, and, and name so that every time they went in and engaged with a new, uh, a new, you know, software team that was building a different app that they were like, okay, we're going to help you do some modernization. There wasn't kind of confusion about like, well, what do they say? And what do they say? And who are the people who work here? It's like, Nope, we're a team. We've got a team. You're engaging the blah, blah, blah team. And once they did that, they were able to actually move a lot faster and help a lot more teams. But the, the meta sort of observation was they embraced this continuous approach and they made it someone's job and they, you know, they were able to supplement. If you're, you're starting that practice, know that there is a way to, you know, you don't have to form this team and hire all those people from day one, you can form that team and you can bring in, you know, uh, uh, help from, from consultants and whatnot to kind of help get it off the ground and over time evolve it. Uh, but anyway, it's, uh, I, I love this report. I think it's a great one. I referred to it, uh, in a couple places in the app modernization 101 guide that is on intersect. Um, and, uh, I think it's, I think it's a must read for, for anyone who's looking at modernization efforts. Um, so highly recommended. You know, one of the things that stuck about that stuck out for me in that report as well is, um, thinking about modernizing business capabilities as opposed to apps. So starting, they really espoused

this, uh, outside in thinking, right. And once you take on this outside in thinking and business value thinking, then this, this concept of, of, uh, uh, business capabilities or modernizing business capabilities makes more sense. And then they talk about managing, managing those business capabilities, right. As products and services and, um, you know, for their whole full, their, their, their full life cycle. So, yeah. And I, I will acknowledge that around the same time, cause this, this report or, or this update of the report, um, was published on the 15th of August in 2019. And I think it's even in the same month, uh, Gart or Forrester also came out with a report about modernization. I think it was like modernized core apps for the cloud. Um, I think that's one of the, the Bartoletti and John, John Reimer, uh, collaborations. So I was reading both of these right around the same time. And what's interesting is, you know, that they've got a different case for modernization in the Forrester report. And in, in some ways, at first glance, you might say that there's like these, these two pieces of guidance are, are in conflict because, uh, Gartner is strongly advocating for like, you need to have that business outcome, that business capability in mind. And then you touch whatever apps are, are needed in order to deliver that capability. And in the Forrester report, they also kind of look at things and say, you know, some quick wins and benefits to be gained from steps like containerization. And so I think that sort of speaks to maybe more of the, the, the operational, the I and O side of things where you're probably going to get some I and O benefits from those types of, you know, Hey, let's just try to containerize more of our applications. They're quick wins, but I think there's, I don't think that that approach is not valid. I just think

that it's interesting to put them side by side and recognize like, these are two different approaches that are going to yield some, you know, depending on where you focus is where you're going to get your, your outcome. So depending on who's, who's driving the bus, who's really, um, calling the shots of like, this is what we want to get out of it. Are we trying to get some operational benefits? Great. We can get some quick wins over here. Um, are we, but we have to try to keep that in mind that like, don't, don't boil the ocean, right? Like, cause you'll, you'll just get bogged down. If it's really like, can we get some business capability out of it, then you're probably going to take a different tack. Yeah. I think, I mean, there are people who would argue that, you know, containerization, let's say is a, which by the way, is a great segue to the, uh, report that I'm talking about, but there, I think there are people that would argue that containerization is maybe step one, or, you know, some early step in any modernization effort, if you're going to modernize technology along with processes more broadly, but right. I mean, it is, if that's all you do, that's, it's, it's, it's, it's not going to be the end of, it's not going to modernize a whole lot in the end. Like you said, it's a quick win. You're going to get some, some efficiency benefits. Maybe there's going to be some of that, but it's, it's, it's such a baby step along the way. I think that you really need to embrace the, it seems like you really need to embrace the whole modernization. And then I get up to the business level, because again, like it seems like so much of what ends up, what ends up filtering down to the application level and to the IT, some of the IT processes is, you know, the, the organization's culture overall. So, I mean, a very process driven, like, you know, heavily regulated, um, you know, whatever industry, like, I mean, I think when that starts boiling down into the application level, then, you know, all the containerization in the world isn't going to change the fact that you can still have very slow processes and very, um, you know, honestly kind of, you know, maybe just unhappy people at the end of the day. So.

Yeah. It's, it's, it's interesting to think. And like, it depends, I think that comes back to that collaboration point, which is if your, your IO teams and your, your line of business folks, if they're collaborating well, I think there's a higher likelihood that that modernization can really focus on those business outcomes. If I know is really, really, truly working in a silo, then they can get some of those quick, quick wins. They can, they can, you know, do things like containerization. But, um, it's really also, to me, seems like that's probably symptomatic that they're, they're heavily siloed from their business counterparts because if they're spending their efforts on that, they're not really focused on the business outcomes. Yeah. I always go back to the early days of cloud computing where, you know, the real benefit of Amazon web services, when it, when it launched, I mean, God, decade and a half ago now was, you know, one of the big pictures was you don't need to wait to provision a server anymore. Right. So, so, so that was, that was the big hole. That was a big holdup. And that was what, you know, how people viewed, I think the I and O teams a lot. And, and, and so now if containerization is only solving a slightly more modern version of that problem, it just seems like it's, you know, that's not going to be, I know you said that that's, that's not a business, um, changing the shift probably. Yeah. I mean, to that, to Dormain's last comment, I mean, again, Charlie talks about, uh, siloed efficiency metrics, right? How that those are not useful and talks about rather talks about, uh, metrics that are aligned to, or KPIs aligned to business objectives. And that's how, you know, I know it can show its value. Oh, Rita, you just, you know, my trigger buttons when you bring up metrics. All right. Well, on that note, uh, there, you're saying that this, this, this tees up a segue to, uh, the report that you dug into. Yes. And another, uh, really inspiring headline on this

one is the best practices to enable continuous delivery with containers and DevOps. Although it hit a lot of buzzwords, so that's good. Um, but yeah, best practice, best practices is one of those buzzwords. Who doesn't want like some best practices? Oh, for sure. You know, but, but yeah, the thing that stuck out, and then I think the big thing that stuck out to me was, is that, I mean, it's kind of less about continuous delivery as in like how to set up your CICD pipelines and more about, and more about just this process of, again, it's a lot of collaboration. And the thing that really stuck out to me was viewing containers as, as not like developers pushing new technology and I know, but rather as a type of technology that can help facilitate collaboration that can help both sides meet their, meet their own goals and also shared objectives. So, I mean, and it was really this idea of like, you know, I know containers will help, I know if they have some sort of established maturity around automation, they're going to help them take, it's going to help containers can help them take that to the next level. I mean, it's going to help, you know, as everyone gets comfortable working with this new, because the other thing they say is by 2023, you know, their prediction is that 70% of apps deployed in the cloud will use containers as a packaging mechanism. So if that's accurate, I don't know if that's existing apps or new apps or whatever the, you know, what apps we're talking about, but that's a significant number. And right. So you need to start thinking about this as it's just, I think the whole thing is you need to start thinking about containers, not as, not as a replacement for VM, not as this thing that developers like to work in that that's insecure or whatever. And more as this, more as a, frankly, a technology that is going to enable you to do some of these bigger picture things that you want to do once everyone gets on board and their processes in place. And then the report goes on to layout, you know, how would you lay, how would you build a product team? How would you build a platform? How would you build a DevOps team? How do you build a platform ops team? And, well, you know, depending on the maturity of the

organization, you might have two teams, you might have dev and platform ops, you might have dev and DevOps and platform ops, it really all depends. And they might have slightly different roles. And then I know is kind of hanging out still maybe managing infrastructure and networking and kind of the underlying stuff that, that all this, that your Kubernetes and all your container orchestration, all your containerized components are running on top of. But yeah, it was, you know, again, it was just this idea of like, think of taking a technology and how do you utilize that technology as, as something that's going to help build and help you reach bigger goals. So again, containers, great step one. And, you know, they can be very useful for doing, and I think for a VMware audience too, like, frankly, you know, the idea that, that people like to think about containers as, as a, as a, as a replacement for a virtual machine, right, it's just not probably the right way, the right way to think about it at all. And if people are still viewing in that way, it's, that needs to be shaken out of their head. Yeah. I mean, I think that's a great point of like, use this as an opportunity to re-evaluate your team structure and those processes, right? The whole, like the, the holy trinity of people, process and tech, like containers are a technology, but, you know, when not paired with process changes or team structure changes, like you're really just kind of doing the same thing, but with a slightly different format. I mean, the key, the key, the, it seems like the crux of this, of the, the, the, the nugget of this is that it's all about continuous, continuous delivery, right? As the holy grail, if you will. And then how do DevOps and containers enable that holy grail? Yeah, but I think it's more continuous. Yeah, I mean, continue, but it's, it's, I mean, I write it kind of more as it's being about continuous everything in the sense that. Continuous modernization, right? Like, modernization is to be continuous.

In the sense that like, you know, security, right? I mean, one, you know, containers have pros and cons in security level, right? But one of them, you know, one of the things that they require, if you're going to do it right, is continuously upgrading the components of the application components, continuously upgrading the host OS, continuously, you get the, the automation and the upgrades and everything has to be coming and your components are going to be updating. You know, if you're using, if you're using a container, that's real. Like if you're building an application that's running across multiple containers using however many open source projects, right? I mean, there's so much change happening at all those levels that if you're not plugged in and haven't figured out a way to automate the upgrades and patches and all this, like you, you, you fall behind real quickly. I think that's part of it. I was waiting for you to say automation. I feel like we've come full circle, right? Like here we are talking about automation and collaboration again. Yeah, this is, this is probably a great place to tie it off. We've come full circle. As you said, that's, that's when you tie the bow, uh, you know, we'll put the links to each of these three reports. Um, you know, I'm a classroom learner, so I like listening to people gab about stuff and present things. Um, but every now and then you gotta, you gotta hit the books and actually read it. So we'll include the links, um, as well as links to some of the other, uh, episodes and, uh, and talks that we referred to that, that kind of came to mind as we were all, all reading these. So anyway, thanks, uh, Rita and Derek for joining and sharing your, your insights in this kind of, uh, almost like book report style. Thanks. That was really fun. Thanks for having me. Yeah. All right. Thank you.

Thank you.

Tanzu Talk · 🍕 Get more pizza.