Search
Follow me:
Listen on:

Day Two Cloud 093: Application Modernization With VMware (Sponsored)

Today’s Day Two Cloud tackles application modernization with sponsor VMware. As new application platforms such as containers and the public cloud take hold, organizations need to examine their application portfolio to figure out how  applications are meeting business requirements—and how they aren’t.

The point of app modernization is to determine whether a new approach and new technologies will better align your applications with your business goals. For example, would greater agility in a critical business app help the business respond faster to new demands? Would an application be better served by elastic resource consumption or improved resiliency?

On today’s show we discuss how to understand whether and when an app could do with a rethink, how to weigh the pros and cons of different approaches (containers, VMs, serverless, on-prem, cloud-native, etc.,), and why consistency should be a key element of your strategy. We also discuss VMware products and services including Tanzu and VMware Cloud.

Our VMware guests are Kit Colbert, VP and Cloud CTO; and Dormain Drewitz, Sr. Director, Product Marketing for Modern Apps.

Show Links:

Office of the CTO Blog – VMware

VMware Cloud Event – Registration

VMware Tanzu

Responsible Microservices, with Nate Schutta – Tanzu Conversation (Podcast)

Bringing More Tanzu to Three Cloud TransformationsDormain Drewitz via VMware

@DormainDrewitz – Dormain Drewitz on Twitter

@kitcolbert – Kit Colbert on Twitter

Transcript:

 

[00:00:05.880] – Ethan
Welcome to Day Two Cloud. Ned, we have a show on app modernization or modern apps or I guess kind of both of them with our sponsor today, VMware.

[00:00:16.620] – Ned
Right. And this is a really interesting conversation. It’s not just about VMware. It’s really about this larger app modernization landscape that we find ourselves in. And the point that I took home from everything was consistency is key at multiple layers if you’re going to responsibly manage this app real estate that you have. So let’s get right into the conversation.

[00:00:38.970] – Ethan
Enjoy this conversation with Kit Colbert, VP and cloud CTO at VMware, as well as Dormain Drewitz, senior director of Product Marketing for Modern Apps.

[00:00:49.210] – Ethan
Well, welcome, both of you to the show and what we want to discuss today is modern apps. Modern application modernization is really the big idea, which is kind of a buzz word. So Dormain I want to start with you to set context for this conversation. We need to define what a modern app really is here. We’re talking about moving to cloud. OK, so is a modern app one thing, many possible things. What do we mean by this?

[00:01:15.370] – Dormain
Yeah, I think it’s a good question. And it’s interesting how you kind of talk about, well, there’s modern apps, there’s app modernization. And I actually prefer to talk about app modernization because that’s a spectrum that can hit so many different applications. And it’s kind of the journey that we’re always on. But the the how that journey plays out keeps evolving and changing as technologies evolve. And so what app modernization would have looked like 10, 15 years ago is now going to be different.

[00:01:49.600] But and you could say the same thing about like, what’s a modern app? Right. Like what’s modern art. Right. So, you know, there’s some some definitions around, say, a cloud native application. And they’re kind of looking at a spectrum from kind of cloud readiness to cloud friendliness and all the way up to a cloud native application where you’re you’re highly resilient to failures. You’re really designed for those types of scenarios where you’re going to be hitting consumers scale and you have a high degree of isolation between components.

[00:02:23.900] But the reality is like that’s not necessarily needed for everything. But some point along that modernization spectrum might still be useful. And so navigating that app modernization spectrum is probably a more useful conversation than getting really wrapped around the axle, on like what is this, a modern app? It’s like, well, it’s still uses a relational database and it’s relying on hard consistency. It’s like, well, I mean, does it work? Does it solve your business needs right now? Can you change it? Then, you’re kind of arguing the wrong point.

[00:03:04.370] – Kit
So I think, first of all, I totally agree. It’s it’s hard to pin down. And there are a lot of different definitions, like you can look at it from an application architecture standpoint as Dormain mentioned. You can look at it from an application packaging standpoint. Is it using VMs versus containers? How is it using those things you can use? You can look at it from a delivery standpoint.

[00:03:25.130] Have you adopted a CI/CD process? What sort of automation do you have there? And there’s a variety of other aspects that come into it, and there’s different definitions, like 12 factor, are you doing all 12 factors? And if you’re not, if you only got 11 factors, are you still modern? Yeah, it doesn’t really I don’t think it’s very useful to wrap yourself up in too much of that. And then there’s things kind of outside that like an ML application. Is that a modern app. Well, I think so. It’s certainly a pretty newish, ML is still fairly novel.

[00:04:00.470] So it’s a pretty wide umbrella and like Dormain said that I think focusing on the modernization part of it, like taking looking at your application, estate or portfolio and figuring out how those applications serving you and where are they not and where the problems, especially with regards to your business priorities. And then how do you modify those apps so that they can better solve those business problems?

[00:04:25.220] You know, it’s you see all sorts of new technologies coming out. Whether it’s containers a few years ago or now Serverless more recently, and I occasionaly talk to customers, and they’ll say, hey, we want to move everything over to containers. I talked to a number of customers a few years ago saying we’re doing this and I’m OK. But like, why? What’s the business priority? To move everything into containers? Sure. If you got the time and you got nothing else to do.

[00:04:51.560] But I feel like you probably have some other important things to do. And so it’s really about aligning your business goals with the right technologies and figuring out how those technologies support those business goals.

[00:05:02.960] – Ned
I was going to ask you what what is the ultimate goal of app modernization, the way you think of it? I think you put a pretty fine point on it that it needs to advance some sort of business goal or or do something good for the business. Dormain is that how you think of it as well?

[00:05:18.640] – Dormain
Yeah, I mean, there’s kind of a litmus test that seems to come up a lot in some of the engagements that we we do with customers, that’s around kind of around the velocity that you need.

[00:05:32.230] And so I often use this sort of how fast does this application need to change? What’s that? That change rate required? And so where you have applications that are in the critical path for revenue, for example, those are often ones that you’re going to want a high degree of agility around. And so whether that’s anything kind of a backing service for, you know, an e-commerce site. And we think of e-commerce as retail, but increasingly, like a lot of different industries, have to be able to provide some level of transact ability at that they’re trying to do digitally.

[00:06:12.880] And so whether they’re they’re just trying to, for example, get insurance quotes out to customers digitally so that they don’t have to get on the phone with an insurance rep or, you know, logistics, wanting to be able to pipe in a headless service that an online retail partner can use in order to make sure that that’s going to service a shipping transaction that’s going to be used by their logistics company. So, you know, just that say that caveat of e-commerce is more than just a retail problem.

[00:06:42.890] But those are often ones that you want to be able to iterate really fast to respond to changing customer requirements, business requirements. And I remember working with Dick’s Sporting Goods and they were telling me about how their marketing department like was going to get the Yeezy shoes. And I was like, what’s a Yeezy? Like?

[00:07:05.530] They were laughing at me. They’re like, you don’t you don’t know, you know, Kanye’s shoe thing. And I’m like, I am so out of the loop. But they, they were able to like Yao and but it was a really tight window there, like the marketing departments out there trying to cut this deal for a limited edition type of, you know, piece of merchandise from a third party. But that means that they’re going to have to make sure that the website can scale because all of these kind of sneaker heads are going to be hitting their site overnight.

[00:07:34.450] They were able to do that, right, because they had modernized in order to be able to support changes and ultimately the scalability and resiliency that was going to be needed for that. But then, you know, a counterexample that a friend of mine used to use was he worked at NASA and they had a specialized applications for just for printing the the badges when you would come into any of the buildings. And, you know, it’s a very secure facility.

[00:08:00.910] So they had a lot of important kind of custom things. There was a custom application, but it prints the name tags. Right. It’s if it’s working, it’s probably fine. Like, that’s probably pretty low on the priority of like does that need to be 12 factor? I don’t think so.

[00:08:19.210] – Ethan
There’s a point here that we don’t have to have some some litmus test. The term you used earlier, where app modernization means if it’s a modern app, it’s cloud native or, you know, some hard and fast definition. Instead, what we’re saying is, does it do what you need to do in the digital age? Or if we want to say digital transformation, if you’ve been successfully transformed as far as you need however the app is delivered. It is. You would consider it modern.

[00:08:45.160] – Kit
Yeah, well not, however, but it’s about solving the business. It’s not about getting to a modern app. Maybe that’s the way of saying it.

[00:08:53.140] – Dormain
But it’s like having that in your repertoire to be able to support a modern app, if you want to call it that, that’s that’s going to be useful. And and so you’re going to have things that are going to be running alongside each other, that some things are going to need to go really fast.

[00:09:09.850] And you’re going to probably want to get the scalpel out and do the surgery on that that bit of code. But you’re going to have other stuff that doesn’t need to be changed that fast. But increasingly, with the volume of vulnerabilities that are getting uncovered every week, you increasingly need to be able to solve for a certain level of velocity, probably just to keep things patched and secured. And I think of that as. Security hygiene, more than any kind of really sophisticated advanced threat management, it’s just basic hygiene, right?

[00:09:49.560] – Ethan
So the velocity, as in keep the app up and running and available, but be able to update, patch this thing so that it’s secure.

[00:09:57.750] – Dormain
Mm hmm. And that’s where, you know, like containerizing the app and having a CICD pipeline in place, even if this isn’t a, you know, a bit of code that’s in the critical path for revenue, but it’s somewhere deeper in the system, kind of a backing backing service somewhere. You still need to keep that secure. Right, because that’s that’s where threats can sometimes come in is it’s not the crown jewels that everyone has put into Fort Knox. It’s that kind of like server over in the corner that no one’s paying attention to that gets compromised.

[00:10:34.950] And then a clever hacker is going to find their way through like a credential here and a credential there. And they’re going to worm their way across until they do get into the crown jewels. And so having a little bit of a mindset of, OK, where where do we have how can we raise the waterline of keeping our overall footprint here patched and available, even if it doesn’t have to change tremendously? Well, maybe we don’t have to rearchitect it, but can we restart it without disruption?

[00:11:12.630] That kind of that one I like. That’s the part where. Yeah, the one factor of can we restart this thing? Like, you know, you realize like there are always those applications that…

[00:11:24.690] – Ethan
I’m laughing, having been a former government employee, small state government, and you talk about the server in the corner, it’s like, what does that server in the corner? Don’t touch it. Wait a minute. Why are there so many why are there so many corners and why is there a server in every corner? What’s going on around here?

[00:11:41.040] – Dormain
Well, I mean, the Pentagon does have five corners. So they’ve got an extra corner.

[00:11:46.140] – Ned
Valid point. But I’m thinking about that that card reader or the name badge maker app that you referred to before and how it’s it’s not the critical path, but it is a security risk. And if you don’t modernize it in the sense that you keep it up to date with a language people know and it’s up to date with the security patches, then you could be in real trouble. If someone manages to hack into that system, make themself a name badge, and suddenly they got access to all these other areas.

[00:12:15.000] – Dormain
Totally. Totally.

[00:12:15.660] – Ned
Is there a concern that even if it’s not one of these shiny revenue generating apps, you still can’t just let it slip into obscurity and have no one who understands the code base or the security implications?

[00:12:30.010] – Dormain
I mean, I think like we hear these examples of where that becomes very painfully obvious when a particularly a government entity is they can’t actually change how they’re rolling out paychecks to people because they don’t have anybody who can change that code because the language is so obscure. You know, those those kinds of headlines, you know, I think bring a lot of attention to the fact that, yeah, it is. There is a certain amount of you can’t totally like, oh, if it ain’t broke, don’t touch it.

[00:13:04.290] But you have to put things into like what level of are we talking about refactoring or are we talking about containerizing this and just getting it on a CD pipeline. Are we talking about just being able to have enough resiliency in our underlying infrastructure so that we can quickly stand up another copy and redirect to an updated version and minimize disruption that way.

[00:13:29.250] – Kit
Yeah, I mean I think for some of those apps you can definitely take kind of an infrastructure approach and whether it’s just enhancing the networking and security or that sort of thing and avoid even having to modify potentially the app. But going back to what Dormain was saying, and this is where the definition gets a little murky, is like you do want to move toward kind of DevSecOps type process for most of your applications, even if you’re not going through fundamental architecture changes because of all the issues you just laid out.

[00:13:57.540] And this becoming a bigger and bigger challenge to understand what is the provenance of the code that’s running in my environment, whether a data center or a public cloud or what have. You know, where that code comes from. And a lot lot of times it’s like random open source stuff people got. They got the download a binary from the Internet and who knows what happened with that thing or who put what in there. So that becomes a real security threat and a bigger and bigger one over time.

[00:14:21.780] And so you say, OK, well, I might have a traditional air quotes here app. Using this very modern delivery process, so is that a modern app or is it not? Well, it’s kind of hard to say.

[00:14:34.990] – Ned
Right, and sometimes that code is just the top result from stack overflow. Let’s be let’s be honest here.

[00:14:40.430] – Kit
Yeah, that’s all that’s that’s yeah, that’s the worry. And by the way, one final thing I’ll say real quick. There was this interesting blog from Martin Fowler back in twenty fifteen, I think a long time ago saying, like, start with monoliths. So even for like modern applications, you know what we’d all consider modern apps on this micro services and fully 12 factor. Oftentimes it’s better to start something super simple, just a traditional monolithic architecture. And over time, as the business needs change and grow and evolve, then you move to do more that micro services architecture.

[00:15:14.020] And the reason being that monoliths are very simple. They’re easy to reason about, easy to debug. But then to Dormain’s point, if you have a situation where, man, I need to like, push out of change tomorrow, well, somtimes its hard to do that with monolith, it doesn’t work as well. So then you might say, OK, I need to go through and refactor, or maybe you had a greater level of scale.

[00:15:32.320] And a monolith, you can’t stamp out a number of horizontal copies and it won’t linearally scale. OK, so I’ve got to refactor there. So there will be there’s certain inflection points where that sort of rearchitecture is warranted by the business case. But the idea is like, OK, what can we do to start simple and then move forward based on business needs?

[00:15:50.350] – Ned
Right.

[00:15:50.980] – Ethan
Well Kit, you just opened up the door to ask about VMware Cloud and how we should think of it now in the VMware product portfolio. We’ve talked about VMC on the on this show a few different times. So, folks, if you’re not familiar with it, dig back into the Day Two Cloud catalog. We talked about it at some length. So position it for us now Kit, in the context of this conversation.

[00:16:09.070] – Kit
Yeah. So first of all, we have somewhat expanded what we call VMware Cloud recently. I think typically speaking with, say, VMware Cloud, we meant VMware cloud on AWS, kind of like an infrastructure offering from us and with a kind of event we did recently. It was really about unveiling a much broader vision around what VMware cloud can be, and that is bringing together our infrastructure and application services and security and management a whole bunch other things together to be a real modern application multi-cloud platform.

[00:16:46.120] It even being I can support your apps running in the public cloud on Prem at the Edge and the data center. And support both traditional and modern applications together. And so there’s a bunch of work that we’ve done to bring together a lot of the products and services people are familiar with, things like Tanzu, things like vRealize, things like our infrastructure offerings all into a more unified whole. So that’s a very, very broad VMware cloud bucket here. Our new offering.

[00:17:15.850] And the goal there is really around application modernization, well modernization in general, both of the infrastructure and of the application. So I think it lands really well here because it talks a lot about and focuses a lot on the things we were just talking about.

[00:17:30.890] – Ned
I think one of the concerns that some people might have when they’re looking at their at the app real estate, because when I think of a large enterprise, it’s not just like 10 or 15 apps.

[00:17:42.380] They have hundreds or thousands of apps that they’re responsible for across multiple BUs right? And how do you even start deciding which apps you should pay attention to? Which ones would be good candidates for modernization? Which ones you should move up to the cloud or out to the edge? Is there anything within the VMware cloud suite that sort of helps with that assessment portion of things before you even start making a move on changing an app?

[00:18:10.260] – Dormain
It’s a good question because I think that that problem has existed for a long time and folks have often ended up with those assessments, like taking on a life of their own. And, you know, like it’s like, well, this is an 18 month assessment. I mean, well, how much has changed since when we started this assessment? Until now. Now we’re done. And so the need for kind of knowing enough to get started has become really critical.

[00:18:41.520] So this is actually a services engagement that VMware does called the App Navigator, because this is kind of this is hard to do completely like with just say let’s just throw some software at the problem. It requires having some expertise, you know, like actual human expertise who can help you parse through what are we looking at here? And so this kind of app navigator engagement is another part of what we we launched the other week. And it’s a four week engagement.

[00:19:17.430] And so enough time to be able to do that real estate wide assessment, but not so much time that like the the the whole ball has moved by the time you get to the end of it. And they use that kind of, you know, weekly agile sprints that the Tanzu Labs team has has really kind of mastered that that approach to the way that they work on software, including modernization projects. But they actually apply that now to these navigator kind of assessments.

[00:19:51.840] – Ethan
App Navigator, that is it’s a service Dormain, not a software product.

[00:19:55.870] – Dormain
That’s right. That’s right.

[00:19:57.720] – Ned
That that makes a lot of sense to me, because in a previous life, I did a lot of consulting and we would be working alongside these big firms. And the first thing they would do when they came in is like, we’re going to do an assessment and it’s going to take six months to a year and then we’re going to start doing work. And yes, as soon as another firm would come in and say, we’re going to do an assessment, I saw everybody at the company start rolling their eyes because they’re like, well, looks like we’re not getting anything done for another six months. So it’s great to hear that this hits the ground running, it sounds like, as opposed to taking six months just to assess things.

[00:20:31.920] – Dormain
Right. It’s like you can’t like come in like guns blazing and just start blowing stuff up either. Like you do need you do need four weeks to kind of, to be able to actually know what you’re doing. And so it’s kind of that minimum viable assessment, I guess is another way to think of it.

[00:20:50.400] – Ned
And I’m glad to hear it’s not all automation either, because I’ve also seen that side of things where the sell is. We have this product that you just install some agents. It’s going to collect all this data and it’s going to tell you exactly where to move every application. And just as someone who’s been a sysadmin, I’m like that. There’s no way that works. Like you give me like a general guidance, but you need a human being that’s actually going to help you out with that is that you can use both in the app navigator?

[00:21:17.790] – Dormain
Yeah. I mean, most folks that, yeah, do do any kind of assessment, like there’s often some kind of code analysis tool. And so there are code analysis tools and actually there’s a lot of them that can get pulled in in order to do that assessment in a short amount of time. And I think folks are often, yeah, they’re looking for that easy button wherever possible. And when it comes to modernization, it’s you know, you just have to be careful. But the you know, speaking with the Tanzu Labs teams, it’s done a lot of modernization work.

[00:21:55.980] The way they put it is like when you go into an organization you’ll often find that there’s probably maybe like ten patterns. Right. That are the most common patterns. And once you kind of understand what those are in an organization, then you can start to automate and stamp out a lot of improvements. So you develop kind of a cookbook that can be followed for that particular type of application that exists in an organization. And that then becomes where you get a lot of acceleration and repeatability, but sort of first identifying what are the the sort of the tribes inside this this particular organization, what types of patterns.

[00:22:38.670] And they they can be unique to that organization because of just, you know, the human side of history of like, well, we had a policy for a while that we always did it this way. You notice like a bunch of applications from that time that follow certain patterns. And some of them end up evolving and some of them end up kind of sticking with that pattern. So once you kind of it’s almost like a demographic study of what’s going on. But then when you find these patterns, you can you can start to do some level of automation.

[00:23:09.870] – Ned
I think that’s called Conway’s law, that the structure of your organization is going to define how your software is written and, I think that also harkens back to the monolith thing, where when you are a small company, you can end, with a small organization, you can do monoliths because that’s the way you’re organized. But then as you break out, you need to start breaking apart that monolith, too.

[00:23:29.650] – Dormain
Yeah, I mean, and to Kit’s point earlier, like a well-formed monolith that doesn’t have those requirements of it needs to be able to scale independently where one function within that monolith is is going to get a lot more action than other parts. And that might be fine. And that doesn’t even in a big organization, a good, well formed monolith that’s doing its job and doesn’t have those requirements. Keep it that way. Right. There’s no need. But but figure out how do you keep it healthy and then.

[00:24:00.370] Yes, where you’re running into those constraints, where we have a slice of functionality that we we need to be able to change much more often. Great. Then you can carve off just that piece. You don’t have to break everything up. And, you know, I’m thinking about some of an engagement we did with Travelers Insurance. And there they were actually trying to modernize off of mainframe. And this is like a lot of people think, OK, when you’re modernizing mainframe, it’s like there’s no more mainframe at the end of the story.

[00:24:30.430] But that’s not necessarily true, right? Like, as we all know, the mainframe never dies and they’re still here. But they were able to slice off the functionality that they did need to move faster, modernize it into .Net core. And then what was what was great talking through the the team there was you know, they they first kind of broke it down too small and they were running into a lot of chattiness between the components and incurring like a performance overhead.

[00:25:00.300] And that’s always the thing. Like one of the great things about Mainframe is, hey, it meets a performance requirement. That’s that’s often why they are there persisting. And so they actually sort of swung back and they started to combine back up some of the services to sort of find the right amount. I sort of talk about this is like the Goldilocks level of sort of isolation. And so you don’t want to get too small, right. Sometimes that you’re incurring more complexity and a performance hit.

[00:25:31.000] So you have to kind of find like that that Goldilocks balance of, OK, now we now we’ve identified the pieces that these these parts need to stay together because they change together and they scale together and they’re talking to each other in order to to complete their processing. But these pieces over here, they can they can be separate and we’re going to get benefits by having them isolated like that.

[00:25:55.120] – Ned
I like that, the Goldilocks zone. That’s just right.

[00:25:59.410] – Dormain
Just right.

[00:26:00.760] – Ethan
It’s almost like there’s not one right way to do it. And I think that is the trap a lot of we engineers fall into. We want the one right way to to deliver our app, to deliver our networks, to deliver a security paradigm, whatever it is and there isn’t. You have to take every case, every business individually and find the correct answer with its associated tradeoffs for that particular situation.

[00:26:23.860] – Dormain
Yeah, absolutely.

[00:26:25.300] – Ned
I think as engineers, we also sort of have this progression in our mind of we were on mainframes and then we moved to Wintel and that was awesome. And then we moved to VMware and that was awesome. And now the natural next thing is, is Kubernetes and container’s that’s that’s just the natural progression of things. But then you’re pointing out, if you look at the actual reality, nothing ever dies or goes away. All of those older platforms still exist. So it sounds like my app is going to potentially move through the to these platforms. But if I just stay on one of them, is that is that the right way to look at it?

[00:27:02.120] – Kit
There are components, components stay. I think one of the most common patterns that we see is, I don’t know, this is the term we use internally. I don’t know if it’s industry standard, but it’s kind of a greenfield on brownfield pattern where you have this existing app, usually a more traditional architecture, monolithic architecture, what have you and what you see people want to do is to start extracting various aspects of functionality from that app and then rewriting those things as micro services, having clean APIs there and so forth.

[00:27:35.390] And so what you find then is that you may have this traditional app still running in a VM, maybe even still on Prem in some cases. You have the new thing of micro services running in containers. You might have some like traditional database that it’s talking to for persistence and all that. And so you start getting this very, very heterogeneous architecture for the application. And we’re seeing this more and more, you know, again, this green field on Brownfield’s it’s one of those common patterns that we see.

[00:28:00.830] And it’s very much part and parcel of the overall application modernization process that you can’t rewrite the whole app in one day. So how do you do it? Well you take it sort of iteratively by breaking down this big problem into a set of smaller problems and iteratively go through. What that means is that you’re in a situation where for a long time, possibly the foreseeable future, where you have multiple technologies at, play multiple architectures at play that all make up one logical application.

[00:28:30.320] – Dormain
Yeah, and I think like one of the the challenges in that when you kind of accept that reality that we’re not going to able to boil the ocean and get everything to this clean, sterile place we want it to be. We’re going to have this heterogeneity. So where can you drive consistency? Because consistency is very powerful and it will help reduce a lot of that toil that comes from, you know, everything from like it worked in dev, like I don’t know why it’s not working in prod.

[00:29:02.510] And it’s like, well, your dev environment, your prod environment are like they’re either vastly different or the hardest one is where it’s like it’s zero point five percent different, you know, and that that one little difference between Dev and prod and they’re not at parity. It’s that point five percent non parity. That’s like, oh, that’s why it’s not working in the expected way. And so, you know, or just at your at the infrastructure level.

[00:29:27.860] Right. Like every time we have to stand something up, how can we drive consistency so that we’re not having to go in and manage all this infrastructure in kind of a custom Japanese craftsmanship way, like Japanese craftsmanship is awesome for Japanese crafts and like and things. But that’s probably not how you should be dealing with your IT infrastructure.

[00:29:51.780] – Kit
So I look at a few different ways, I think this aspect of consistency is super important. We think a lot about it on the infrastructure side, obviously, as Dormain just mentioned, it’s a lot of what we’re doing with integrating Kubernetes into vSphere.

[00:30:05.040] I mean, you talked about this notion of, hey, kubernetes is like a big thing. And of course it is. We’re seeing a ton of uptick there. But we want to drive consistency in terms of how you deliver that infrastructure capability to developers, to operators, how you manage that. There is consistency at the DevSecOps level as well. This notion of how are you actually delivering these bits, irrespective of what infrastructure are the things running on or what architecture the app has, there should be a consistent way that you do this and it should be auditable and you should be able to go back and figure out how to Dormain’s point.

[00:30:36.870] OK, how how does it work in your development environment? How does it work in production and build it very quickly? See the difference there and then there’s consistency in terms of the application architecture as well and what you’re looking at there and managing across those different application architectures, and how do you bring that? And so consistency at these different levels enables more things around management and automation and security and all the other compliance, all these other aspects of actually operating an application.

[00:31:05.280] – Ethan
Does that mean I mean, if I can find the consistent bits as I’m modernizing my application, do I get to move my application around? I don’t want to host it on Prem anymore. I want to move it to the cloud because reasons is that where that gets me?

[00:31:21.720] – Dormain
It certainly helps a lot.

[00:31:23.440] – Kit
Yeah. So I think there’s a few different levels of abstraction there. Right. So if you look at like the virtualization consistency. So that’s a big focus for us because we have a lot of customers who have, they are still mostly on VMS and they say, hey, I want to move these up to the cloud. And traditionally, in that model, it does mean that you are doing some amount of rework to that app. You’re changing the operational tooling, maybe even refactoring a little bit, hopefully not too much, but there is some manual work required there.

[00:31:54.160] And what we can do with VMware cloud is really give you that consistent infrastructure on both sides. You can literally vMotion that workload up to the cloud and we see customers moving things really quickly. The other little consistency that I find is then trying to use an infrastructure abstraction like Kubernetes, so you’re not dealing with core virtualization anymore, you kind of one level up on the stack, so to speak, and saying, you know what, I want to be able to run across clouds or even on prem, and I want to have a bit of freedom to to move it around.

[00:32:25.870] And so there you want to use Kubernetes, as that infrastructure abstraction and you still get core network, compute, storage and some other services like that. But now you get a lot more flexibility in terms of how you move things around. That’s a big focus for us as well, obviously, with everything we’re doing with Tanzu Kubernetes grid for the core cluster of Kubernetes clusters, as well as Tanzu mission control for management of those Kubernetes environments. And then there’s at our enterprise management level, we look at it and say, OK, so even if let’s say you’re using some AWS, you’re using some native Azure and you’ve got some stuff on Prem.

[00:33:00.490] We still want to be able to do some of your operations consistently across those quite diverse environments, with quite diverse applications. So being able to bring automation and governance, to be able to bring operations management, network insight, these sorts of things, cost management consistently. So those are the kind of three different levels of abstraction in terms of consistency that that we tend to think about.

[00:33:24.750] – Ethan
As I move stuff around does my licensing just get really confusing because I’m used to different environments, different licensing schemes and so on, so that doesn’t sound like a pleasant thing to deal with, honestly.

[00:33:34.530] – Kit
Yeah, that’s a good point. This is something that we were hearing a lot from customers that, hey, you guys have all these offers, all different solutions, some on prem, some in the cloud, like how do we really simplify consuming all of this? So that’s what spawned this idea of VMware Cloud Universal, which we also just launched recently with the broader VMware cloud I discussed earlier. And the idea with VMware Cloud Universal is really it’s kind of the one stop shop for what is today VMware cloud infrastructure, but will expand to other aspects of VMware cloud over time.

[00:34:08.420] So what I mean by that is that you can buy into VMware Cloud Universal and then be able to get access to VMware Cloud on AWS, VMware Cloud on DellEMC as well as VMware Cloud Foundation. And be able to move workloads between those and move your entitlements between those as well. And so the goal here is that we don’t really want you to start thinking about or keep thinking about VMware Cloud as a bunch of individual products, it’s an overall solution.

[00:34:37.250] You should be able to buy into that overall solution then have a lot of flexibility in terms of which of the specific components of that solution that you choose to use. And as we mentioned, that might change based on your your business priorities.

[00:34:50.360] – Dormain
I think this is this is so important because it kind of comes back to that, like first we’re going to do the assessment and it’s going to take six months. Right. You run into the same thing with we have to build our cloud plan and we we don’t know exactly what’s going to move, how fast, when and if we have to try to thread the needle on a bunch of different licensing agreements, then it’s just going to slow down the whole process, you know, and I think of it as like it makes it feel like a type one decision.

[00:35:25.730] And we really want to make these type two decisions, which is like, OK, you could change it. I don’t know if you’re familiar with type one and type two decisions. Right. Where type one, decisions are like these are ones you want to do, be careful about because they’re very difficult to undo. Right. And Type two decisions are ones that you can make that decision now. But if you need to go back and you need to reverse that decision, you can do you can do that.

[00:35:50.570] Right. And so what happens is a lot of things get treated like type one decisions and this can happen. And, you know, in personal life or in organizations where you see this creep of Type one decision thinking and everyone is getting really wrapped up in trying to make the perfect choice and that you get analysis paralysis. And it’s a fear of like what’s going to happen if we get this wrong. And this is this comes into application design all the time, right.

[00:36:20.570] Where it’s like we have to perfect the architecture. Right. We have to get it right. And this is the big upfront design approach that then it takes months and months. And then by the time the software actually ships, it’s like, well, actually now we have smartphones and we need it to work on a smartphone. Right. And so you can actually create a lot of problems when you treat too many things like a type one decision. And this comes up a lot.

[00:36:45.020] And, you know, I do product marketing, so we like to get the messaging right. And so sometimes we get a lot of folks weighing in, oh, you’ve got to get picked those words carefully. And it’s like this is web copy, right? If I need to, I can change that word. Right. I can change it tomorrow. Like this is a type two decision. Let’s not turn this into a type one decision. So that’s that.

[00:37:07.520] It’s an agile mindset as much as it is how you actually set yourselves up to be able to treat more things as a Type two decision. So when I look at VMware Cloud Universal, I’m like this is great. This this totally opens up type two decision making for folks because they can they can change what they’re doing. They don’t have to have the big upfront design master plan. That will undoubtedly be wrong somewhere. Right. Just because this is life and reality.

[00:37:40.880] But you can you can enter the fray and know that you can change decisions, you can change your mind, and you actually now have a licensing model that supports and aligns that. So now it’s just really kind of up to you. If you’re going to if you’re going to do all the other things to make these more type two decisions wherever possible.

[00:37:58.970] – Kit
I like that framework was unaware of the type one versus type two. At first I was like, is it like Type A or whatever type B personality thing, but no, OK, I get it. No, I totally agree and it’s this, this notion of preparing and optimizing for the inevitability of change or maybe another way of putting it is optionality. Right. Because what we have seen with customers. Is that they decided they want to move to cloud and they originally have a plan that’s like, oh, is going to take me a few years and because we’re going to move all these ads manually, then we come along with VMware Cloud, let’s say VMware Cloud on AWS and they find they can move much faster and they say, oh, man, this is awesome.

[00:38:41.720] So they want to move fast. But then they say, hey, I got all these licenses on Prem that I don’t need anymore and I got to buy more licenses up in the cloud because I got more stuff in the cloud. And so the great part about Universal is it doesn’t matter. Like it’s you’re buying into the same thing. It’s like it’s all one pool of resources, entitlements, their licenses. And so as you move to the cloud, whether it’s faster or slower and you need to move back on Prem or something else changes, you have that optionality and VMware Cloud Universal supports you in that.

[00:39:11.330] I think that’s the really big piece there. And I like what you mentioned Dormain. It’s like, hey, we know we want to move to the cloud, so let’s let’s go that direction and then let’s figure it out on the fly. Like, if we find that we can move a lot faster and things are going great. Great. Let’s speed it up. But if not we hit some road bumps and that’s fine, too.

[00:39:26.570] We can take our time and focus on the most important business problems rather than necessarily being artificially constrained by some plan you made two years ago.

[00:39:35.930] – Ned
Licensing is one of those things that’s always just given me a headache, especially when I was doing consulting and trying to make sure you get the licensing right in the in the work plan. So you buy the right things. You’re not showing up with the wrong licensing when it’s time to install that. That’s always dangerous.

[00:39:53.600] One thing, to go back on the consistency theme, because I really like this idea of like multiple levels of consistency and an abstraction. You mentioned the virtualization layer and that’s I definitely want some consistency there. And Kubernetes is being more of an infrastructure abstraction, but the one above that was the management abstraction. And I just like you to dig into that a little bit more. What what do you what’s included in your mind that management abstraction and how does software development fit into that?

[00:40:22.190] – Kit
So that’s a good question, and maybe Dormain could talk somewhat about the kind of build side. I think of it. I’ve been putting a lot of thought recently into more like the run side that, OK, you’ve got these things in production and now you have a fairly diverse number of infrastructures that you may run on. So taking it just a quick step back on this, because we have a lot of discussions with folks on what is your multi-cloud strategy and is it is there really a strategy?

[00:40:50.870] There is a kind of just an inevitability, something that happens. Right. So we’ve debated this. And what we find is that sometimes people have a strategy, but oftentimes they don’t. And lines of business go off and do their own things in different clouds. They get an acquisition and they’re using a different cloud. So this presents a lot of challenges to the business in the sense of there’s various risks that you have those risks in terms of can you actually maintain your SLAs for that service, are there security and compliance risks?

[00:41:20.770] You look at the different tooling that people have, the different sorts of SRE teams that get built up around this and oftentimes what you find. Is the people have to duplicate all these things on an individual cloud or infrastructure basis. They have different ones in public cloud, on-prem and between public clouds. And not only are the teams duplicating, the tooling is duplicated as well. So it gets really hard to sort of manage that. And so I think what we’re looking at is saying, hey.

[00:41:46.890] How can we drive better standardization there so that when these apps are going out, you can give your developers choice so they may love the ML services on this one cloud and they love these other type of services on a different cloud. And maybe that’s a good business reason to use both of those things. OK, so how do we best support them at the same time, ensuring all the sort of enterprise production requirements that are there? Right. And how do you do that in a way that’s cost effective?

[00:42:13.500] And so I think that’s really where I look at it on the run side from a management perspective and consistency of management.

[00:42:19.960] – Dormain
Yeah, it’s my favorite expression from Cornelia Davis on this was a kubernetes is not a kubernetes is not a kubernetes. So like they all use that word, but depending on where you’re getting this from different cloud providers or even just the way different teams have configured it, you could end up with sort of different exposures of what are the Kubernetes APIs that I as an operator have access to in order to apply the configurations that I want and and manage this on an ongoing basis. And I have to go. If I do, the more I have to go and treat these clusters over here differently than I treat those clusters over there, the more I have that and the more toil that I incur.

[00:43:02.200] So something like Tanzu Mission Control, you can use it to provision your clusters and then you’re kind of driving that consistency from the moment of birth. But you can also attach any CNCF compliant cluster and then you can start to even there we are like, hey, we got to deal with reality. Right? Like some other teams went ahead and spun up their own cluster somewhere. It’s OK, right? Like we may not have the consistency at that level, but we can bump up a level and say at the management level, we can now apply overall management practices and that will then drive down the overall toil and effort.

[00:43:37.260] And so that that’s at that layer to kind of get into some of those. When you think about higher levels, like when you think about, for example, you know, Kubernetes is orchestrating the containers. But what’s in the box like what’s going on in these continuum of…

[00:43:53.430] – Ned
What’s in the box?!

[00:43:54.960] – Dormain
What’s in the box? So how do those containers get built? And if you’re a developer, you probably like containers, but you probably don’t like building them. Right, like you as much as you can just sort of offload that. That’s great. So you can sort of take like, hey, just look at how do I do this, make a Dockerfile, we’re done. But then you end up with well, you might end up with a bloated container.

[00:44:23.010] You’ve just you’ve just shoved in more operating system than you than you needed, which actually increases the overall attack surface area. So from a security perspective, it’s not a best practice that also can hurt you from a performance perspective. And that’s actually the thing that probably triggers more developers to go back and earn their their container whittling badge from the the the Cub Scouts of Development. I just I’ve just invented this organization that, by the way, I will be issuing patches. They’ll be delightful.

[00:44:54.930] So that time of like I’m going to I’m going to whittle this container down to just the pieces that I need. And that’s really like that was a big promise of containers in the first place. Right. Is just enough OS. And and that’s that’s a security best practice, but it’s a performance thing. Now, the question is, OK, if I have all my different development teams and they’re packing various flavors of operating system in there right, like if we leave this up to the masses to do you kind of have the Wild West situation on your hands.

[00:45:29.940] And a friend of mine used to call this the mystery meat problem, like what got packed in there? We’ve got CentOS over here. We have a Debian like operating system over here, and then it’s like different JDK. So it’s like, well, sure, they’re all Java, but like you, you just have all these different layers of potential variation.

[00:45:49.610] So this is where things like the Tanzu Build service actually takes that process and offloads the developers. The developer doesn’t have to get that whittling badge, but it also kind of lets you drive that consistency. And so, hey, we’ve got a golden image operating system. That’s what we want to put in all of these containers. And so sometime in the future, when a CVE’s uncovered and we’re like, hey, what’s our exposure area? You now have the metadata about all of your containers to say, oh, we’re using that version. So let’s let’s roll out an update or. Nope, we’re on a different version. We’re good.

[00:46:28.590] You can answer that question very quickly. And that’s super important from a just a security perspective. But then you’re also driving consistency at those other layers and that it’s even it’s very clever in that you can even go back and rebuild that container without disturbing the developer. Right. You don’t you don’t put that work on them. And that’s kind of what I think of as like the two fold tax of those types of updates where you’re paying a tax in terms of your exposure window into the longer it takes for you to go back and make that update.

[00:46:59.940] If you’re dealing with the CVE, the longer it takes, the higher your exposure rate is right. The dwell time factor from a from a security perspective. But then the other tax is, if you have to go back to developers and say we need you to reimage that or we need you to rebuild that container, you’re now taking away from the time, the precious time that they have to actually build something of business value. And so that double tax is really hard.

[00:47:29.130] Like we don’t want we don’t want to pay that. So this is where you can drive consistency. Then you just have a better understanding of where what you have out there, what your exposure levels are. But if you can automate that right, like you can drive consistency through very labor intensive craftsmanship or you can automate it, and that’s going to be the way that you’re going to actually be able to reach everything that you’re doing and build those containers in a consistent way and with a point of control that you can go back and say, like, I just need to change this slice right here.

[00:48:04.820] – Ethan
This has been an interesting conversation on app modernization. I have taken something away that I did not expect to take away. I expected to take away. There is a way, a specific journey. And at the end of the journey, you have modernized your apps in this one way and this is what it looks like. And that is that is not reality because there’s such a variety of business needs and. A variety of application architectures that exist and so on.

[00:48:26.740] There is no one right way to modernize your apps and get to a state of app modernization. I have a lot to think about, I am grinding through a lot of different things in my mind based on this conversation. So thanks to both of you for for sharing your thoughts on this. Dormain, starting with you. Would you let people know how they can follow you on the Internet and if there’s anywhere else you’d like to direct them, blogs or books or anything like that, please feel free.

[00:48:52.900] Yeah, absolutely. So I’m pretty active on Twitter at Dormain Drewitz, you will get chocolate tasting notes. Just that’s a little disclaimer, so if you’re really averse to chocolate or hearing ever about it, like, OK, probably don’t follow me then. But, you know, we’ve got a lot of great resources on the Tanzu part of the VMware site, Tanzu VMware dot com. One thing that came to mind was a book about responsible micro services from my colleague Nate Schutta. So since we were talking about, you know, when does it make sense to actually make something and do a micro service, for example?

[00:49:30.870] That’s a great little O’Reilly book that that we have there. And then just in terms of news and kind of catching up on things, published a blog post on March 31st that just as sort of a roundup of a lot of different updates from across the Tanzu side of the portfolio, everything from a lot of the integration and collaboration we’re doing with our colleagues across VMware and how we’re part of the broader VMware cloud and VMware Cloud universal announcement. But just other enhancements to that DecSecOps story and how we’re supporting folks kind of having having the capabilities they need to build those types of platforms.

[00:50:11.880] We didn’t get into platforms in that concept so much today, but that’s a big one. And then also even at the app layer and those how do we how do we make it easier for folks to developers to adopt new patterns and get started quickly and really offload a lot of the scaffolding and infrastructure layers that just slow them down so that that blog you can find on Tanzu blog.

[00:50:37.290] – Ethan
A lot of metaphors. There are a lot of metaphors, but very good Dormain. Thank you for joining us, Day Two Cloud today. Kit, same question to you.

[00:50:45.150] – Kit
Yeah. Well, thank you for having us. First of all, and love the discussion. And, you know, it’s very much an evolving conversation. And so have it with, talking with about it with a bunch of folks on Twitter, just at Kit Colbert, on Twitter, also on our Octo blog for VMWARE, octo dot VMware dot com, I blog on there pretty regularly thinking a lot of the discussions with Twitter and trying to formalize them, formalize my thoughts around them. So I’d love to get people to check that out and get get your feedback.

[00:51:14.680] And then the other thing that I’d recommend if you haven’t had a chance to check out yet is the app, modern app and cloud event that we did recently. So that one is VMware dot com slash app, dash cloud dash event. But I think it’s also going to be the show notes in case you didn’t follow.

[00:51:33.320] – Ethan
Oh, yes. Yes.

[00:51:34.570] – Kit
But it’s a nice, succinct summary of the broader VMware cloud vision, what we’re doing there across our portfolio, as well as more information on VMware Cloud Universal. So definitely check that one out.

[00:51:48.040] – Ethan
Once again, thanks to both of you for appearing on Day Two Cloud today and catching us up on VMware’s thoughts on app modernization and how VMware can help us all with that. And if you’re listening, thanks to all of you for tuning in virtual high fives, because you’re awesome people out there. And if you have suggestions for future shows, vendors, you want to hear from, topics you want to discuss. We want to hear them hit Ned and I up on Twitter at Day Two Cloud show or fill out the form on Ned’s fancy Web site, Ned in the cloud dot com.

[00:52:12.670] And if you like engineering oriented shows like this one, because of course you do visit packet pushers dot net slash subscribe. All of our podcasts, newsletters and websites are there. It’s nerdy content for you. That’s what it all is. It’s designed for your professional career development and it’s all free. And until then, just remember that cloud is what happens while IT is making other plans.

Episode 93