Podcast transcript: The importance of committing to a definitive cloud strategy
44 min approx | 13 July 2021
Simon Hobbs
This EY podcast is about the need to commit to a definitive cloud strategy, ideas for leadership from EY, offering clients the expertise they need to harness Microsoft Azure. I'm your host Simon Hobbs in California. Organisations will soon be spending $1 trillion a year on the cloud, according to IDC. Choosing the correct cloud strategy is obviously critical, with far reaching consequences. But it's a challenging decision. Because there's no one-size-fits-all. Some businesses will go all in with a single provider. Others will drive for a multi-cloud solution to avoid vendor lock-in. But according to the two thought leaders you're about to meet, what you do not want to do is to attempt to plough a middle path, because that will likely deliver the worst of both worlds. More importantly, they believe the middle ground can trigger paralysis, organisations left oscillating or vacillating between the two poles. This podcast is about how to craft a concrete cloud strategy and why, in order to win, you should explicitly publish that agreed plan. Please remember conversations during this EY podcast should not be relied upon as accounting, tax, legal, investment, or other professional advice. Listeners must consult their own advisors.
Joining us now from Seattle, Rick Claus, who from within the Azure engineering team leads Microsoft's cloud advocacy efforts to the ops community around the world. Rick, I really appreciate you sparing the time. Thank you very much for joining us.
Rick Claus
Thanks for having me, Simon, great to be here.
Hobbs
And from New York. Tim Rehac joins us, who leads EY’s cloud strategy in the Americas. Tim, I really appreciate you helping us make this happen as well. Thank you.
Tim Rehac
My pleasure. Great to be here.
Hobbs
Okay, Tim, let's kick off by addressing the elephant in the room, you know. COVID-19, I think as we probably all know, tested every aspect of an organisation, not just its technology, but its supply chains, its operations and, and latterly even its culture. What is the pandemic meant for you doing your job on cloud competency within EY?
Rehac
Sure, yeah. COVID definitely stressed our internal collaboration tools, and had we been on prem, I think we would have been in for a world of hurt. But luckily, we had been on Microsoft Teams for, I guess, a year and a half now or so. So when COVID came and our employees work from home, it was really pretty seamless. And we've seen the same things really with our clients that those that had made good progress on their cloud journey, were much better able to respond quickly to what was changing in the marketplace. There's a state government we do some work for that, their unemployment system was able to keep up with dramatic unemployment claims demands early on in COVID. And we saw, you know, many other states not be able to do that and the key difference was that their unemployment system had been migrated to the cloud, and was able to scale, you know, very, very quickly. And, you know, honestly, I think it was about 10 X to normal compute power that they were able to deliver on demand. So, yeah, we've known all along that agility is one of the key benefits from Cloud. And I think COVID, as you said, really proved that, you know, once again, for everybody.
Hobbs
Well, three months into lockdown, you wrote a blog about those extreme and sudden shifts in demands, you know, scaling up and scaling down, which you're talking about. I guess, if anything, that reproved the case for the cloud, if proof were needed.
Rehac
Yeah. And I think, you know, it's interesting, right, as EY we talk to CIOs and CFOs, and CEOs, for that matter, but, you know, CFOs have always kind of liked the concept of being able to link, you know, underlying IT costs to the revenue stream. So, you know, we've had retail clients that saw their digital business grow 40, 50, 60%. And, you know, their cloud costs went up, probably not as fast as their revenue did. But they were able to scale and achieve those revenue gains, because they were in the cloud. And then we've got other clients that were severely disrupted. And, you know, their revenues went dramatically down. But their cloud costs also went dramatically down. Wasn't anything in particular they had to do; they just were seeing less demand for compute, which was powering their transactions. And that, you know, dramatically brought down the cost of the cloud for them. So in both, you know, increasing market and a decreasing market, the ability to tie, sort of underlying costs directly to revenue is something that most CFOs really respond to. And most CIOs, I think, are happy to be able to enable.
Hobbs
You know, Rick, the other major dynamic that I think we should mention that I believe, from what I can gather, occurred during COVID-19 is a simultaneous explosion in the range of services that are being offered by engineering teams like yours at Microsoft in the cloud, not least, artificial intelligence and machine learning. I mean, that would be a potential game changer at any time. But it seems to have occurred in the middle of COVID. Correct?
Rick Claus
Well, I think what you saw was actually as just kind of like what Tim mentioned, the proof is in the pudding, the unfortunate circumstances around the heavy stressors of a worldwide pandemic like COVID-19 really forced a lot of different organisations, including Microsoft, to go through and truly live what we've always been saying about agility using cloud as one of the ways to get there. This actually gave Microsoft a very large customer base that was actively using these technologies in a much higher intensity way, and we were able to determine certain faults and certain tweaks that we had publicly talked about. A great example, like we talked about Microsoft Teams as an example, for collaboration for tools that Microsoft and EY has used – we actually went down like any other service provider with an issue of capacity. And we actually tweaked behind the scenes, things within the code itself, to make it so that we had more capacity to handle more customers at such a rapid pace, something as simple as the ‘dot, dot dot’, that someone is typing as an example. We turned that down or completely off for a period of time, just to be able to give more processing cycles to the rest of that particular software-based solution for collaboration that our customers were using, so that we could onboard more customers. So, the volume is there, the technology was there. And even we embraced a lot of cloud concepts, because obviously, we're a cloud provider, to be able to maximise the return on the processing fire that we had.
Hobbs
Tim, your response within EY again during COVID-19 was to become the first of the big four to set up dedicated teams, to help your clients develop the capabilities that they then need to harness what Rick is offering over at Microsoft. Why did you decide to do that? And how big a funnel is that for Rick?
Rehac
The key, I think, differentiator for our clients out there today is how quickly can they learn, right, and their organisations learn, and then take advantage of the new technology to create a market opportunity. And so you know, Microsoft is doing all this great engineering, but it doesn't just, you know, magically then translate into all of the different customers. So they lean on EY to work with Microsoft very closely, understand exactly what Microsoft is working on that's going to be available, you know, in three months, in six months and nine months, and then help them better understand and take advantage of that roadmap.
Hobbs
Talk us through the speed at which you observe different industries moving, I'm thinking particularly on AI and machine learning, but I mean, generally across the board as far as cloud is concerned.
Rehac
Sure yeah. During COVID, particularly and probably even before, right, there was a, you know, a dramatic shift towards cloud computing and digital transformation in consumer product and retail, right. You know, the move away a bit from brick-and-mortar to multi-channel and online channels. Certainly, you know, absolutely killing it right now in that industry. Healthcare going pretty quick. Financial Services, kind of, interestingly, I would say were late adopters to cloud and predominantly because they had security and particularly compliance issues that were a challenge for them early on. But the shift has been dramatic over the last several years and financial services right now is adopting cloud at a very, very rapid pace. And then, you know, you have some traditional industries like utilities that move at a slightly slower pace, right. So they are absolutely all, you know, on the cloud journey, but they may be, you know, at step one or step two, and they certainly have, you know, longer investment cycles, and it takes a little bit longer for them to dramatically change their workforce to take advantage of some of these technologies.
Hobbs
Rick, you make a fascinating point that businesses coming into COVID-19 that had already made the forward-looking cloud investments could obviously harness the agility that we're speaking about. But for many clients, you say it actually slowed migration to the cloud because of this absolute imperative, as you put it, to simply keep the lights on.
Claus
Yeah, we've seen customers that have gone through and have already made investments in cloud technologies. They ramped some of those up. They had customers who had not made investments as of yet, and they very rapidly made the switch over to use some different resources inside of clouds, like Microsoft inside of Azure, as well. The interesting part is, and this is something that Tim and I talked about many times, with regards to when you are in a situation, you have to choose the right solution that's going to work for you and your user base. And so for some, it might mean you're going to need to go in and kind of shore up and fix some stuff on premises, but then take advantage of some hybrid capabilities inside of the cloud. Others are going to identify individual workloads that make total sense, they can't scale on premises, they can scale inside of a cloud environment, just from the sheer factor of machine sizes. And they can migrate lock, stock, and barrel, that whole chunk of a workload up inside of a hyperscale Cloud like Microsoft Azure. And then scale those sizes as required as Tim's blog post pointed out, bring them down when they're not required to be able to reduce the cost. The biggest issue really is whether or not they're going the next step after moving workloads, after examining workloads to move, and are they taking advantage of all they can to recoup the benefits of using cloud beyond the simple first step, the bright shiny thing, the sizing and the agility of turning stuff on and turning stuff off, those value-add services where they actually get the most benefit.
Hobbs
I started this conversation by saying that you guys are very worried about people being in the middle ground. And that can cause paralysis and the worst of both worlds. Are you saying that as a result of COVID actually there are more companies, multinationals in your case, that by default, by the hybrid nature of what they were doing ended up in that middle ground, they end up in a in an area that may be potentially dangerous for them, Rick?
Claus
I'll clarify a bit, it's not necessarily the middle ground, that they're stuck on premises or there's they're stuck inside of a hybrid world. It's more so that they're not making a clear choice, they're reactively going through, and just simply choosing to move something and then leave it and not touch it after the fact. That's the paralysis, you can't just simply move or choose a strategic workload, say this is going to go to a cloud environment, take advantage of some agility, or some a new hybrid adaption between that particular workload with on premises in there, that's not the paralysis that we're concerned about. It's the not re-examining how that particular workload is working, and how it can better be tweaked, refined, reimagined, re envisioned, re-engineered to take advantage fully of all those different cloud resources. Or that they choose to go and use the best of this cloud provider, the best of that cloud provider, the best of the other cloud provider, have the best of on premises and end up with a very complex and overly complex solution, thinking that they're going to be in a better situation, being very mindful of how to leverage the cloud technologies and take advantage of what makes the most sense for your workload, is where the ultimate place I'm hoping customers go.
Hobbs
Tim, in your experience, why do people struggle with the creation of a definitive cloud strategy?
Rehac
In practice I think it's a combination of things. One, you know, many of our clients when they first created their cloud strategy didn't have a tonne of cloud experience. So they're making these really long range, impactful decisions, before they actually have the experience they need to make them. And obviously, you know, as EY we do our best to advise them and counsel them. But you know, ultimately, it is our clients’ decision. And ultimately, early on, I think for a lot of them, they sort of lacked that experience and the understanding of the implications of all those decisions. I think, second, you know, there are a number of really sort of intertwined decisions that they're being asked to make. And you often have multiple camps within, you know, these large enterprises, and sometimes the power shifts over time, right. So if you don't have wide consensus on a single strategy, there is always that opportunity for those folks who felt they lost out on the first go round to try to re litigate it. And, you know, open up the question again and again. So we certainly feel strongly that, you know, your cloud strategy needs to be evergreen and adopt and adapt as long as you go. But at the same time, you know, if you're constantly reassessing those decisions you've already made, or those decisions are being questioned by folks that have decision rights further down in the organisation, it can lead you to a bad place. And, you know, ultimately, the worst end case scenario is a random placement of workloads in multiple clouds without a strategy and a plan upfront.
Hobbs
Rick, you're nodding furiously there.
Claus
No, it's just that Tim is absolutely capturing it right there. It's that your cloud strategy doesn't mean that it all has to be on the cloud. Your cloud strategy is the best for your workload. But you have to commit to one and make sure everyone clearly understands it. Examples that Tim brought up, the whole concept of going with a cloud first strategy, that is the Evergreen project. So new projects coming into being at customer sites, new creations of line of business apps, or internal apps or solutions, it's obvious that using a cloud solution is a very quick way to prototype, test it out, refine it, make sure that it works, have an agile approach to it, and then meets the customers’ needs, fantastic. The longer more complex designs of migrating workloads up and out of an area because of a data centre closure or because of a leased hardware that's going to disappear or something like that, those are much more complex. And a valid strategy could be that it's going to be hybrid for these portions. And it's going to be cloud native for these other portions of that one particular workload. But having that strategy and not, as you mentioned, oscillating between paralysis and decisions, is what you're ultimately trying to do with the cloud strategy. And as Tim points out, as well, not necessarily having: let's use everything, let's used best in breed, let's just focus on one, let's just go on prem. That is where you end up in trouble. Because it's not well thought out and not well adapted for the overall decision maker flow.
Hobbs
I just want to take a little bit of a step back and explain what the two basic strategies are. Just explain the option of going all in with a single provider.
Rehac
Sure yeah. So for some of our clients, they say that, yeah, we're going to pick one hyperscaler. And, you know, we're going to try to get most of our workloads there. And for large enterprises, actually, they all end up at least a little bit multi cloud, but they might end up 90%, you know, in a single hyperscaler. And the good news there, right, is that they then have a less complex environment, they have a less complex skills environment, right, because their people can focus on one set of skills and one set of services. You know, Rick could probably tell you better, but Microsoft and the other hyperscalers are releasing, you know, 1000s of services per year. So if I'm in a multi cloud world, I've got to keep track of how many times, 1000s, right, so being able to pick one, go deep with skills, reduces complexity. The bad news, obviously, is you are a bit locked into that vendor, you need to make that decision to say, look, this is my partner, I want to be close to this company, I feel good about their direction, I know that they're going to be in business in five years, in 10 years, I'm not worried about, you know, relying too much on them. So I'm willing to get locked in with this vendor. And you know, if I'm willing to do that, then I get back quite a bit on, you know, simplicity and lower cost to operate.
Hobbs
Rick, I guess as a vendor that that's the option you love at Microsoft, provided they come to you?
Claus
Well, what I will say is that all the hyperscale cloud providers are doing their best to make sure that we're using native tools for the different services that are available. So for instance, if you're going to be doing some of the more advanced stuff with Kubernetes services, which is the buzzword du jour, or we're going to make sure that we're using a CNCF version of Kubernetes services that all the regular tools are going to work with. And other cloud providers should also be doing this as well, to try to limit some of the, not necessarily limit the lock in but simply limit the skill set lock in that you have to have by only knowing how one cloud provider does it versus the other cloud provider while using an industry norm of using something like containerized services. But Tim is bang on with regards to the skill set that's there. And required investments, when you understand how for instance, is the entry point for a lot of cloud solutions works within Azure, it's going to be different than how it works within hyperscale provider x, whichever the x happens to be, they have their own way of how you manage and work and provision and tune and tweak and we use the AI as Infrastructure as a service virtual machines inside of their world, those don't translate between the other and requires a very specialised skill set. And we try our best to minimise the differences for the skill set requirements to make it so that customers have choice.
Hobbs
Tim just for the sake of completeness, just run us through that second basic cloud option, being multi cloud, and just, I mean, for people who this subject is new to just what why did vendor lock in become so scary?
Rehac
Yeah. You know, I think to be fair, in the IT industry, right, we've seen before when a single vendor gets too much power in the industry, and we've got a few examples of that certainly going back. So I think that you know, if executives are concerned about doing that. I think, you know, in my mind the fact that there are you know, two hyperscalers that have terminal market share and a third that is growing very quickly. And, you know, actually internationally a fourth and a fifth that, you know, have some traction as well, really, you know, makes that less of a concern. But that concern is certainly out there. So yeah, some clients say, look, you know, we want to be 50-50, or we want to be at 20. In, you know, hyperscaler A, and 20% in hyperscaler B, and we're going to do that purposefully and upfront. And not only that, usually, they then say, also, look we don't want to use too many paths services, from, you know, either of the clouds, because that can tend to lock us in, and how Microsoft operates a database, you know, as a platform is, is different than other hyperscaler. Right? So we tend to avoid more of the past stuff, we tend to do things more like in Kubernetes, for instance, so I could potentially move workloads back and forth from cloud to cloud. And, you know, the goodness there is I avoid vendor lock in, the goodness is I can, you know, take advantage if I believe that hyperscaler B has the best AI and machine learning right now I can take advantage of that. The bad news is I do buy some more complexity from skills perspective, I buy more operational complexity. And ultimately, I've got to be a little bit smarter with my workload placement. We have seen some clients that sort of randomly dispersed their workloads between two or more hyperscalers. And then they spend an awful lot of time moving data back and forth. You know, there's the effort involved. And there's also cost, egress costs, right, from coming out of the cloud. So if I'm, you know, moving a lot of transactional data back and forth between multiple clouds, all of a sudden, that can start to get expensive.
Hobbs
Before we talk about the middle path, and why it gives us difficulties. I mean, Rick, are there examples of the two polar options that you would cite as being great examples of when it works, it works really well?
Claus
We've developed some tooling that allows us to go through and enable customers that do go down that multi cloud path. As an example, one of the things that we've done is we've made a heavy investment over the last year and a half in a technology that we're calling Microsoft Azure Ark. And Azure Ark is basically at a very simplified level, the ability to go in and to receive and take commands and policy and apply it down to different workloads for how people should be accessing content can take data and logs and analytics and performance data, centralise it up inside of one spot, to be able to do large scale analysis on that particular data. And basically have a one pane of glass for how you would manage that particular workload of an IS workload or Kubernetes workload in someone else's cloud environment, as well as the one that's inside of Azure, and even as the one that maybe you're developing on, on premises too. And you have that one pane of glass to bring all that data together to be able to analyse it and to look at it, and at the same time typically go off and manage it to say you can or you cannot deploy in this area based on what groups you belong to, based on where you go to. So you don't we're building the tooling necessary that's there to make it so customers can be successful if they find themselves inside this multi cloud environment. And if that's the design that they purposely chosen to go down towards.
Hobbs
Let's talk about people wanting to find a middle path and not wishing to favour either of the two polar options. Tim, I think even you would admit that oftentimes, ploughing a middle path can succeed. I mean, this is tradition for a lot of you guys in your community, isn't it?
Rehac
Yeah, for sure. And I do think, you know, there are many examples, right, where the sort of middle path between the two strategies makes the most sense. But in the cloud space, what we see happening is, you know, clients that end up, you know, essentially in multi cloud, but that wasn't their strategy, have all the complexity and the skills challenges, what they also ended up with is a fair amount of vendor lock in, because they didn't do it strategically. And then they also don't spend enough time thinking about which workloads go where. So instead of having, you know, a specific data domain in a single, hyperscaler, so that the data movement is eased, they end up with one HR application in hyperscaler A and another in hyperscaler B. And, you know, they end up with the data movement challenges anyways, right? So, you know, they miss out on the ease and simplicity of, you know, a single or, you know, a strong majority 90% in one cloud, but then they also really lose out as well, on the sort of ability to move workloads back and forth. And, you know, not being locked in because they haven't sort of fully declared on, you know, an abstraction strategy.
Hobbs
Right. Rick, I've heard you observe that often clients, almost by default, end up generating six or seven micro strategies that they're unable to choose between. How do they get to that stage? Because I'm assuming that's what then leads to the paralysis or the vacillation, correct?
Claus
Yeah, this conundrum of having too many cooks in the kitchen, if you will, of making decisions for their own individual projects, and no centralised vision for what the ultimate single-cloud strategy should be, that has enough input from the different expertise areas of the storage admins, of the networking gurus, of the advocates of using cloud native technologies that are inside and the also the anti-cloud people that happen to be inside those different organisations. If you don't have the ability to bring them all together to have a voice on, say, in making that single strategy that they all can buy into, you're going to end up with dissent. And you're going to end up with folks that just are not committed to going down that path. On their particular portion of a particular project they say nope we're gonna stick with this cloud provider over here, even though you're going with the other one, because all my folks are trained up and understand this one better, so I can provide you with better services, that's when you end up with a lot of the fragmentation that we've seen so far.
Rehac
Yeah, one of the things that we see happen, right, is if you don't have a clear, you know, governance process and decision framework and, and clear lines of who makes each decision and how it's made. And that is anchored in your strategy. You know, different teams are actually executing against different strategies that are sometimes orthogonal to the direction that the CIO wants to go. And so you see each application, then, you know, be litigated, if you will, you know, throughout the organisation as to where it should go, and how it should go. And that can really be a big, big time sink and cause the cloud programme overall to slow down dramatically. So we believe pretty strongly in getting a decision framework agree to that is tied to the strategy that's been agreed to, and then tied into the governance structure within it so that it's clear who makes the decisions about what should move and where it should move, should it move to hyperscaler A or hyperscaler B and how it should move? I think, you know, one of the real complex parts of this issue is that over the last, you know, many years, it has kind of decentralised decision making and allowed for more and more local autonomy, which is I think, you know, a good thing in general, but it has led to the inability to make and hold to a single strategy from a centralised sort of command and control perspective. So we end up localising or optimising locally, and cloud is honestly something that needs to be optimised for the enterprise. And we've kind of lost the ability I think, as an IT organisation or organisations to do that, well, we've lost that muscle, and we need to rebuild it around cloud, in order to be able to execute quickly.
Hobbs
I think you make the same point, Rick, with a nod to the basic principles of it architecture, that the cloud is a situation when you ultimately need to optimise at the enterprise level, which is what Tim is saying. But you do that, importantly, via this decision framework, where you get all stakeholders committed to the strategy before you start, correct?
Claus
Yeah, when everybody feels that they have a seat at the table, but then ultimately, someone makes the decision, this is the way we're going to go. And we've all agreed to this, or people have agreed to disagree. But they understand in principle, what the nature is behind it, you get out of that paralysis mode that Tim talks about, and we've been talking about on this podcast. It's important to understand that a lot of the people that are making these contributions and discussions have valid points that potentially for this particular scenario, something's going to work, something's not going to work based on their experiences, because it's that tribal knowledge they have about those individual experiences. But ultimately, the agreement of going forward and progressing down the path of modernization, progressing down the path of adopting cloud technologies or hybrid strategies that work, that ultimately is going to get the internal customer and the external customer, what they need done, and what they need from the IT services environment to get those projects moving forward. The biggest thing that can happen that can be a blocker to this has been the I'm moving something just for the sake of moving, which is like one of the worst cases or I'm moving it and I've done hands free, it's over with. You have to continue to re-examine that workload and the services that you're using to make sure that you're using them in an optimal fashion and that you're getting the most value from them.
Hobbs
Tim, you're very clear. Once the business has hammered out a single, clear cloud strategy it needs to be explicit, and it needs to publish that. Where does it publish it? What does it do with that? Is that a letter to the staff and why is it so important to you today? It’s defining, I think, in the way that you view this.
Rehac
Yeah, I think the CIOs that we see do this best. They tell this story and they get behind the strategy. And they tell it repeatedly. And you know, it's funny and honestly, a lot of CIOs I speak to are kind of annoyed with it. But like, it takes seven times sometimes to tell people the same thing before they truly hear it, right? And maybe before they truly believe that you're going to enforce those rules. So it's something that needs to be done at town halls, it needs to be published on whatever, you know, standards, websites, the clients might have. Yeah, go out in the weekly newsletter on the cloud programme. Just constant reminders that yes, we've had this conversation, we understand the pros and cons, we've debated it, we came to a decision. And this is how we're executing.
Hobbs
Tim, what are the key elements that have an impact on the decision-making process? I guess you start from where the business is now and where it needs to be? And can you explain this, this expression ‘lift and shift’ and why it concerns you so much?
Rehac
Sure. Well, you know, we do feel actually that there's appropriate times for lift and shift. So lift and shift fundamentally, is taking a workload that's running on prem, and moving it really without any significant change to the cloud. So you know, the good news is, right, it's out of my data centre, and maybe I can close a few data centres. But I haven't fundamentally re architected the application to take advantage of the cloud. So in this case, the cloud is acting kind of like my data centre. Now, hopefully, I've got a little bit more automation, you know, the hyperscalers potentially have more scale than I do. So maybe it's cheaper for some clients, for some workloads. But I haven't done anything really dramatic other than move something to really take advantage of, you know, the cloud, I need to re architect the application, so it can scale dynamically, right? If I lift and shift the workload, it doesn't gain dynamic scaling, just by moving to the cloud, I actually have to do something to that workload. So for some of our clients, actually, most of them, there's a combination of, we always refer to the six R's, right. So on from left to right, the best business case actually is for retire. If I find things that I just don't need to run anymore, I turn them off. That's a pretty good business case, right? Next up, we refer to as re host, and that is a pure lift and shift. So you know, good news, it's pretty easy to do, I can get it done quickly. Bad news, not a tonne of savings, right. Not a tonne of agility gain. But you know, there is some goodness in that. Next up Microsoft and EY tends to refer to as a refactor, other hyperscalers might call this replatform. But I will do a lift and shift, but I'll optimise a few things, maybe I'll move to a pass database layer. Or maybe I'll upgrade an operating system, or maybe I'll add some automation around turning workloads off when they're not being used. So a little bit more cost to migrate, a little better benefit on the agility and on the cost perspective. Next up is re architecting the app and this is a big change to the application, I'm going to change the architecture or some of the components in a bigger investment to make that happen. But bigger returns both from a cost and agility benefit. And then last, is rewrite. So I'm going to essentially start over with this application, I'm going to write it in cloud native fashion. Probably these days, it'll be microservices. And probably these days, it'll be on Kubernetes. And now I can take advantage of all of the wonderful things that the cloud has to offer, all of the services that the hyperscalers have invested in, and I gained the most cost and agility benefit. But oh, by the way, the cost to actually rewrite that app is pretty high. So bigger investment, bigger return, longer time to break even.
Hobbs
I'm really impressed that you've got through all of the six Rs. I only had four on my list there, Tim?
Rehac
Ah, well, it might have been five, I'm not 100%.
Hobbs
Sure. But Rick, this is hard to do. I mean, you've said yourself a lot of engineers don’t want to go back and look at the code that was written before, they'd rather get involved in the greenfield stuff. I mean, this is a political problem within an organisation, I'm assuming?
Claus
it definitely is. And I do, I do want to give kudos to Tim for that beautiful spectrum discussion he just did a second ago because it really does kind of lay out the path that we've seen for the maturity of someone's cloud strategy of being able to go down that last level. And absolutely, as Tim mentioned, the higher up on that scale you have to go the more benefit you end up reaping from using these cloud technologies that are in there. But we do see a lot of customers that kind of come in and they stop at the lift and shift, take a breath, take a break and then all we'll get back to that in a bit but they don't come back to it. The incremental step even of just coming back and revisiting, oh, we used to back up our stuff this way on premises. Now we'll do it differently inside of the cloud environment. Or we, we used to rely, as Tim mentioned, on a dedicated virtual machine for sequel or for your database layer for their application. Now, let's go and we don't want to manage the complexity of the machine anymore, we now just want to take advantage of the platform as a service from databases and service options, to be able to go off and to have access to the data for that particular layer. The higher up in that scale you go, the more benefits you reap and the more payback you get, you don't get stuck inside of the world of we've moved it, it's done. It's typically in the cloud, we'll move on to the next 700 workloads, we have to decide if you want to retire. I love that. Or if you want to keep around in some kind of a modified form.
Hobbs
And we should remember, right, that you sit within the Azure engineering team talking to engineers around the world. I mean, fundamentally, I think for both of you, it comes down to guardrails in the struggle to be more agile, to give teams more autonomy, someone has to figure out how to make it clear that certain tenants of the plan are not up for debate, Rick?
Claus
You're having those defined on the paper based and then the people process side of things absolutely is required. Tim's done a great job going through some examples of how to go off and get this communicated. The good part is a knowledgeable team of individuals that understand the platform that they've chosen should go in and make sure that they have set up those guardrails, set up those policies, set up the different governance places, things that are in place that they always wanted to put in place on premises, but never got around to. Now they're in this green space of using cloud technologies, they can go through and say, Oh, you know what, the data team has the ability to go through and spin up these types of VMs only not these super large, super expensive ones, unless they're inside of production. But in the development environment, they can spin them up at this certain size, or they can only be running for so many hours. If they're inside the lab environment, and they get shut down automatically, you can put all these different processes in place, and you can put the guardrails in place too. So for instance, you have the ability to empower the different dev teams for different projects to allocate and create architectures and resources within the scope of their area for their project. But then they don't go and over commit or over populate or over create these different things, that potentially is going to incur a very large cost. So you can have these guardrails put in place, they can be flexible, to a point to give them the autonomy to work as their teams need to work. But at the same times, they still are there to enforce when they're over exceeding their bounds of where they should be working. Very simple examples with sizes of VMs is the easiest way to tangibly explain it, but it goes much, much, much more in depth because all hyperscale clouds, Microsoft Azure included, has these different policies, these different governance guidelines and these different blueprints as a way to set this up. So you've got the guardrails, the customers have the autonomy and the teams within your companies have that autonomy as well.
Hobbs
We're rapidly rapidly running out of time here, Tim, from the outside, when the cloud works, when does it work really well, what do you see at EA y as examples that should spur everybody on to these ideals?
Rehac
They're kind of good news is right, that most of our clients have come to the same conclusion. And that is that cloud architecture wins. Right? And honestly, I don't think there's any debate. So if you're creating, you know, a new application today, you know, you're gonna do it in the cloud. And if you don't do it in the cloud, then it's probably immediately technical debt, that's going to have to get migrated in the near future. Right. So, so, like, at least in my career, and it I have not never seen, you know, the whole industry, you know, sort of make the same decision almost at the same time. So I think that's the good news. And I think the clients that are doing it the best, you know, they take the time upfront to experiment a little bit, and then create the strategy, create the governance, create the decision framework, so that they can, you know, move quicker later, right. And then they can go and revisit that every 12 months or 18 months, but, you know, let's not revisit it on a daily basis. And then, you know, they tend to also have a mix of the of the five hours or six hours in the portfolio, right? Because if you want to go rewrite every application, it took us 70 years to accumulate those applications, right? So we're going to rewrite them all in 18 months is not a very good strategy, right? So there's got to be some combination of lift and shift and re architect and rewrite, and honestly replaced with software as a service solution as well. So you know, decide on your strategy, decide on the mix and what's appropriate for each application, and then go execute it. against that plan, those clients tend to be very happy and very well positioned, as we've seen with COVID. For a world that changes faster and faster every day, we cannot survive without agility in our technical solutions, and cloud is a key enabler.
Hobbs
Let me ask you one final question each. First of all, to you, Rick, what I really want to ask you is where we'll be in five or 10 years’ time, but the cloud is moving so fast, and the hyperscalers seem to be moving so fast. I don't know how, how you can answer that. But you are in a truly unique position to understand within the Azure engineering team, where do you think we'll be in five years or 10?
Claus
See, this is where I can give you my typical consulting answer of it depends. But I'm not going to do that. But what I will say is that Microsoft Azure, and quite frankly, all hyperscale cloud providers, we build the solutions that our customers are asking for, and that they're looking to have hard situations or hard problems solved. And we're very customer focused, to make sure that we have what our customers need, before they actually need to have it. And so we have a very strong listening arm, I'm part of that listening arm as an example, to be able to go through and to bring feedback from customers back to the engineering teams to help them craft their products better or create net new products. And customers ultimately end up succeeding because we do that, and all cloud providers do that.
Hobbs
But what you seem to be saying is that these are the two sides, the clients, and you guys within the engineering teams are moving at different speeds. And maybe that will become more dramatic.
Claus
I think as time goes on, I think the record’s going to show that we're always moving, but we're always going to be moving at different speeds. And we're going to be doing our best to stay ahead of what customers are asking and provide them with solutions that will solve their needs, once they come to the ability to adopt and to use some of these newer technologies. And so really, in the next five to 10 years, it's just going to continue to grow. And it's going to continue to evolve. And we're going to be here and ready for you when you're ready.
Hobbs
Tim how do you see the 5-10 year future? Didn't one of your clients ask you for a 15 year roadmap?
Rehac
They did. And you know, I do think it's telling a little bit about the pressure in different industries, right. So, you know, if your industry isn't undergoing a tremendous amount of change, then you can afford to have a 15 year cloud roadmap. By the way, I can't create one for you, because my cloud crystal ball runs out in about three years. Maybe it goes to five years. But it certainly doesn't get us 15. But you know, in that particular industry, they weren't feeling pressure, you know, that they had to change quickly. But as we've seen in financial services, as we see in retail, you know, there is tremendous pressure there. And I had a client tell me actually, as we were trying to decide on a cloud strategy, that, you know, he felt that the company wouldn't be there in five years, if they didn't dramatically digitally transform. And if they didn't make dramatic shifts to cloud. So if it's an existential question for that company, it's really impressive how fast some clients can move.
Hobbs
Tim Rehac, leading EY’s cloud strategy in the Americas, and Rick Claus, leading Microsoft's cloud advocacy efforts to the ops community. Thank you both. It's been a real pleasure. I think I understand a lot more than I did when we started this.
Rehac
This was great. I really enjoyed it. And it's always fun to talk to Rick.
Claus
It's just been a pleasure being on this one. I love the conversation that I've had, both with Tim and yourself, Simon, thanks a lot for having me.
Hobbs
For more information, visit ey.com/microsoft. A quick note from the attorneys. The views of third parties set out in this podcast are not necessarily the views of the global EY organisation nor its member firms. Moreover, they should be seen in the context of the time in which they were made. I'm Simon Hobbs I hope you'll join me again for the next edition of the EY podcast. EY and Microsoft, your digital world realised.
