>>Live from Atlanta, Georgia. It's the cube covering Ansible Fest 2019. Brought to you by red hat. >>Welcome back everyone. Live cube coverage here in Atlanta. This is the keeps coverage of Ansible Fest. This is red hat and suppose two days of live coverage. They had a contributor day yesterday before the conference all being covered by the cube. I'm John furrier, Miko Stu Miniman. Our next guest is Chris Gardner, principal analyst at Forrester Gardner. Welcome to the cube. Thanks. See you. Good to talk to you. Hey, analyzing the players in this space is really challenging. You've got a new wave that came out a few months ago. Yep. Laying it all out. Um, certainly the world changed. You go back eight years. Cloud was just hitting the scene on premises. Look good. Data's Stanley was rocking. You're doing network management, you're doing some configuration management now you've got observability, you've got automation apps. The world's changing big time. What's your take? What's this? I mean, it's interesting because the prior versions of that wave focused entirely on configuration management and the feedback I got was, um, the world's a lot bigger than that, right? >>And we have to talk about platforms and you heard it this morning during the keynote about Redhat moving towards an platform and automation platform. And my definition of a platform is things like configuration management, hybrid cloud management, all the various types of automation and orchestration need to be there. But you also need compliance. You need governance, you need the ability to hopefully make a call as to what is actually occurring and have some intelligence behind the automation. And obviously you need the integrations. It's not a situation to simply have as many people as possible, although that's nice as many vendors you work with. But to have real relationships, if you have Microsoft working on automation code with you, if, if Amazon working on automation code with you, that makes a true platform, right? It's John said earlier day a platform needs to be an enabler. And we've even said, if you can't build on top of this, like the collections that Ansible announced here seems like it might fit under that definition. >>And there's an old joke that everything becomes a platform eventually. Right? Um, but I think that, I think it bears it. There's some merit in this one. Um, the other thing is that I'm seeing a lot of folks want a holistic automation solution and the only way you're going to do that is to have a platform that you can build things on top of it and connect the pieces and provide the proper governance. So, um, I'm mostly in agreement with the definition that's been described here and I think you could tackle different ways. Uh, and all the vendors in the space are certainly doing that. Definitely platform thinking is different. Um, you know, the easy way to look at it and the old big data space do, we'll use to cover that was a tool versus a platform, you know, tools, a hammer, everything looks like a nail, did great things. >>One thing great are a few things. Good platform is more of a systems thinking. Yes, yes. And you've got glue layers, you've got data. So it's really more of that systems thinking that separates the winners from the losers, at least at our opinion. Absolutely. I mean, when you looked at who was the leaders in my wave, it wasn't the basics of automating or orchestration and configuration management, they all had that. The, the ones that were winners, where can I do compliance in a different way? Can I actually have people come into the system that aren't it people and make a call on some of these things? Can I apply AI and machine learning to some of this? Can I make some recommendations and hopefully direct people in the right, you know, the way they should go. And you know, the folks that were able to do that Rose to the top, the folks that weren't were average and below. >>Yeah. Chris bring us inside to some of the competitive dynamics here. We understand that, you know, there's a lot of open source here and therefore everybody holds hands and things can buy y'all. But, you know, there's, you know, product tools, there's the public clouds and what they do. And then, you know, Ansible, uh, you know, fit, fits in a lot of different places. Yeah. It's, it's a bit ironic because, uh, you know, this is one of those waves where, and it's very rare that everyone was sitting was, was at least preaching kumbaya. They are all saying that they were friendly with one another. And, and, uh, quite frankly, I, I tend to believe it. We're in a situation right now where you can't get by, especially in a hybrid cloud world. We are going to have resources that live in multiple, you know, AWS and Azure, but also on premises and at the edge. You need to have these integrations. You need to be able to talk to one another. So, um, that said, there's certainly a lot of coopertition going on where people are saying, if I can integrate these tools better, if I could provide a better governance layer, if I can again, hand things off to the enterprise in a way that has not been handed off before that I don't even have to go through an INO group and infrastructure operations group, those are willing, could be the ones that truly succeed in this space. >>Software defined data center, software defined cloud, everything software defined. Yep. These abstraction layers, data and software. We had a guest on the cube a week ago saying, data's the new software I get. Okay, it's nice, nice gimmick. But if you think about it, this abstraction layer, it's like a control plan. Everyone wants to go for these control planes, which is a feature of platform. As this automation platform becomes ultimately the AI platform, how do you see it evolving and expanding? Because you see organic growth, you see certainly key positions, 6 million stars on get hub. I mean, it's running the plumbing. I mean, come on. Like it's not, it's not like it's just some corner case. >>Yeah, yeah. Infrastructure. Yeah. I mean, you know, in an idealistic way, I'd like to see, we us resolve on singular holistic platforms for enterprises. The reality is that's not not the way you can do it today. What I do try to help clients do is at least rationalize their portfolio. If they have 12 different automation products they're running, chances are that's not the best idea. Um, I've actually had situations where someone will say to me, um, I'm running Ansible in one portion of my organization and chef and another, and I say, well, it's some, they do similar things. And the reason for it was because they were stood up organically. Each group kind of figured out the things along the way. And I have to at least guide them and say, you know, where are the similarities? Where can you potentially, you know, move some stuff from there. >>But the cloud discussion, you know, always debate upon, you know, multi-cloud, Seoul cloud, ultimately the workload needs something underneath. And I think workload definition dictates kind of what might be underneath. So it might be okay to have a couple, you know, automation platforms or it could be great to have one. I mean, this is really the eye of the beholder. Beauty is in the eye of the, >>yeah, in my view. Um, I, I've been an analyst for a couple of years before that I was doing this stuff for a living. I have the worst scars and in my view it's, it's not even a matter of how many tools you use. It's putting the workload where it belongs, that matters. And if you could do that with fewer tools, obviously that from an operational level that makes life a lot easier. Um, but I'm not going to say to somebody, you know, completely dismantle your entire automation and orchestration workflow just because I think this one tool is better. Let's talk about how we can, >>that's the worst case scenario because if you have to dictate workloads based on what tool you have, that's supposed to be the other way around. >>Yes. Setting up a nuclear bomb in the data center or in the cloud has never worked. Note to self, don't do that. Yes. One of the interesting conversations we've already been having here at the show is that the tool is actually helping to drive some of the cultural change in collaboration. So, you know, what are you finding in your research? How is that, you know, kind of this admin role and you know, to the cloud in applications. You know, it's interesting. I, we continued to beat the drum that these folks are becoming developers, but we've been beating that drum for a decade now and quite frankly we had to continue to beat it. But what I think is more even more interesting is we have groups starting to pop up in our research that are separate from it, that focus on automation in a way that no one has done before. >>Some we went into it saying, Oh, that's a center of excellence, right? And the teams that we talked to said no, do not call us a center of excellence. A two reasons. One is that term is tainted. Uh, but secondly, we're not one team. There's multiple automation teams. So we're actually starting to call these groups, strike teams that come in and standardize and say, okay, I have a lead architect, a lead robot architects say it's around infrastructure automation. I'm going to standardize across the board and when other groups need to come on board, I have the principles already laid out. I have the, the process is already laid out. I come in, I accelerate that, I set it up and then I back off. I don't own the process and I'm not part of it either. I T's got operations of its own that's got to worry about. >>I'm going between the two and when we talk to especially the fortune 100 they are setting these groups up. Now when I ask them what do you called them? They don't have a name yet, so I think strike team sounds sexy, but ultimately this is not like a, a section of it that's been severed off and becomes this role. It's a completely true committee. I yeah. Oh yeah. I want our falls slow process. Exactly, exactly. And it better fits what the role is. The role is to come in, nail the process, get it automated and the get out. It's not to stand there and be a standards body forever. Um, there's certainly some groups that in some types of automation like RPA where you want them to stick around because you may want them to manage the bots. There's a whole role called bot masters, which is specifically for that role. But most of the time you want them to be part of that process and then you know, hand it back off. >>Yeah. We've seen some interesting patterns. I want to get your thoughts on this as a little bit of a non-sequitur. Want to bring it in, but in the security space you seeing a CSOs chief information security officers building their own stacks internally, they're picking one cloud, Amazon or Azure and they're building all in maybe some hedge with some people working on some backup cloud, but they don't want to fork their talent all on one cloud and they cause they need to be bad ass responsive strike teams for security pressure. Yeah, yeah, absolutely. Not as critical with the security side with automation, but certainly relevance. Is that the same thing going on here with this development Durham, this being continued to be as much more around core competency and building internally stacks and building some standards? >>I I, I think it is, and you know what's interesting too is that I work with, I'm on the infrastructure and operations team at Forrester. I talk with INO people all day long, but I work alongside the security team and I said to them a couple of years ago, um, you guys are going to have to get your hands dirty with this stuff that I cover. You guys have to know infrastructure, automation, API APIs, you need to know how to code these things. And I said, are you comfortable telling your sec ops folks, your clients that they go, no, by all means they have to be part of this. So they're okay with them talking to me, talking to them and saying that you need to be part of the infrastructure design process and need to be part of this decision making process. Right. Um, which is different than their sec ops role used to be. So my point is, is that these worlds are not that dissimilar as some people might think they are sec dev ops or whatever we're going to call it. We keep tacking letters onto this thing, uhm, is a actual discipline. And it is a reality in most organizations I talked to the people should. >>So a system has all of these things as data across the system. They have high blood subsystem you're talking about and yet it's this holistic system security and data. Yeah. >>And we're in a world now, especially around things like edge computing where data gravity matters. So all these pieces, you know, it's, if you go back to the old school kind of computer science folks from the, you know, 50 sixties and seventies, they're like, this is not new. We've been thinking systems thinking for awhile, but I think we're finally at a place where we're actually now breaking down the silos that we've been championing to do. So for, >>I got to ask you the analyst questions since you're watching the landscape. Sue wants to jump in, but I want to get this out. So observability became a category at a network management. I mean, network management was like this boring kind of plotting along white space. I mean, super important. People need to do network management. Then in comes the cloud becomes a data problem. Whether it's observability you get to microservices, you got security signal FX, all these companies going public. Um, well a lot of M and a activities basically large segment, a lot of frothiness automation feels like it's growing to be big. Is there startup opportunities here? If, if platforms are becoming being a combination of things, is there room for startups and if so, what would you say? Um, those stars would look like? There are, I think >>what we're seeing is, and it speaks to the observer, observe the word you just said. Um, uh, I can, I can S I can know what it is, but I can't say it. Um, we're seeing the APM vendors move down the stack. We're seeing the infrastructure monitoring vendors move up the stack and in the middle we're seeing them both try to automate the same things. Um, you cannot pull off some of the infrastructure as code automation that we need to pull off without observability, but you can't get that observability unless you are able to pull it from the top of the stack. Um, what we're going to see is consolidation and we're already starting to see it, um, where you're gonna have different groups come together and say, why did have to tools to do this? Why not do one? Um, the reason why you do multiple tools today is because no one is truly strong at the entire stack. >>A lot of the folks that are going down the stack to say that they're not quite infrastructure automation players just yet, but watch this space, they will eventually, Oh, this change happening. Absolutely. Startups getting funded. Do you think there's opportunity to take some territory down? If there's any opportunity? And, and I'm, I'm pushing for this, it's in the AI AI ops space when it comes to these things is actually going beyond where we stand today. So I want to be clear that, um, AI ops is a great concept. The reality of is that we're still a ways away from being practical. I'd like to see not just recommendations from these tools that the startups are providing, but actually trust in them to make the changes necessary. So Chris, it sounds like the antibody automation platform announcement today fits with what you've been saying for the last couple of years. >>So the question is, what's next? Where does the Ansible need to mature and expand and you know, what, what are users asking for that Ansible is not doing today? So a couple things. Um, they did okay, but not fantastic at infrastructure modeling. Ansible. They did okay, but not amazing at what we call comprehension, which is making a call as to, you know, using AI and machine learning to make a call and what the infrastructure layers should look like. To be Frank, no one did really well in that one. So not too, not too bad on that. Um, and the other thing is they need to improve slightly. Is there integration story? They actually have a really good one. You see all the folks that are here. Um, it's just, it's, it's just as hair away from being the best. They're not quite there yet. So, and when, again, when I mean integrations, I don't mean having a laundry list of vendors you work with. >>I mean actually working with them to build code and you saw that this morning where there's the best, uh, right now surprisingly is VMware, but for you Morris built that relationship off for a long time. Um, they work right alongside Microsoft and Google and all these folks to build the code together in the industry. Uh, I think the darkest source of all is probably, and it remains to be seen if they can actually do something that is HashiCorp. Um, Terraform is an interesting player in this entire space. I actually included them in our wave on infrastructure automation platforms and you can argue is it even an automation platform? Quite frankly. Um, uh, I think HashiCorp itself was trying to figure out exactly what it is. But the bottom line is it's got tremendous Mindshare and it works well. So I think that if you watch, if you see the strategy going forward and look at, you know, what they're putting their investments into, they could become a really serious damaging player in this space. Chris Gardner, thanks for coming on the cube, sharing your insights and your research at Forrester forced wave. Check it out. Just came out a couple of months ago. Uh, infrastructure automation platforms. Q three 2019. Chris Gardner, the author here in the Q, breaking it down. I'm John furrier. There's too many men. We'll be back with more after the short break. Thank you.

>> live from New York. It's the Q covering AWS Global Summit 2019 brought to you by Amazon Web service, is >> welcome back here in New York City on stew Minimum. My co host is Corey Quinn. In the keynote this morning, Warner Vogel's made some new announcements what they're doing and also brought out a couple of customers who are local and really thrilled and excited to have on the program the C i O and E V P from Finn Ra here in New York City. Steve Randall, thanks so much for joining us. You're welcome. Thank you. All right, so, you know, quite impressive. You know when when I say one of those misunderstood words out there to talk about scale and you talk about speed and you know, you were you know, I'm taking so many notes in your keynote this 1 500,000 compute note. Seven terabytes worth of new data daily with half a trillion validation checks per day, some pretty impressive scale, and therefore, you know, it's I t is not the organ that kind of sits in the basement, and the business doesn't think about it business and I t need to be in lobster. So, you know, I think most people are familiar with in Rome. But maybe give us the kind of bumper sticker as Thio What dinner is today and you know, the >> the organization. Yeah, I started it Fender and 2013. I thought I was gonna come into a typical regulator, which is, as you alluded to technologies, kind of in the basement. Not very important, not strategic. And I realized very quickly two things. Number one, The team was absolutely talented. A lot of the people that we've got on her team came from start ups and other technology companies. Atypical financial service is and the second thing is we had a major big data challenge on our hands. And so the decision to go to the cloud S I started in March 2013. By July of that year, I was already having dialogue with our board of directors about having to go to the cloud in orderto handle the data. >> Yeah, so you know, big data was supposed to be that bit flip that turned that. Oh, my God. I have so much data to Oh, yea, I can monetize and do things with their data. So give us a little bit of that, That data journey And what? That that you talk about the flywheel? The fact that you've got inside Finneran. >> Yeah. So we knew that we needed the way were running at that time on data warehouse appliances from E, M. C. And IBM. And which a data warehouse appliance. You go back 10 15 years. That was where big data was running. But those machines are vertically scalable, and when you hit the top of the scale, then you've got to buy another bigger one, which might not be available. So public cloud computing is all about horizontal scale at commodity prices to things that those those data data warehouse appliance didn't have. They were vertical and proprietary, inexpensive. And so the key thing was to come up to select the cloud vendor between Google, IBM, You know, the usual suspects and architect our applications properly so that we wouldn't be overly vendor dependent on the cloud provider and locked in if you will, and that we could have flexibility to use commodity software. So we standardized in conjunction with our move to the public cloud on open source software, which we continue today. So no proprietary software for the most part running in the cloud. And we were just very smart about architect ing our systems at that point in time to make sure that those opportunities prevailed. And the other thing I would say, this kind of the secret of our success Is it because we were such early adopters we were in the financial service industry and a regulator toe boots that we had engineering access to the cloud providers and the big, big date open source software vendors. So we actually had the engineers from eight of us and other firms coming in to help us learn how to do it, to do it right. And that's been part of our culture ever since. >> One thing that was, I guess a very welcome surprise is normally these keynotes tend to fall into almost reductive tropes where first, we're gonna have some Twitter for pet style start up talking about all the higher level stuff they're doing, and then we're gonna have a large, more serious company. Come in and talk about how we moved of'em from our data center into the cloud gay Everyone clap instead, there was it was very clear. You're using higher level, much higher level service is on top of the cloud provider. It's not just running the M somewhere else in the same way you would on premise. Was that a transitional step that you went through or did you effectively when you went all in, start leveraging those higher service is >> okay. It's a great question. And ah, differentiator for us versus a lot. A lot of the large organizations with a legacy footprint that would not be practical to rewrite. We had outsourced I t entirely in the nineties E T s and it was brought back in source in in house early in this decade. And so we had kind of a fresh, fresh environment. Fresh people, no legacy, really other than the data warehouse appliances. So we had a spring a springboard to rewrite our abs in an agile way to be fully cloud enabled. So we work with eight of us. We work with Cloudera. We work with port works with all the key vendors at that time and space to figure out how to write Ah wraps so they could take most advantage of what the cloud was offering at that time. And that continues to prevail today. >> That that's a great point because, you know so often it's that journey to cloud. But it's that application modernization, that journey. Right. So bring us in little inside there is. You know how it is. You know, what expertise did Finn Ra have there? I mean, you don't want to be building applications. It is the open stuff source. The things wasn't mature enough. How much did they have toe help work, you know, Would you call it? You know, collaboration? >> Yeah. The first year was hard because I would have, you know, every high performance database vendor, and I see a number of them here today. I'm sure they're paddling their AWS version now, but they had a a private, proprietary database version. They're saying if you want to handle the volumes that you're seeing and predicting you really need a proprietary, they wouldn't call it proprietary. But it was essentially ah, very unique solution point solution that would cause vendor dependency. And so and then and then my architects internally, we're saying, No way, Wanna go open source because that's where the innovation and evolution is gonna be fastest. And we're not gonna have vendor Lock in that decision that that took about a year to solidify. But once we went that way, we never looked back. So from that standpoint, that was a good bad, and it made sense. The other element of your question is, how How much of this did we do on our own, rely on vendors again? The kind of dirty little secret of our beginnings here is that we ll average the engineer, you know, So typically a firm would get the sales staff, right. We got the engineers we insisted on in orderto have them teach our engineers how to do these re architectures to do it right. Um and we use that because we're in the financial service industry as a regulator, right? So they viewed us as a reference herbal account that would be very valuable in their portfolio. So in many regards, that was way scratch each other's back. But ultimately, the point isn't that their engineers trained our engineers who trained other engineers. And so when I when I did the, uh um keynote at the reinvented 2016 sixteen one of my pillars of our success was way didn't rely overly on vendors. In the end, we trained 2016 1 5 to 600 of our own staff on how to do cloud architectures correctly. >> I think at this point it's very clear that you're something of an extreme outlier in that you integrate by the nature of what you do with very large financial institutions. And these historically have not been firms that have embraced the cloud with speed and enthusiasm that Fenner has. Have you found yourself as you're going in this all in on the cloud approach that you're having trouble getting some of those other larger financial firms to meet you there, or is that not really been a concern based upon fenders position with an ecosystem? >> Um, I would say that five years ago, very rare, I would say, You know, we've had a I made a conscious effort to be very loud in the process of conferences about our journey because it has helped us track talent. People are coming to work for us as a senior financial service. The regulator that wouldn't have considered it five years ago, and they're doing it because they want to be part of this experience that we're having, but it's a byproduct of being loud, and the press means that a lot of firms are saying, Well, look what Fender is doing in the cloud Let's go talk to them So we've had probably at this 50.200 firms that have come defender toe learn from our experience. We've got this two hour presentation that kind of goes through all the aspects of how to do it right, what, what to avoid, etcetera, etcetera. And, um, you know, I would say now the company's air coming into us almost universally believe it's the right direction. They're having trouble, whether it's political issues, technology dat, you name it for making the mo mentum that we've made. But unlike 45 years ago, all of them recognize that it's it's the direction to go. That's almost undisputed at this point. And you're opening comment. Yeah, we're very much an outlier. We've moved 97 plus percent of our APS 99 plus percent of our data. We are I mean, the only thing that hasn't really been moved to the cloud at this point our conscious decisions, because those applications that are gonna die on the vine in the data center or they don't make sense to move to the cloud for whatever reason. >> Okay, You've got almost all your data in the cloud and you're using open source technology. Is Cory said if I was listening to a traditional financial service company, you know, they're telling me all the reasons that for governance and compliance that they're not going to do it. So you know, why do you feel safe putting your your data in the cloud? >> Uh, well, we've looked at it. So, um, I spent my first year of Finn run 2013 early, 2014 but mostly 2013. Convincing our board of directors that moving our most critical applications to the public cloud was going to be no worse from the information security standpoint than what we're doing in our private data centers. That presentation ultimately made it to other regulators, major firms on the street industry, lobbyist groups like sifma nephi. AP got a lot of air time, and it basically made the point using logic and reasoning, that going to the cloud and doing it right not doing it wrong, but doing it right is at least is secure from a physical logical standpoint is what we were previously doing. And then we went down that route. I got the board approval in 2015. We started looking at it and realizing, Wait a minute, what we're doing here encrypting everything, using micro segmentation, we would never. And I aren't doing this in our private data center. It's more secure. And at that point in time, a lot of the analysts in our industry, like Gardner Forrester, started coming out with papers that basically said, Hey, wait a minute, this perception the cloud is not as safe is on Prem. That's wrong. And now we look at it like I can't imagine doing what we're doing now in a private data center. There's no scale. It's not a secure, etcetera, etcetera. >> And to some extent, when you're dealing with banks and start a perspective now and they say, Oh, we don't necessarily trust the cloud. Well, that's interesting. Your regulator does. In other cases, some tax authorities do. You provided tremendous value just by being as public as you have been that really starts taking the wind out of the sails of the old fear uncertainty and doubt. Arguments around cloud. >> Yeah, I mean, doubts around. It's not secure. I don't have control over it. If you do it right, those are those are manageable risks, I would argue. In some cases, you've got more risk not doing it. But I will caution everything needs to be on the condition that you've got to do it right. Sloppy migration in the cloud could make you less secure. So there there are principles that need to be followed as part of >> this. So Steve doing it right. You haven't been sitting still. One of the things that really caught my attention in the keynote was you said the last four years you've done three re architectures and what I want. Understand? You said each time you got a better price performance, you know, you do think so. How do you make sure you do it right? Yet have flexibility both in an architect standpoint, and, you know, don't you have to do a three year reserves intense for some of these? How do you make sure you have the flexibility to be able to take advantage of you? Said the innovation in automation. >> Yeah. Keep moving forward with. That's Ah, that's a deep technical question. So I'm gonna answer it simply and say that we've architected the software and hardware stack such. There's not a lot of co dependency between them, and that's natural. I t. One on one principle, but it's easier to do in the cloud, particularly within AWS, who kind of covers the whole stacks. You're not going to different vendors that aren't integrated. That helps a lot. But you also have architect it, right? And then once you do that and then you automate your software development life cycle process, it makes switching out anyone component of that stack pretty easy to do and highly automated, in some cases completely automated. And so when new service is our new versions of products, new classes of machines become available. We just slip him in, and the term I use this morning mark to market with Moore's Law. That's what we aspire to do to have the highest levels of price performance achievable at the time that it's made available. That wasn't possible previously because you would go by ah hardware kit and then you'd appreciate it for five years on your books at the end of those five years, it would get kind of have scale and reliability problems. And then you go spend tens of millions of dollars on a new kit and the whole cycle would start over again. That's not the case here. >> Machine learning something you've been dipping into. Tell us the impact, what that has and what you see. Going forward. >> It's early, but we're big believers in machine learning. And there's a lot of applications for at Venera in our various investigatory and regulatory functions. Um, again, it's early, but I'm a big believer that the that the computer stored scale, commodity costs in the public cloud could be tapped into and lever it to make Aye aye and machine learning. Achieve what everybody has been talking about it, hoping to achieve the last several decades. We're using it specifically right now in our surveillance is for market manipulation and fraud. So fraudsters coming in and manipulating prices in the stock market to take advantage of trading early days but very promising in terms of what it's delivered so far. >> Steve want to give you the final word. You know, your thank you. First of all for being vocal on this. It sounds like there's a lot of ways for people to understand and see. You know what Fenner has done and really be a you know, an early indicator. So, you know, give us a little bit. Look forward, you know what more? Where's Finn Ra going next on their journey. And what do you want to see more from, You know, Amazon and the ecosystem around them to make your life in life, your peers better. >> Yes. So some of the kind of challenges that Amazon is working with us and partnering Assan is getting Ah Maur, automated into regional fell over our our industries a little bit queasy about having everything run with a relatively tight proximity in the East Coast region. And while we replicate our data to the to the other East region, we think AIM or co production environment, like we have across the availability zones within the East, would be looked upon with Maur advocacy of that architecture. From a regulatory standpoint, that would be one another. One would be, um, one of the big objections to moving to a public cloud vendor like Amazon is the vendor dependency and so making sure that we're not overly technically dependent on them is something that I think is a shared responsibility. The view that you could go and run a single application across multiple cloud vendors. I don't think anybody has been able to successfully do that because of the differences between providers. You could run one application in one vendor and another application in another vendor. That's fine, but that doesn't really achieve the vendor dependency question and then going forward for Finn or I mean, riel beauty is if you architected your applications right without really doing any work at all, you're going to continuously get the benefits of price performance as they go forward. You're not kind of locked into a status quo, So even without doing much of any new work on our applications, we're gonna continue to get the benefits. That's probably outside of the elastic, massive scale that we take advantage of. That's probably the biggest benefit of this whole journey. >> Well, Steve Randall really appreciate >> it. >> Thank you so much for sharing the journey of All right for Cory cleanups to minimum back with lots more here from eight Summit in New York City. Thanks for watching the cue