Public Cloud Workload Repatriation

Auto-generated captions from YouTube, not hand-corrected, so names and technical terms may be imperfect. The video is authoritative.

>> All right, thanks for continuing with this really interesting journey we've been on with virtual events. I hope you engage with our experts in the chat. While this has been prerecorded, the experts are here to talk to you, unless you didn't participate day of, shame on you, but you'll still enjoy the content. Let's go around the panel with introductions. We have a star-studded panel. Let's start with Bobby and then work our way to Jo, Matt, and then Tim. Bobby, introduce yourself.

>> Hi Keith, I'm Bobby Allen. I'm CTO for Cloud General based out in Charlotte, North Carolina, which we like to call Silicon South. Thanks for having me. >> Hi, I am Jo Peterson. I'm the Vice President of Cloud and Security for Clarify360 and I'm visiting with you today from southern California. >> Hey, everybody, Matt Wallace. I'm the Chief Technology Officer at Faction and I'm joining you today from my basement in Denver. >> All right, and I'm Tim Crawford, CIO and Strategic Advisor at AVOA, joining you from southern California, as well.

>> All right, thanks for the introductions. Let's jump right into the conversation. Let's set some boundaries and this first question is for Tim. Tim, what's going on? Are we seeing mass exit from all the cloud providers, like is this cloud growth thing, a public cloud, is that real or is that fake and everyone is just leaving that? What is cloud repatriation? >> It's a great question, Keith, but let's be clear, it's not happening en masse. It is happening but it's not happening en masse.

What's more important is to understand the reasons why it's happening and this kind of comes back to the fundamentals of I think what we're going to talk about in this discussion, which is what are some of the challenges that people are having that's causing them to rethink moving their workloads or moving their applications from public cloud infrastructure back to their corporate data center or to even co-location or to another infrastructure. I would say it's not happening en masse, but it is happening and there are very good reasons why it is happening.

>> So, a question for the panel in general, is it an incrimination or a sign of bad management or strategy that companies are repatriating workloads? What are some of the drivers? Let's talk about that. >> So, Keith, I'll jump in there. I think that repatriation is happening for different reasons. Sometimes it happens because people didn't plan well, but I'm going to throw something out there for the panel to critique or poke holes in. I think a lot of the issue is because people don't understand the value of what they're running out there in the public cloud.

So, for example, here's one of the questions that comes to mind. As the expense of an application goes up, does the value of the application go up? And if you can't answer that question, here's another one to kind of pose is, should an application that does not have unlimited value be placed in a place that can have unlimited scale and spend? That's what I think a lot of corporations are wrestling with. >> I think, to that point, there's definitely a question of what value you expect to beget, right.

When you embark on a cloud project, there's some outcome that you think you're going to have, right, that drives the business case to go do it in the first place. I think there's a certain level of naivety on some organizations part, thinking that it's going to look different, that it's going to cost less, and it could be that they didn't begin their business case thinking about the savings you get from lighter touch operations or it could just be that they thought their bill was going to be X number of dollars and it turned out they didn't account for things like egress charges or access fees or the premium support they decided they needed or things of that nature, and by the time all those things got added together, it completely trashed their business case.

>> I guess the thing that I would add is the planning part. When they went to put the workload in the cloud, they maybe hadn't thought about the global impact of what was going to happen and by global impact, I mean the IT folks that did this hadn't really thought about, perhaps, data sovereignty issues, so they've all of a sudden got holdings in the EU or maybe they acquired a firm that was in the EU and now they've got to worry about how can I get this to work, (clears throat) pardon me, how can I get this to work in the EU because I've got all these constraints that I didn't have before.

So, as we were sort of talking offline a little bit, it's part of the planning and the maturation process, business happens, and then does that cloud strategy that they set forth really match what the business needs? >> Yeah, I think there are two aspects that I look at. One is you've got organizations that are comparing what they're doing in public cloud to what they were doing in a corporate data center and those are two completely different environments. I think that the narrative around cloud is cheaper has really kind of gotten us into trouble or that cloud is just another data center, that's gotten us into trouble from setting us off on the wrong mindset.

So, one dimension is don't think about your existing workload or existing application and moving it to cloud, just like you would move it to another data center. The second piece, and it was kind of something that Bobby touched on, is you have to think about the value aspect of this. A lot of folks look at what they're spending in cloud and say, "I'm spending $1 million a month in cloud services. " And the reality is you should be asking yourself the other dimension of that value equation, which is, okay, I'm spending $1 million a month but I'm actually making $5 million a month because I've done that.

So, great, that's a 5X uptick. The question shouldn't be at that point, hey, how do I reduce that $1 million of spend? The question should be how do I turn $1 million a month of spend into $100 million a month in spend because that would, in turn, have a 5X uptick on your value. And so, looking at that value equation on one dimension is important but also, equally important is looking at the back end piece of not comparing what you were doing traditionally with public cloud.

5 or $2 million in public cloud, therefore public cloud is more expensive and we need to repatriate, but before we get to that point, Jo, I wanted to probe a little bit more on one of the points you made. Data sovereignty is a interesting aspect of the public cloud because now, instantly, where I had barriers of entry to going into, let's say, the EU or to more restrictive governments, because I just couldn't deal facilities, now the cloud makes that available. How much of data sovereignty, IOT, et cetera, are you seeing as drivers for, if not repatriation, pauses in cloud strategy?

>> I wouldn't say that it's necessarily pauses but I think it really takes everybody in the business getting together and talking about what is important. So, everybody's got to be on the same page and the IT team shouldn't have to figure this out themselves. They need help from management, they need help from regulatory, they need help from legal to figure out if they're doing things correctly. I read that the China cyber security law, for example, requires companies to follow localization requirements for what the government calls important data but it's really hard to define what is important.

So, I feel badly sometimes and I feel like IT teams are trying to figure this out by themselves and that shouldn't be the case. >> Good cloud strategies definitely start with governance on some level and you can't leave it up to a cloud architect or your IT team to go and tell you what your cloud governance strategy ought to be, even in terms of how your strategy for creating multiple accounts and having them roll up from a building standpoint works, to what are the security requirements and who's allowed to create and who maintains a footprint or a view of the footprint resources in different regions.

Those are all important questions to answer and if you're just going to leave it up to chance as you embark upon lifting and shifting, before you answer those questions, it's going to be very difficult to have a good outcome. >> So, this is the CTO Advisor virtual event, so we're talking primarily to technical resources, but again, executive level technical resources. So, most of us in this room, in this virtual room, can go to a CIO, we can go to a business leader and have a one-on-one conversation and kind of have these thoughts, but let's think back to the architect and the CIO organization that doesn't have that bridge to the business.

What are they missing? It seems like a really big miss that I've spent $1 million going to public cloud and now I'm pulling back these resources. There's a business conversation that hadn't taken place to at least identify that this is a valuable thing to do and we should keep doing it or to identify this was too expensive and we need to pull back. >> I agree. Keith, I think a lot of the problem is that some of these things are done in silos.

The typical architect who has to figure out a cool way to do stuff in the cloud and make it cloud native and so forth, is not responsible or equipped to figure out things like total cost of ownership or licensing or how to consume it so things are done in a good way. For example, we talk about architects who are really good at moving from scale out to scale up. We don't emphasize what about scale in and scale down. Architects don't get recognized for saving money.

They don't get recognized for being efficient. They get recognized for coming up with designs that can scale to a million customers, even though we might not have 1,000 of them yet using that application. >> So, the wrong incentives, I'm hearing, architects specifically, are being given. How do we start to change that? Is this a skills gap? Where's the core problem? I'm an engineer by trade, so I'm trying to get to a root cause analysis. Why are we having this problem to begin with and how do we solve it?

>> So, let me jump in on this, Keith. You know, I think the first step is we should be asking ourselves why are we even having this conversation in the first place? If you're thinking about moving to cloud, why are you moving to cloud? If you're looking at is as, hey, it's going to save us money or it has a mandate tied to it from my executive team that we have to move as much as possible to cloud, you have to understand the reasons why you're moving to cloud and then start to kind of pick that apart and make sure that you're making the right decisions, in terms of what moves to cloud and how it moves to cloud.

This is where things like lift and shift, really start to show the ugly truth of taking what you were doing in your traditional data center and just simply moving it to cloud, because I had a mandate to move it to cloud. That's not going to fly. You're going to run into significant issues and the first thing you're going to see is cost as a problem. And so, I think it's important, especially for architects, to step back and say, "Okay, I heard the mandate.

"I heard the conversation. "I've heard the narrative. " And kind of to Jo's point, I do think that it's a team sport. It does require input and engagement from other parts of the organization. We have to break down these silos because cloud does start to venture into other spaces. " It's not that simple. There's a lot more at stake here that we have to consider and that's the piece I think that's missing. >> So, Keith, I want to piggyback on something that Tim said because architects are often working at an application level, to Tim's point, that's where the decisions are made, but the financials are often kept at a data center level or a server level or an infrastructure level.

So, people are talking past each other. I'm coming up with the design for an application but I can't tell you what it costs today, so if I say, if we move this to cloud and make it cloud native, I'm going to save 20% on the app, I have no idea what that app costs today. The average enterprise CIO cannot give you a TCO of an average application in their data center so they can move it all or they can move none of it or what ends up happening is the individual line of business will take their apps to the cloud because they want more transparency around the costing.

So, we're talking past each other because the financials and the technical architectures are on different levels. >> And let me just add another piece to that, Bobby. Actually, two components, which is around cost. The CIO, and I know we're focusing on the technical architect but to exemplify that point, the CIO typically doesn't have responsibility for the real estate and even electrical costs within the data center. There might be a pass down or pass through cost that comes in to the IT organization but they don't necessarily get all of that cost, so there's a visibility problem around the data center, in terms of its true cost.

When you move to cloud, you're now picking up all of those costs, regardless. It almost goes back to an old saying, kind of dates me a little bit, but if you truly want to know what something costs, outsource it, because at the end of the day, you will truly figure out what it's going to cost your organization to run that application. " But, of course, you know that their organization pays for data center and that can extend to some very strange places, like occasionally you'll see people who are doing this for either a function, like disaster recovery, or an application in particular, but they don't even pay for the staff that maintains it or the people who design it.

I think there's something interesting, too, about the question of architecture because there is this delineation that I have in my mind between the function of a cloud architect, which, to a certain extent, can take what you want to do in the cloud and design your cloud consumption and your use of cloud services to fit that need, and then the enterprise architect, right, who is much more, I think, the tip of the spear for understanding who the stakeholders are in the business and understanding what outcomes you want to get and understand cross-functionally how all the teams have to work together to pull in viewpoints like what is the financial viewpoint, what is the security and compliance viewpoint.

And, if you don't have that function in your organization, you can have a sort of random outcome, I guess, going to the cloud, because you are leaving so many considerations out. And to Tim's point, it's not just a question of lift and shift. You're not merely mapping workloads into the cloud equivalent because if you do, you're missing out on all of those other very important aspects of that transformation. >> Wow, you guys gave me two really big topics to talk about and I hope we have enough time to cover them in depth in both areas.

One, I need to be able to identify the scope of my cloud migration. On the flip side of that, once I've identified the scope and I've put it to test, I need to understand what I need to pull back into the data center and what I need to push the pedal to the floor and go forward with on public cloud, but in order to do that, I need the skillset within my organization to even identify these opportunities and challenges. Talk to me about the profile of the types of people that I need and then the organization of where they need to sit inside of my organization.

>> I think an enterprise architect is definitely very much one of those key skillsets because at the start of a cloud project, you are definitely going to have to address things holistically, right. So, you're going to have to have somebody who is familiar with looking at the financial point of view, who can actually go to stakeholders and understand what's the outcome that drives the project, what is the value that we get from it and ask what are the costs that go into it, how do those costs change over time, not just specifically for the use of cloud resources but questions of people who have to be pulled in the soft resources from within the organization and what you take and add to the projects from your internal resources.

They also have to have the technical resources that you understand what are the possibilities for moving a workload to the cloud because certainly some people do lift and shift things, it's not always the wrong choice necessarily, but you have to understand, you're not necessarily getting the true value of cloud. If you can do things like transform the application, replatform it, in whole or in part, make some pieces serverless, move certain application components, like a database, into something that's managed, maybe you can realize bigger gains, and yet, there's complexity in that, too, where cost comes into play between those selections.

Is there an ability to get rid of this waste? We all know that if you size something for your old data center, you have to size for that high water mark of consumption. Moving to the cloud, you have that ability to scale things down so you're not usually using as many resources and you can scale up but you have to ask questions of do you have the skillset to set that up, are you going to be successful scaling up and down, and how much will that save you.

All this complexity, obviously, and ignoring that complexity is what leads to the negative outcome when those things aren't considered and then you get surprised on the backside. Although, doing what I say, even though we're talking about repatriation so far that happens because people move to the cloud and they didn't get the outcome they want, there is a whole other side of this where smart technologists in great organizations who move to the cloud and then spend tens or even hundreds of millions, very high profile tech companies, then repatriate for other reasons, so I'll table that but it's worth talking about, too, because there are other reasons to come out, other than just it didn't work out like we expected.

>> And I think that's a maturation question and Bobby, I want to drill down on this skillset gap a little bit, specific with you, and I think you might, hopefully, be able to clarify some of this for us. In my mind, as just an engineer, VMWare in my data center is VMWare in Google's data center is VMWare in AWS data center. This seems like just the back of the napkin math problem. Is it just the math that I need to be concerned with or specifically, to some of Matt's points, what are some of the a-ha moments that you've seen clients realize once they've actually done the work?

>> That's a great question, Keith. To compare that, to kind of play this back, so I can run VMWare on prem, I can run VMWare off prem, and there are a couple things that are interesting about that, so one, if I have a level of discipline or a lack of discipline in the data center, that lack of discipline hurts me a lot more in the public cloud. So, I just gave my teenager a set of car keys and now they can do a lot more damage.

So, VMWare in the public cloud can connect to all sorts of other resources and things that can get me in a lot of trouble and so, number one, the math is challenging because typically VMWare in the cloud is a big bucket of software-defined resources that I often can't break down and compare the native services, but back to the prior point, I can connect to all sorts of other things now. I can provision storage and services and software and other things. In my VMWare data center on prem, there's only so much that my costs can get to.

There is a ceiling that's kind of fixed, but again, in the public cloud, I've now let my ideas and my lack of discipline run wild and I think that's part of what scares people. So, if I'm going to go to cloud, I'm going to take the VMWare tack, so to speak, to public cloud but then now give it access to all of these other things, I think that's why a lot of CIOs have been giving pause about that. I need to refactor more of my culture, than just take existing paradigms on prem and move 'em off prem.

I've got to change some of the behaviors to make sure we're being more efficient, resizing resources, and thinking about why we're going what we're doing. >> So, let's talk a little bit about scope and this is getting to, I think, the maturity conversation. So, I've gone to public cloud and I've realized, wow, there's something that I didn't account for, whether it's power, people, speed, agility, et cetera, and we have a problem. And the problem usually surfaces in a bill. There's an unexpected bill that I've received.

I've gone to VMC on the AWS and I expected the VMWare cloud on AWS bill to be X and it is actually X but to Bobby's point, wow, now I'm leveraging RDS, I'm leveraging all these other solutions that I didn't expect. We need to pull the plug on cloud and repatriate, but before we do that, what's the conversation that needs to happen? >> I think that the conversation is on what does the business actually need. So, Keith, I'm going to kind of mix this question with the prior question that you talked about, in terms of skillsets.

We need people that can dream about what's possible but then also balance that with what's practical. So, if you have a white piece of paper, yes I need to fix the car but don't put a $10,000 transmission into a $2,000 car. And some of the times, what we're doing is we're gold-plating applications that are close to end of life, don't have a lot of value for the business, or about to get retired or killed off anyway, and so, we're not being practical. So, yes, dream.

If I put my project manager hat on, Keith, this is about being able to balance unconstrained requirements with constrained requirements. Dream like you have a white piece of paper, but then act like the budget is coming out of your check. That's what's not happening. That balance is what a lot of teams and people don't have in place right now to make sure they're juxtaposing those two competing priorities. That's what I'm seeing. >> Since you've asked this skillset question, I just really want to say, this is a really incredibly rare combination and because I've had teams reported to me that had project management under their purview, product development, architecture, I will say that the number of folks out there who kind of bring together an architect's mind, thinking about how design works and who stakeholders are, people who bring product management to the table to ask what you're trying to accomplish and who the end value goes to and what the purpose is, who have the technical skills to actually answer deep technical questions about how you implement things, but then can also sit down with something like a spreadsheet and do math on how the financial costs work out, just incredibly difficult to blend those and I think, in the industry, as we migrate more towards cloud models, we're going to have to be on the hunt for people that have a different skillset in the same way that 10 years ago, we were telling people who were administering network devices, hey, you're going to have to get better at APIs in the future because so much of this is going to be API driven.

We also have to be telling technical people you have to be comfortable with a spreadsheet so you can show how something that you designed works out at scale. We have to get those soft skills into the process. >> I wanted to say something about what these gentlemen were saying and I want to take a step back because the cloud strategy that we chose five years ago, whatever that was, I think we, as resources to IT organizations, need to say to them, is that still working?

" So, everybody needs to get on the same page. Maybe the business has grown. Maybe there have been acquisitions made, but what worked for you five years ago, the question you need to ask is, is it working today, before you just go try to figure out how to just save money with what you've got going on. That's not really the problem. >> Yeah, that's a really great point, Jo, and I would exemplify that by saying, even what you had planned to do six months ago, you really have to go back and rethink that.

But, there's another dimension to this that we have to think about, as well, which is when you move that application out of your corporate data center to public cloud, you still have that footprint in your corporate data center. You still have those costs in your corporate date center. So, you haven't saved anything yet on the corporate data center side of the equation. So, it's not truly an apples to apples comparison and this is where, just one of many examples, of where people tend to get tripped up, is it's not an ability to be able to say, hey, when I move this application across, and if I did that planning, to Jo's point, if I did that planning five years ago and now I'm finally getting to move these other pieces, part of this larger project, I mean, God forbid, if you're doing a five cloud project, that could be problematic in its own right, but larger projects in large enterprise are still multi-year ventures and you have to think about all of these different components coming together and I think that just exemplifies the earlier point that it's not just the architect, it's not just the CIO, it's not just the cloud administrator or system administrator, all of these different personas have to come together and also, you have to think about some of those soft skills that have to be layered in here.

This is not just a technology problem. >> So, this is not just a technology problem and repatriation is also not just a technology decision. So, I'd like to turn the conversation a little bit more to Tim and Jo, because I think this is more of your level of expertise. How do we have that difficult conversation? Like, repatriation for some things, to Matt and Bobby's points, sometimes the application just isn't the right fit for public cloud or Matt hinted to, we may have gotten to a scale where public cloud was the right thing five years ago for this application, but this application is static and we can probably do it cheaper and better ourselves in a private data center.

How do we have that difficult perception conversation that repatriation is not necessarily a bad thing? >> I think there are a couple of dynamics there. You're right, scale is one component but I think we have to be careful because scale for an enterprise is very different than scale for a web-scale company. If I were to try and simplify this a bit, a web-scale company has four applications but at massive scale. An enterprise has 4,000 applications but at very small scale. And so, scale is one piece that you have to ask yourself what are the alternatives and then do an apples to apples comparison of that.

There also might be other aspects, as Jo mentioned earlier, kind of picking up on the point about regulatory and compliance and sovereignty issues and privacy issues, which are in constant flux around the globe. S. And so there might be changes to legal frameworks and ramifications that you have to consider, too. So, there could be a lot of different dynamics, (audio cuts out) are changing, where your customers are coming from, your supply chain, your business operations, all of those are currently in flux and with the pandemic and economic crisis that we're dealing with right now, that statement is X fold.

We have to rethink how we're architecting from the ground up because the rules of the game have changed. It's not a matter of someone played a chess piece in a different direction and I have to think about how to move my piece, the board changed and we have to figure out how to play within that new chess board. >> I think all that's spot on, Tim. And I don't ever want to call anybody's baby ugly, right, but there are people's emotions and people have stakes in some of the designs that they've done and one of the advantages of working with private equity is it's cleaner, right.

Everybody understands it is about value creation and what I mean by that is I go in and we look at the spend cube for that hyperscaler and we go take it right back to the architecture, Tim, just like you said. " You have a one-on-one ratio between, you built your cloud like you built you data center and you don't need to do it that way, so let's rethink that. " And then we can really have a conversation about what matters to the business, as soon as we get that baseline right.

>> Yeah, you know, Jo, I want to kind of bridge off a point that you made there, which is talking about the baby being ugly. I think that's absolutely important for us to talk about and what I mean by that, or how I'm thinking about it is you made decisions to move to public cloud or to do something with an application based on a certain set of assumptions or certain set of criteria that drove that decision. It is what it is. " That was made at a certain point in time.

You're now at a different point in time with a different set of inputs and now you have to rethink, okay, was that decision really the right decision to make? Maybe it was back then, now we're at a different point. Now what's the decision we should be making? So, I just want to support what you're saying there about just being careful that we don't necessarily ostracize decisions that have been made in the past, but rather, times have changed, how can our decisions change to be able to accommodate that?

>> Let's leave the last set of questions or last question off on a semi-technical note. I've made the decision that some level of repatriation is the right move to make, but I've gotten out of the data center. Do I have to go back and rebuild a data center to rightsize my locations and workloads? >> I don't think you do, Keith. I think it's a great question that you asked. Number one, there are what I'll call off-prem kind of semi-private providers, co-los, et cetera.

There are other options. I won't mention specific vendors but there are people that do that, right. It doesn't have to be in a hyperscaler. It doesn't have to be in your data center. There's somewhere else it can go, but I think the other part of that is that public cloud keep, in many ways, was an opportunity, or an excuse, for people to innovate and so, now that we're going to move it back somewhere else, one of the things that comes to mind, and I've said this before, when we were comparing private cloud and public cloud, I questioned did you have a private cloud or did you have virtual light, chewing gum and duct tape.

So, maybe you can refactor what you had going on in a private location and be more efficient now. Looking at HCI versus CI or something like that, so anytime you're looking at a move, just like if we were moving in real estate, it's a chance to declutter and to get rid of those ideas that don't make sense, that don't make sense to carry with us to the next venue. >> Yeah, I mean, I'll just piggyback on what you're saying, Bobby. 15 years ago, I was leveraging other people's data centers.

It wasn't cloud, it was (audio cuts out) facilities. It was rented infrastructure and just to be clear, I'm not talking about outsourcing. Outsourcing I did, as well, 20 plus years ago, but what I'm talking about is where I took my BMs and moved them to someone else's infrastructure and was able to run it on someone else's infrastructure and so, I paid a fee, based on the portion of that infrastructure, that shared infrastructure that I was using. If I needed dedicated infrastructure, it was available.

If I just needed a cage to be able to put my servers and infrastructure into, that was available as co-location. So, I think there are a lot of different mature solutions that have existed for a long period of time. I mean, 10, 15 yr, that's eons in technology speak, but I've done it, done it very successfully. Those options still exist today. So, I don't think cloud or your corporate data center are the only two options. There's a myriad of different options in the middle.

>> All right, so, if you're watching this panel presentation after it aired live, you've missed a dynamic conversation in the chatroom. Our experts really got put to test on some of the answers and a little bit tangents went on. I'm sure of it. I'm predicting into the future. Watch out for the next CTO Advisor virtual event. We'll do this again, not quite sure when, but you know what, the same way that you found the event, you'll find it the second time.

Thanks to our sponsors and this conversation about co-location, oddly enough, we have it on the agenda. John Frayman from Frayman IT Services, who helped build the CTO Advisor hybrid infrastructure and our selection of the co-location, will talk about all the factors, or some of the critical factors, in selecting the data center. He's on the agenda for three o'clock this afternoon Central. Stay tuned for that one. Hope you've enjoyed the virtual event. Make sure to fill out the survey and help us improve the event.

On behalf of my entire expert panel, thank you for taking out the time. Talk to you next session. (electronic sizzle)