Panel – Enterprise Cloud-Native Migration

Everybody thank you for joining us for keynote session on Enterprise Cloud native migration. com a number of things. So I'm very pleased to be joined by a couple of experts.

My name is Mitch Ashley. I'm CTO with Textron group and all so part of our analyst or organization principal with text drawing research and have two gentlemen who I've known both for a long time though. They haven't necessarily work together much until this point.

So we've got a good a good start here Donald Lutz and Mike Rothman. Let's start by Donald if you want to start introduce yourself and tell us a little bit about you work with house and what you do and what kind of things Dallas does. I've been I work at Taos.

I'm a senior Software and Cloud architect. I was originally working on what we call our advisory services. So these are Cloud offerings that we offer consultative services to our companies helping them do various things everything from cloud cost optimization to security to sort of the gist of that.

And now I'm working heavily on sort of the whole Cloud migration and what's involved with that. Excellent and tells a an IBM company right house and IBM company. That's the hat.

I don't think that's the new IBM logo, but we get we get where you were going. I have no other gear so the gear okay. And Mike Rothman introduced yourself, please.

So I'm Mike Rothman. I am general manager of tech strong research as well as Chief strategy officer of the tech strong group. I've had the I don't know whether it's good fortune or just pretty lucky to have been, you know, really kind of at front center in terms of a lot of the cloud security Evolution that we've had.

So we started working with the class security Alliance 11 12 years ago, we built the curriculum for the ccsk training and of late really over the last three to four years. I've been working almost exclusively before I joined Tech strong in helping clients really navigate this idea and this migration of how do you migrate workloads to Cloud infrastructure mostly public Cloud, but you know, certainly we've gotten involved in a lot of cloud native and container eyes type of environments over the last couple of years and really helping them do that while maintaining and not having to compromise on Protection for both their infrastructure and the data that they roll up into these workloads. Hmm fantastic fantastic.

Well, you know sort of the the oversimplified version of Enterprise or any kind of migration in the cloud is lifted ship right? Well, that's sort of the the most Brute Force way. You can get something to go out and we're way past that.

I mean maybe maybe folks are still doing that but it's a much more complicated sophisticated to really move applications and all the elements that's required to run. It isn't one app. Right?

It's Minneapolis one after requires a lot of other things to go with it other applications on the services all kinds of things Donald you're living in eating and breathing this stuff on a day-to-day basis you work with customers. Why don't you kind of give some your thoughts on sort of the framework of approaching that maybe what some of the challenges are and we'll dive into that even the large companies we run into their they really, you know, they want to move to a hyperscaler environment. And a lot of them are interested in multiple multi-scaler.

Kind of environments so they are when they take it on, you know, they haven't clearly delineated. You know, we have a bunch of Legacy applications. We want to go to the cloud, you know that a lot of these companies can have revenue or 500 million dollars.

So that's sort of like a baseline but they kind of view going to the cloud. We jokingly call them the teenagers they go in and they pull up some portal interface and they spin up some stuff and then they change some things and they don't know why they change and they don't know what's going on. So you have to sort of get them to the principles of what are your workloads?

What's a landing Zone? What are your devops principles and how do you do cicd in what infrastructure is code tools? Do you use those are kind of the Baseline of that?

A lot of them aren't very sophisticated. Even if they have a very large it Department haven't really thought a lot about that nor have they thought culturally about how they're going to you know, connect the business and the technologists in everybody especially business app owners in this process. Every one of those are like not a small challenge.

They're all biggie biggies. They're all very big, you know and they you know, we also talk about Cloud centers of excellence which you know, very few of them have even though we use the term a lot most of the time they don't really know what that means even. Even when they sort of say well, we know what that is then.

Well, what does that mean? How does that relate to security governments and then you realize they have no understanding of that at all. Yeah, you know if you kind of think about it and and Donald, you know, what I certainly have seen a number of those folks and that ilk of organization.

But you know, if you think about it from a crawl walk run standpoint even what you're talking about is as kind of unsophisticated and and obviously complicated but um, you know early in the process, I would still view a lot of those things see I C D and and kind of integrated devops and this environment as kind of walk, right, you know, a lot of the environments I get into they're at crawl, right? They don't understand even basic Cloud networking structures, right? They don't understand, you know, how they should be provisioning this and a lot of it also varies whether you're dealing with the business aspect of the organization or whether you're dealing with the infrastructure folks, right the infrastructure folks sitting there going, how can I put like, you know, I I walked into an environment and they use the term wall Garden, right, you know to refer to the network that they will building in their environment.

I I wanted to slam my Through a wall. It was just like oh my God, you know you're trying to build your data center right in the cloud. I mean, it's just like yikes.

I mean don't don't go back 20 years to you know, kind of these architectures when we made so much progress on a lot of different fronts. So yeah, I mean for the folks that have embraced, you know, kind of an application driven Evolution and migration, you know to the cloud and and or even to, you know, kind of a containerized environment you bet right see ICD a lot of the integrated processes working we get testing involved, you know into the process as an automated type of function absolutely but you know, and again I'll poke it you Mitch a little bit about you know, lift and shift not still happening. Not my world man.

I mean I still walk into a whole bunch of environments where you know, they start talking about trust zones and and I grew up as a networking guy, right? So so I kind of you at, you know, kind of layers that layer seven, it's all the way up there, right? There's a lot of stuff we got to do underneath there and and I'll tell you I mean you just you just a lot of folks that that, you know kind of talk about process zones, they they sit there and they buy huge, you know virtual firewalls to do their access control and they haven't taken a step back and go how can I actually strategically think about my tenancy as a way to you know, isolate a lot of these environments and then once you do that, then you can really start to leverage a lot of the, you know constructs that Donald was talking about And by the way, that's technically known as a softball Mike.

So good job. Thank you smack and Nomine out instead of Singapore. You know, it's I think what's what's interesting about this is you don't move the whole organization of the cloud.

You don't move all of it, right you do it in phases and you mentioned a phrase Mike that I think is is maybe one strategy here. I think is a good strategist think it is an application land right because a lot of times it's Do I need to move all my legacy stuff. Do I need to move everything that I have or maybe I want to build the next or maybe my first Cloud native application, you know with microservices and containers in community or whatever environment, you know environment that you're creating probably not going to do that in your data center though.

You could oftentimes that's another approach to starting out on the cloud is you see that happening down. Sometimes I would claim containers and kubernetes or a lot more sophisticated than a lot of them know in a lot of ways because they have you know, Like a spring boot application that does a certain thing for their Enterprise and they are you know, they want to take it to the cloud because they think they're going to save money. So to speak they view it, you know, it's sort of goes into some operational expense land and life is better and that's why we started then talking about Landing zones.

Okay. So we said, you know, you want to look at zero to eight workloads. If you have none then we'll figure out but then we want to keep a minimal set of workloads.

And then we mean by a landing zone is you want to place where you have figured out your identity your security your High availability your backup so you have a structure which you can put them so you can have a landing zone for like you mentioned for your containers a landing zone for sap a landing Zone, you know, there's different ways but there's a core framework behind it all just like you would do with an application framework and most of them haven't really thought about that. I would claim in the past net. You know the past two years Microsoft's really got big into this the whole idea of you know, creating a framework around how you move these Landings zones, you know, which leads to governance and the cloud Center of Excellence, but most of these companies You know Landing Zone sounds like something from Star Trek or some other science fiction thing.

It doesn't show and even the cloud Architects that these companies will have don't know what a landing zone is. But I appreciate the the teenager stage you're diagnet. I think it's kind of gangly to teenager.

At least when I was growing up it is that awkward. Like let's go see what we can do with this and start to work with them learn to play with it. But you're right.

You've got to set up. My mother's with The Landings on concept is right as interesting. I was talking with a senior Security executive at a unnamed coffee company that we often frequent and his strategy is a security leader was to go put the identity in place that every apps can need that just one of the first things you're gonna need.

Let's go build the identity infrastructure in their Cloud providers, you know, maybe it was using Landing Zone capabilities they have maybe it was earlier than that, but that's it's one of those building blocks. You've got to have you know with other security with monitoring you talked about Donald so it's kind of like Build the principles, you know, at least the structure of the principles as you can further out. It seems like a pretty good approach.

So I kind of look at it and and I'm coming at it mostly from a security, you know kind of standpoint. So I'll kind of reflect that, you know perspective and in a lot of views but we kind of broke out and one of the you know kind of topics that we did a lot of research on, you know, really two to three years ago was this idea of cloud security maturity, right? And we broke the world up into three different domains first being the foundational domain and Mitch.

That's a lot of what you just mentioned. Right first is account security instruction. Again, that was the tendency point that I made before.

You don't have your tendency, right? It's gonna be difficult to do stuff. And by the way, and and this is the thing that most folks don't understand.

It's fundamentally different for how you have to do Azure because as your ad is linked up to Microsoft 365, right, so we have Microsoft 365 and you're moving about your stuff into Azure you kind of have this code dependency there that you have to factor in AWS is a little bit different. Google is a little bit different on that front, right and Get to Identity and access management. Would you just mentioned if you don't have a lot of those roles those, you know kind of policies in place difficult to provide any measure of control over your Cloud estate, then you get to logging and monitoring and again as a security person that's kind of a lifeblood of what it is that we do and then finally you have interested in response, right?

Those are the foundational types of capabilities that you know, I think you need to work on and and Donald I mean that's kind of what I view the purview the cloud secure the cloud Center of Excellence is really, you know, kind of the organization that needs to own a lot of you know, kind of that foundational capability and then you know, what you do for networking or workload protection or application protection can be done on an application by application Basics, but you really have to have that foundation in order to be able to you know, provide some type of reliable environment to work it. And even the security we end up talking about, you know is our back and there's a back so then we start talking about how do we transition to attribute-based things that live in the things that you create? We sometimes we call them apps.

Sometimes we call services. The problem is what a lot of these companies have they call Micro services and the container or like three things that are all mapped together that really aren't a microservice because they don't do one thing but they haven't really figured out how to split them apart. So then you have that becomes difficult concept too because it's like okay would be easier if we could separate these but since we can't we'll just move it over and then we'll kind of talk about how do we get you to the idea of something like a back, you know, and you know and most of them never heard of that because they know what our back is but a back sounds like some other bizarre Star Trek concept, too.

Yeah, maybe if you kind of can get down to a tactical level with many of them you just say kind of like conditional access and in Azure, then like Oh, you mean by setting a policy based on where somebody is, right? So, you know, they're they're kind of ways to not scare them off, you know from a lot of these, you know kind of Fairly and and the problem with all the power that a lot of these capabilities bring is that folks get into you know, you know kind of brain lock right? They're like, I have so many different options for how I said these policies I end up not doing anything, right?

So so again, you know kind of that's kind of why I favor the application Centric approach because then you build the infrastructure that your application needs and it kind of drives those decisions. And as long as you're kind of on a consistent Foundation, you know, you you can achieve the longer term goals by getting them there one step at a time. It's supposed to try and you know drive them towards, you know consistency in every area.

I do do we run into the problem a lot. I would imagine many organizations have already got some groups that have gone off and it's done done the teenager thing right gotten I've gotten their app. Maybe they built up, you know Greenfield app or whatever or did it lift and shipped or some variation of all that and you probably don't have one you may have Between sizes you could have a dozen of them, right?

And so Donald I have to imagine is it is it taking the learnings from those groups or do you have to kind of step back and say well wait a minute, let's step back you do it right the first place. We're kind of foundation. That's that's map it and then look at how we do it.

Yeah, because they're like there's one they can't mention who but they have a you know, some of the transportation industry and they have a very large cloud-based five-year. Set of microservices they built there weren't built very well, but you couldn't take that and help them do the rest of it because it was very it was a one-off that really just lives with a certain group and there's not a universal mapping. Across the whole organization.

They don't have you know, we end up talking a lot about Conway's law which is, you know comes from software engineering that you know, the way organizations communicate is the way they build their software in in because the cloud sort of changes that whole transition. We talk a lot about Conway's law and try to get people to understand you know, that if you have these very disparate groups that don't communicate you have a lot of problems going to the cloud because you are trying to blend everybody together into a big, you know group that all communicates that causes other issues because they're not used to doing it. And and I wonder too is is the cloud Center of Excellence is that essentially what the Enterprise architecture group is becoming or is that a parallel to what we're traditionally think of because that's where you look at how all those things fit together and what some of the architectural standards are pre-cloud.

So whatever the architecture is parallel is what I've seen because you know, I have an Enterprise architecture background which is why I went to Taos because most of the people at tests were more. Infrastructure focused and house wanted to have someone who could kind of. Deal with both and the problem is the Enterprise Architects don't care about the infrastructure in any stretch of the imagination, even though they should like understanding you know, why do you want no sequel versus that what does that mean about?

How you Shard and partition? They don't really play in that Arena. And the cloud Center of Excellence you end up with this is one of the things I've been noticing a lot that you end up with a lot of devops people that are obsessed with tools.

This is one of my things I've noticed so they really get you know, if I throw these three Tools in here, it doesn't matter what they're called. That will fix those problems and then we have a you know. A center of excellence in those tools aren't necessarily the issue.

I obviously you should read the Phoenix project. There were no tools. They just had a kanban board.

Exactly. It's about how it's not it's not a technology though. We love to buy two.

And I think tools are you know, obviously part of it. I guess the way I position the center of excellence to a lot of folks is as a consultative body to a lot of these business units that really have no idea what they're doing. Right?

So the center of excellence Donald to your point, you know, they do kind of set that architectural Foundation But ultimately they have to be able to do stuff too and you know, a lot of The Architects, you know there and ultimate output is paper, right, you know kind of ultimately the cloud Center of Excellence has to be stuff. So that stuff tends to look like things that that business users that application groups can actually leverage that then the center of excellence will take back and integrate that so you get a positive feedback loop so that stuff you're learning with each, you know, kind of new implementation goes back and better, you know and improves the center of excellence from the standpoint of you know, what processes they have what tooling they use, you know again what what structures are in place so then the next group can be that much smarter. So be kind of think about him as the center.

Learning, you know for all these Cloud environments again because things are moving so quickly yet again. You kind of close your eyes for two or three weeks and you miss a whole month mess stuff, right. So kind of having, you know a group that's in the center of all this to really kind of relay both Urban knowledge as well as learning from each one of these different environments.

I mean that that's been a very productive way to you know, kind of position that group and then they feel like they're contributing about and more than just. Hey, we're gonna put a position paper out and then the business unit's gonna do whatever the hell they want to do anyway, Yeah, they're not the approval group. You must come to us, right which is interesting me.

I mean nothing's ever clean and easy right now. There's not even with silos no things ever adjust in a silo in a good example is you know, the the development for the apps and the things that are done outside of it, right and business units. We have a lot of Loco no code and and full code being developed outside of that.

It seems like the Cloud Center of Excellence can be kind of a Switzerland if you well on neutral zone Romulan neutral zone for you know going regional a lot of Star Trek here for anybody in the organization to say, okay, you know, we're we've we've done what we can in the business unit. We need some help we're going to it. Maybe they do or don't want to help us but it isn't a group that can kind of look across the organization and share some of that knowledge.

Yeah, and it doesn't some of the cloud stuff is very upsetting to them because they feel like they're losing their power because they may not necessarily have those skills. And because when you move to the cloud, it has a much larger software component, so they're not just racking and stacking which then causes them to have some you know concepts of oh, this is different. Let's talk about you.

We mentioned Landing zones earlier. And I know you have you have some views Donald about you know, the major hyperscalers and sort of where they're emphasis and focuses are on Enterprise type workload. It's an applications talk about is and cloud formation to and for AWS are those things real are people using that yet.

Is it A New Concept if you were on your journey trying to figure out how to get to the Cloud you should like, press pause go look at that and incorporate it. What are your views on that? They are real.

I mean, you know, it's sort of like, you know in AWS cloud formation is evolved to this thing called cdk, which is a tool kit that allows you to write code very different than terraform more. It's easier for developers. You can write it in typescript go see Sharp, it has a lot of those and it translates those in the cloud formation templates.

And they actually even ported it to a way that you can use it to build kubernetes. So it's valuable, you know, it's it's understanding those Concepts, you know, and how do you get there? You know fundamentally, you could use a script you could any of those things or tools but you know, the difference I'm seeing is a lot of the large companies have lots of developers.

So with a tool like cdk it's easier to move and development groups because they may not necessarily have A set of people that know how to use various Tools Salt stack Chef whatever it is, and we've noticed that you can roll them into those tools because it's like coding it has a very similar structure. Because they don't have to understand it. They can go look at some interface and they have a thing in cdk called the construct.

So if I want to build a Virtual machine I put these parameters in here. It does that you know, the understanding is it's abstracted like you do in obsequent programming which makes it easier to cross the board because those you know, super devops people there's not enough of them to put them in all those companies and all those positions. And like you you've looked at like platformation too as part of your work.

What we have and and again, I mean, I think that there's a level of maturity that you run into, you know, the folks that are doing so so we've done some work with you know, kind of think multiple thousands of accounts right their past providers and and they do that and and that's all about automation. Right you you just can't scale unless you have you know, some measure of automation. You can call Landing zones and call them, you know kind of packaged infrastructure design patterns.

There's a hundred different ways to you know, kind of describe them. But but it's basically this, you know kind of idea that that I have to you know, kind of embrace not just infrastructure as code but a lot of the operational motions that are required around that in order to scale to that degree, we found the right point to be somewhere between 15 to 24 different accounts subscriptions Etc where things just start breaking down, right? And then when you have a whole bunch of companies that are well, I got this group they're doing that they're doing that.

It's so you know at some point it may not be just you know, kind of a huge Enterprise. Okay, you get to 20 accounts and then that's it because you have these different groups that are independent and doing their own thing. Right?

And but if you have kind of a command and control, right, you know still very strong top-down it environment again, you get to 25, you know kind of accounts plus you're just like man this stuff is just breaking and that's when you start to embrace, you know, things like cloud formation. We still see a lot of terraform. It may not be as flexible as some of these other things but you know kind of all at least all the large Enterprises I'm dealing with are planning from multicloud and they just feel that you know, kind of cloud formation or even you know, kind of what Asher's offering from, you know from a templating standpoint.

It's just too restricted. So so they kind of drive down that path because they're planning for it. Although, you know, there are going to be compromises and and what's interesting.

Is that right? You know, what in in the good old days right like two years ago, you know you Had four or five years right where you know kind of you could take an infrastructure component and still ride that without making significant compromises. That's not the case anymore.

Right? You know, we're talking about terraform as you know, Legacy technology relative to some of these other things and you know, so that just kind of starts to illuminate just how the changing cycle times that we have, you know in Cloud native, you know environments is really changing the way we have to think the agility that we have to bring to the environment and the fact that you know as Andy gross as you know, we don't kill our you know, our own stuff somebody else is gonna do it for us, right? So we have to look at you know, pretty much each application environment going if I was designing this today, what would it look like right this idea?

And I was just working with a client list five year upgrade Cycles, right? So they literally can't touch an application for five years because you know, they can you know upgrade anything, you know any components any the hardware and software on. And man, the world is like a totally different place in five years.

So with that that just isn't a sustainable approach right? I mean we have to take a look and and just look at just basically say right, you know kind of what how should I architect this environment based on today's technology not based upon, you know kind of the standards that have come, you know out of the architecture group, you know, kind of two or three or four years ago. Yeah, I feel like we'll have like two or three generations of what we're doing in five years, but on the other hand, we're still doing what we did five years ago, right 20 years ago.

I mean, you know, we still talk about folks during date on Big Iron and you know kind of oh, we put an IP stack on it. So now it's part of the you know Community. Well not exactly right.

So so yes, there's certainly that perspective that you know, it's really hard to kill stuff but I think we have to take that approach of you know, zeroing out, you know, kind of at least from a lot of architectural constructs when we're designing a new application obviously refactoring stuff there, you know, listen, we're Delta and we we have data somewhere we have to get it right so, you know, there are going to be some some constraints that we have on that front but you know for net new applications or Innovative groups, I mean you should be looking at the latest and greatest and embracing that within the construct of the foundation that you're building which brings us back to our Center of excellences, you know kind of the group that you know has to own a Of you know kind of that structure. Well, where does where does cloud native fit into this, you know in terms of really not building you take a nap and building three micro sir building in three microservices so I but Where does that fit into the picture Donald our people? Starting Greenfield applications that they're trying to do is cloud native.

Yeah, figuring out the kubernetes, you know a complexity. Where are we? I mean I took the previous company was that I took them all to kubernetes.

So even though we were just running in Azure, I built it so it all ran in kubernetes and we just consumed kubernetes and not the Azure service. and that is a different level of complexity that most people haven't addressed because you're basically saying that you know a container is The base unit and you have you have you know pods and you have microservices and there's a great book called building microservices by I can't think the gentleman's name who was at thoughtworks. And there's a lot of principles you can follow to do that, you know, and it goes back to the 12 Factor app that came out a long time ago.

And if you follow this principles configuration testing All of the above you have Cloud native things. But that requires sophistication on The Architects and the developers to really think about you know, how do I build really small little things? And how do I make these work right and how do I know these small little things, you know, they get confused.

Which then leads to the whole and the soft realm we have you know, what the main driven design is you understand what this means that you know, you need to have this domain. And we need to talk to the business about what the domain is because that's what matters not necessarily all these other components and that you know, and then you get this other concept of called hexonical architecture, which is about ports and adapters so that you have you expose the domain is hidden behind services and there's there's so many levels. And getting people to understand that, you know, I mean at the previous company, I got all the developers up to speed on this.

It was very conceptually hard. It did not like me because they thought running everything and something called kubernetes was like like some kind of crazy thing because who in their right mind would run it something like that. So there are so many levels to get people too.

There was an article in new stack how kubernetes which I've argued for a while is becoming a platform. So it's becoming somewhat invisible. It's there but like serverless is a lot of kubernetes and people don't know it but then it gets to the whole you know, what is platform engineering which is a whole other we can have a whole long discussion about how do you get to platform engineering, you know and companies are trying to figure out you know, you know, what is platform engineering which you know would be underneath the cloud Center of Excellence to provide the tools to the cloud Center of Excellence.

But once again, that's a large jump because you're trying to get the teenagers so, you know put the You know start the car pass the test drive the car, you know, and you know, when you sort of start talking about okay, we're gonna do this Cloud Center of Excellence all of a sudden they're like, well that's like a Ferrari. We don't even have a we have a pinto there's better than the Corvair but okay, are there examples that we can look towards right? I mean, you know, so Donald you're just talking about platform engineering right and that can mean a lot of different things.

But if you're in a command and control, you know top down it driven environment. So platform engineering resides within it like it used to in the data center does an application group within a business have platform engineering or is this something that we see within, you know, basically SAS providers who are you know, basically building out a service that has to you know, scale up or scale down or maybe it's the tech group within an Enterprise financial institution. I mean are we see differences in you know, kind of what these deployment motion should look like what these organizational motion should look like depending on whether All you do is deliver something be a web browser.

Whether it's just something for how you interact with your customers or whether it's you know, again a way that you're kind of trying to improve and streamline some internal operations and I would guess I don't know this for sure right but I would guess that you know, there are there a radically different organizational approaches that you have to think about depending on where in that buck, you know, which bucket or which category of organization you would fit into Yeah, that's true. They have you know, the platform engineering, you know, historically would be it and even though they didn't call it that but then I think platform engineering has to be embedded sort of like the devops principles in each application Development Group. They're not separate because you know, it's the whole you know, you build it you own it concept means that you know, the app groups can't be separate from it that previous company.

I worked at we made them own it to they didn't like that because that meant they had to understand, you know, because devops sounds magical to developers. It doesn't sound like something that you know, I write the code and I compile it happens and I'm done and then when you start talking about well, how do we want to like figure out how these things go and have that process conversation it goes kind of weird and you know, I'm seeing that in the end that's gonna be part of most of these, you know app groups because it isn't really separate. I mean, you know as the Phoenix project so you really don't want to separate that out if you if That people aren't involved.

You're really in trouble. It becomes another infrastructure group, right essentially kind of an Ops infrastructure organization that that's bad. But I think you're talking about something different with platform engineering.

But it's interesting to me about five minutes left in our time here. Yeah, this thing as you were talking down about different architectural Concepts and hexagonal our software architecture design patterns, you know, I think this is part of that, you know kind of chocolate and peanut butter. How do we stick it together and create it reaches your buttercup?

Is you know the security folks don't sit around and talk about I've just gone architecture. It's right and the software engineering folks. Don't sit around talk about, you know atps or whatever.

We have our disciplines but you've got to kind of find that common language or find ways to to be able to work together and we'll worry about our esoteric stuff and you worry about your air statistic Eric stuff. You don't have to know everything. I know but kind of getting that place together and you're talking about the app people have to be involved.

It can't be the silos or we end up with the wrong platform. Right? We just have all the stuff that we need.

It's not designed the way we need it. It's kubernetes, but it's not you know that kind of thing the green Yeah, I mean it goes Haywire but you know, it's it's difficult because companies aren't used to you know, creating those sort of. Organized groups, you know, and if if you did the cloud Center of Excellence, well, you could spin them up and move them around and put this group over with this group and they all could coordinate but that's not the way historically it's been done, you know.

You know all those companies have a brand out of out of the Phoenix project and there's some you know, he's he's the being who causes having to fail because if he's not available nothing works and that's the whole problem, you know, even the executives will say well we have to have him on the call because we don't know what to do because unless he's there we have no idea any of this works. Yeah, that's not that's Brent and Phoenix project right and brands on any other calls fixing five production issues. So that's so it kind of underlies a lot of what we've danced around but didn't really address right?

So, you know kind of as we wrap things up it still all gets back to culture right you have to be able to embrace a lot of these new ways of working new organizational models, right, you know kind of the security folks can't get all territorial about you made this bad decision and all that. It's it's ultimately in our world right? It's about risk acceptance.

These are the rest of doing something stupid, right? You know, if you want to do that because you have a business need to do something stupid. Okay, right, you know, I can't stop you from being stupid.

But you know, I can tell you about to be stupid, right? Yeah, you know and and it's it's that, you know, kind of stamping our feet and taking our toys and and going home that we can't do it. Right we have to figure out a way to work together, you know in my world.

It's where are my insertion points, right? You know, how do I get my stuff? Pipeline and can you please Empower me to break deployments when stuff is just stupid and and yet, you know again you would just be shocked at how many folks look and and they'll put it in jira or you know and or put in service now and and we'll look at that right while the thing continues to you know flow through the pipeline and you scratch your head and go you're not serious about this, right?

You're not serious people if you're not willing to make some of these specific decisions and and that to me all gets back to culture. So we talk about, you know, kind of being successful as we migrate to some of these new structures if if your culture is not willing to accept these things. It's not gonna work no matter how much time you spend on tooling no matter how smart your Architects are no matter how wonderful your center of excellence is if you've got folks supporting the process from underneath.

It's just faster waterfall, right? You know, we joke about you know, it's just being faster waterfall at the end of the day. Sounds like with some challenges you've lived on.

Yep, a lot of them very much. So well, we're at the end of our time gentlemen. It's been awesome fantastic talking with you and having you share your experiences and perspectives and the good news or the bad news as we've met the enemy and they are us right.

Yeah how to make all this stuff working get our nonsense out of the way. Maybe it's about building. I don't know.

I don't overuse the word but kind of building a cloud-centric culture right thinking about this is how we want to start to do things and and we need to we need everybody needs to arrive together. It isn't that's one group race ahead and leave everybody behind and we're all fighting in a new side, right? So well, thank you.

Donald fantastic. You can share all your experiences and good luck with your work at Taos and Mike a fantastic working with you is part of tech strong research and just collaborate on a couple projects that are coming out here. So good to have you on board.

Thanks guys, and thank you to the audience for joining us today. We hope you've enjoyed Cloud native day virtual Summit, and if you haven't checked out the rest of the talks, there's some great stuff there. So please do and we hope to see it in another virtual event with tech strong group.

Thank you.