A sensible approach to multi-cloud

Podcast transcript

Zhamak Dehghani:

Hi everyone. Welcome to Thoughtworks tech podcast. I'm your host Zhamak Dehghani. I'm really excited today to talk to Scott Shaw, one of my mentors and most favorite people in Thoughtworks about cloud adoption. So for maybe some people in our audience that may not know you or be familiar with your work, would you give a short introduction of what you do at Thoughtworks?

Scott Shaw:

Sure. I'm called the head of technology for Thoughtworks in Australia, so I'm the regional CTO. I have a dotted line report to Rebecca Parsons who's our global CTO, and I help to run the business and set the technology strategy for works here in Australia. I also do a fair amount of consulting and that's usually as an enterprise architect, or working to help people bridge the gap, I guess between traditional enterprise architecture and people who are trying to adopt more modern technology practices, cloud, agile, containers, microservices and things like that.

Zhamak Dehghani:

Thank you for the introduction. I know we can talk about many different topics today, but I'm also aware that you've been focusing a fair bit on the state of cloud adoption, the failure modes, and an interesting trend: multi-cloud. You had a wonderful talk called sensible multi-cloud at the YOW conference in Australia recently. So I'm hoping to pick your brain on the topic and perhaps starting with the current state of cloud adoption and what is really leading us towards this increasing interest to multi-cloud.

Scott Shaw:

Yeah, so I think there's a few reasons that people are considering multi-cloud now. We went through this, a lot of exuberance about cloud. I think it was something like 12 years ago now, that EC2 got launched and that was really exciting for a lot of us technologist because we discovered that we could write software that controlled all of the infrastructure, whereas in the past we would have to procure environments, and file a support ticket, and wait for a long time get environment. And then we had very limited access to those environments. You had to buy capacity ahead in anticipation, ahead so... Some I guess we saw that this was a revolutionary change and it was really exciting and lots of people went and created tools and the rest, it's snowballed and created this huge industry now.

Scott Shaw:

But I think along the way some of that excitement got lost. I think some of the early anticipation of what cloud could be and also the way that cloud is consumed by primarily digital companies, startups, and digital companies who truly use cloud in the sense of a metered service that you pay as you go, you have open network access, you can... Everything is available self-service and on demand that has... We've lost that, those qualities, sometimes when enterprises adopt cloud, so enterprises, many of them have done their best to put barriers that remove exactly those qualities that made cloud so exciting to people, and to replace them with support tickets and environments that are doled out one at a time and manage very closely. So that's one phenomenon that I've seen.

Scott Shaw:

Another is that people have adopted cloud without really, it... We didn't have roadmaps initially and they've done it, they've gone down certain paths that have made it difficult for them to see the business success that they may be anticipated at the start of their journey. So they may be had their costs may be ballooning out of control in a way that they didn't anticipate. So people expected to replace their data centers with with cloud, and then they find out that cloud is actually costing them more. That's not an uncommon story.

Scott Shaw:

Another problem is that they just can't find the capabilities. They can't hire enough people that understand cloud or I guess the way I interpret that is they hand responsibility for cloud over to their infrastructure teams. The infrastructure teams manage it the same way they manage assets in the data center, and that's missing a fundamental point about cloud, that is our assets are no longer the metal, the racks, the cables. It's the software, the asset that when you have a cloud environment, your asset is the software that defines that cloud environment. It's no longer the physical assets. So you need put the same level of care into your cloud software as you do into your application software, into the business applications that you're supporting.

Zhamak Dehghani:

So I guess in summary, what I'm understanding is that we had this new infrastructure that was adopted by a new set of consumers, new set of digital companies and then what we were seeing and they saw a lot of benefits in terms of flexibility, maybe reducing the cost of operation. And then we have this majority laggers that are now moving to cloud without the underlying paradigm shift that they need to have in the way they think about infrastructure, they think about managing it and they're essentially just using cloud infrastructure as a replacement for data centers and using the same processes and practices and the cultures that they had, but on a very different platform. And the result of that is the similar challenges that they've seen, high friction and plus higher cost of operation.

Scott Shaw:

Yeah, yeah. I think some of the things that we're seeing is difficulty hiring talent. They're finding that they're spending a lot of times just keeping the lights on and putting out fires. So managing the cloud environments and worrying about the security of those cloud environments is taking all of their time so they don't really have to depend with the innovate, and then we're finding that costs are blowing out as well, that people are spending a lot more than they anticipated on their cloud. The assets.

Zhamak Dehghani:

So what is the answer? What shift need to happen within the existing companies that have been running for many, many years and are used to a different model of operation in cloud? What are some of the aspects of this change that is required?

Scott Shaw:

Yeah. So I think there are really four areas that people need to address because cloud is a fundamental paradigm shift. You need to address it in a 360 degree way. You really need to take a holistic approach to changing your business and changing the way that you operate. So the first thing is around technology. So you have to approach, as I said, cloud from a software perspective rather than a hardware and capital asset perspective. So although there are lots of deep infrastructure skills and network skills needed to manage your cloud environments, you also need to bring in the software engineering.

Scott Shaw:

The second thing is you probably need to change your organization. We find that the separation between operations, and infrastructure, and application development engineering is an artificial separation when we're talking about cloud. You really need to bring these things together in a true DevOps style. DevOps isn't just writing infrastructure automation, DevOps is a cultural change, and an organizational change.

Scott Shaw:

The next thing is you need to have, you need to think about building platforms and you need to have a coherent set of capabilities exposed by APIs, but it's self service APIs and those platforms really need to serve the business goals. If you're building a platform that just exposes a bunch of technical capabilities in anticipation of people coming to use it, you're probably not using your resources very efficiently. Yeah, instead you should drive that by business needs. Build out the platform that you need to support your digital products that you're trying to get into the market.

Scott Shaw:

And finally you need to have a good strategic approach to choosing your cloud vendor. So there is no... I find that people are approaching choice of vendor when it comes to cloud suppliers in the way that they would approach a big IT asset purchase. So if you're going to buy a big core insurance system or you're going to contract a data center host, that requires a lot of deliberation, and it requires signing a big contract with big enterprise licensing fees. The whole idea of cloud was that we can turn that on its head, and we can consume only the bits we need. We don't need to follow that same process, and I think you need to choose the vendor that's right for each application, and choose the vendor that allows you to control your own assets rather than signing a big long-term agreement and handing over control to the cloud vendor.

Zhamak Dehghani:

That last topic is a really interesting one. I see organizations going through multi month, maybe years of analysis paralysis in terms of selecting their cloud vendor. It seems like a really big decision, a decision that the way they make this decision as if there is no point to return from this decision, once you've gone to this partnership and that's it. Can you talk about what are some of the criterias that we see clients put on the table in terms of selecting the cloud provider really as a partner. We see a lot of announcements that, so and so are joined, so they partnered and these are big announcements for the companies, big commitments peer like it's a big commitment. Maybe we can talk about what goes into those decisions.

Scott Shaw:

The first thing to recognize is that, that's in the interest of the cloud vendors. They want you to sign up for a longterm commitment and to consume as much of their resources as you can. So they incentivize that behavior. Certainly they're going to offer discounts. The more you use, the longer licensing agreement you agree to, the more discounts they're going to give you. So I can see the argument from that point of view, but you have to also remember that you are outsourcing your control at the same time and in the peoples rush to get the best bargain that they can from those cloud vendors, they sometimes give up the control of their IT assets that give them the flexibility to operate their business.

Zhamak Dehghani:

And I guess there is a risk associated with giving up those controls of your assets. There is a risk associated with buying into too many components, not just selectively get the components that you need. Can you talk to those risks and how to really mitigate those?

Scott Shaw:

There are various risks that people are starting to get concerned about. So I see more and more businesses partially because we now have a choice of cloud vendors. I realize they're at various levels of maturity, but we have relative parity across a broad range of infrastructure services across, the cloud vendors. People are also being, I guess encouraged by regulators to look at multi-cloud as one of their strategic priorities. And the risks that they're trying to address with multi-cloud, partly it's relationship risks. So you may have a great relationship with your cloud vendor today, but we're talking about 5, 10 year relationship. So you mean what happens when your rival business opens across town and they're bigger, they consume more services than you do, will the cloud vendors still give you the same level of attention? Will they still address your support cases? Will they still give you the discounts that you're looking for when there are more people in the market?

Scott Shaw:

The second risk is the problem of control. I mean we've known for a long time that it's important to maintain, especially over your strategic assets, or your strategic assets over those IT systems that are core to your business. You need to retain control, you need to be able to upgrade on your own schedule. You need to be able to add features that you need when you need them and you don't want to have to pay to support features that you're not using. So it's important to keep that control in house. You also need to have some competitive pressure. You need to be able to manage the pricing. And so if the vendor knows that you have a choice, they're going... their incentivizes them to keep their prices low. That risk is concentration risk. So this is the problem of having all of your eggs in one basket and this is addressed somewhat by choosing what we call poly clouds.

Scott Shaw:

So choosing the best tool for the job, you may, for your data applications, go to one vendor, for your infrastructure intensive applications, go to another vendor that addresses concentration risk to a certain extent. But it's not 100% fixed for that and this is something that regulators are particularly concerned about having an entire say to financial industry dependent on a single cloud provider can introduce risks to the economy, not just to a single organization.

Zhamak Dehghani:

You say something there that grab my attention, choice. The enterprises or companies need to know that they have a choice to go to different cloud providers and you mentioned the parity of capabilities as one of those underlying I guess pieces to have this choice that you can get the same function not only on AWS, but also on Google and the others. What are some of the capabilities or drivers that are enabling having a choice, be able to use multiple clouds, as your underlying services?

Scott Shaw:

There is parody in terms of you can get compute, you can get say the same capacity of memory and CPU cycles from each of the vendors. You can get basic network capabilities. You have to think about how you're actually configuring those things. So many people rush into multi-cloud, assuming that say functions as a service implemented on that as your Azure Lamdas, is the same thing as functions as a service implemented Azure functions. Some of the things that create problems there is identity access management, credential management and encryption, those things people typically do in the raw primitives that the cloud provider gives you. So I am rules, for example. So although there is parody across those basic functions, it's very difficult many times to be able to reuse the software that you write for one cloud provider, another cloud provider. So there's... But today we have things, for example, Kubernetes that allow us to... They give us a level of abstraction away from the cloud provider. But we still have a long ways to go with that.

Scott Shaw:

And I think containers are one of the things that can help you gain some independence from your cloud provider. It's not a complete solution. On the other hand, I don't think we should make too much of Kubernetes. It's still just a way to host a distributed application. It's a way to host an endpoint, an IP address in a port, and many of the rules of distribution, and redundancy, and resilience apply the same way to Kubernetes as they do, when we had to host those things in our own, when we had the handcraft environments where we hosted those things.

Scott Shaw:

There are several practices I think people can adopt to take advantage of the parody between cloud providers that shield you from some of the proprietariness of each of the vendors capabilities and the APIs and the security primitives and so on that they offer. I think it's really important to fuze... I think much of what we already know about software engineering is designed to give us that independence, good software architecture, taking advantage of abstraction and capsulation gives us the flexibility that we need to be able to move from one vendor to another.

Scott Shaw:

If you have an application that you need to move between cloud providers, nobody expects that, that portability is going to come for free. You're going to... It's okay to do some work generally and the amount of work that you need to do to port that application is probably dependant on the criticality and level of risks that you're willing to accept with that particular application. So this gets to the heart of what I've been trying to help people do with multi-cloud, which is choose a level of portability of your application and a multi-cloud treatment, a multi-cloud solution that is commensurate to the risk that you want to accept in that application. So with some of your assets, things like a promotional website for example, you have a limited time promotion, you want to roll out a website, the contest or something like that.

Scott Shaw:

It's going to be in existence for a few months and then it might be discarded, something like that. There's no point in looking for a multi-cloud solution for that application. You can go for broke, use all of the vendor's capabilities. They give you a tremendous amount of labor saving innovations, and the cloud vendors are constantly rolling out new innovations that make it easier and easier for developers to use. On the other hand, if you have a really critical asset, something like a core system that actually runs your business, that's something that you probably want to manage the risks very carefully. And that's also an asset that's going to be much more long lived, that's an asset that you're going to have to maintain 5 or 10 years. So it's worth building in a certain level of portability there. It's worth building in a lot of abstraction and insulation from the cloud vendors proprietary services so that you can very quickly and cheaply port that later on.

Zhamak Dehghani:

So what I'm hearing a lot of nuggets of I guess tips for listeners as how to create a choice, an option of taking different cloud providers and some of these, majority of what you're talking about is practices that are known to suffer developers for a long, long time. Abstraction, cohesion, lack of coupling, addressing coupling. And we're just bringing those practices to sensible practices to infrastructure and coupling to the underlying infrastructure. And what I'm also hearing, that there's a level of costs associated with it. So it's important to classify the assets we have, incurring that cost for the assets that are worth addressing the risks of coupling to a cloud provider. I want to pause for a moment here. You mentioned multi-cloud quite a few times as we were talking about this choice of having different cloud providers. What does multi-cloud mean?

Scott Shaw:

Yeah. I think there are several, it's a term that's seeing more and more use, right? Yeah. Board rooms and execs are also concerned about the level of dependence that they have on their cloud vendors and they're mandating that people adopt the multi-cloud policy. So it's a term that's getting used a lot. And I think there's a few different ways that you can look at it, there's a few different, quite different application deployments schemes. There are architectures that fall in this category, multi-cloud. The first thing is poly clouds. So it's what we called it on the tech radar, a poly cloud and that's choosing the best vendor for the job. So for example, Google tends to specialize in data and machine learning. So you may want to use the Google cloud platform for that, whereas Amazon has the most advanced infrastructure hosting.

Scott Shaw:

So if you want just infrastructure as a service, you may want to choose Amazon for that. And so they have various specialties, or it might be the team that has a particular skill set in one cloud provider or another. So that's going to, that can be considered multi-cloud, choosing, spreading your workloads across different cloud providers depending on which teams deploying it. That's not really what I'm talking about. That's a tool we call it poly cloud. It's not, and multi-cloud would be one of the following portability or some level of portability, whether it's quick and easy or if it's expensive, but being able to port your application from one cloud vendor to another within constrained amount of time and budget.

Scott Shaw:

Another would be a choice of hosting. So where you have an application that you could host to one cloud provider or another, depending on various whether you have a good relationship with the cloud vendor or a business competitive relationship with them, you may want to move out and choose to deploy that application in a different vendor. And finally there's this highest level, most expensive form of multi-cloud that is simultaneous operation. So that would be a high availability, redundant deployments across multiple cloud vendors with geographic load balancing and so on. That's, I think it's very rare that you would need that multi-cloud approach.

Scott Shaw:

There may be certain cases, but I don't think it's really, I think the cost of achieving that right now is probably not warranted given that you can achieve the availability that you need probably with multi-region, multi-availabilities on configurations in a single vendor.

Zhamak Dehghani:

I know we talked about multi-cloud in terms of addressing the vendor lock in and we talked about also some legislation or regulatory requirements around ability to go from one cloud to provider. Are there any other drivers for people to think about multi-cloud as a strategy for their hosting?

Scott Shaw:

Yeah, I think it's all about risk management. I think that is the primary driver to whether it's managing relationship risk, applying some competitive pressure to your cloud vendor to keep prices at parity. It might be just reducing the concentration risk between vendors, you want to spread your load across. Even though you have, each asset is deployed in a single cloud vendor, you set ups different assets deployed in different cloud vendors. Those are the risks. I think the big one that people forget about is control and that is we need to be able to, this is something that enterprises have a lesson they need to learn over and over again. And we've in this industry, we've known for a long time that in order to, that your business success depends on maintaining a certain level of control over your IT assets.

Scott Shaw:

There are some businesses who choose to outsource all of their technology. But in today's world where every business is a digital business, you can't really afford to do that. So for your core assets, you need to maintain as much control, flexibility over those as possible. So implementing them in a single cloud vendor that can in a way that is very difficult or expensive to port, it's probably not a good idea for your most strategic assets.

Zhamak Dehghani:

So for listeners who are either interested in doing multi-cloud or are somewhere on the journey, how should we do multi-cloud? What does a sensible multi-cloud look like?

Scott Shaw:

Yeah, so I know that there are a lot of products and a lot of vendors out there that will try and sell you things that allow you to seamlessly transparently port your applications from one cloud vendor and others. So providing this abstraction layer, an abstract cloud that hides which vendor that you might be deployed to in the back end. I think that is probably, what that leads to is this lowest common denominator. We don't get the real benefits of any of the cloud vendors and we don't get to take advantage of the tremendous innovations. The pace of innovation that the cloud vendors are rolling out right now is really mind boggling and there is increasing productivity gains to be had by taking advantage of the new services.

Scott Shaw:

If you're willing to accept some growing pains and learn how to use those services, I think there's a tremendous amount of productivity so you want to be able to take advantage of that when you need to. On the other hand, for some assets that are long lived that you're going to have around for 5 or 10 years, you probably want to maintain some independence. So I think you need to choose the multi-cloud approach based on the business criticality of each application and you need to look at your portfolio on an application by application basis and choose the multi-cloud treatment and the level of portability that's appropriate for that particular business workload.

Zhamak Dehghani:

I know you've done a fair bit of work in actually establishing frameworks to assess the risk and to look at business criticality, is there anything else that, anything that can be said in a few sentences? I know that we don't have time to go through framework, but some guidelines around how to look at business criticality, how to think about level of portabilty.

Scott Shaw:

Yeah, I think it's important to quantify the portability. I mean, Gregor Hohpe has this concept of buying options. So in a way, investing in portability for an application is like buying an option on a share price. It's locking in a portability cost or a strike price sometime in the future. And this is something that people often don't think about cloud aside, seldom is the portability or the replatforming costs of an action taken into account when people do make a business case for investing in a particular system. But inevitably I've been involved in too many replatforming projects to ignore that problem because ultimately it is going to cost you if you get completely locked in, whether it's a cloud vendor or a big piece of enterprise software, it's going to cost you a lot to port that later on if you don't make some investment up front and buy down the options to lower that strike price in the future.

Zhamak Dehghani:

So in summary, I suppose, think about don't treat all the applications and their level of portability the same. Be able to try to quantify that level of portability and then coming to the investment that is needed to build that portability into the applications, is there...

Scott Shaw:

The challenges in how do we price those, that portability option isn't... Sometimes it's worth investing a lot in creating portability in your application. Sometimes it's not worth investing anything at all and it's better to just rebuild that application in a new cloud vendor if and when you have to port it.

Zhamak Dehghani:

It's an interesting spectrum that you articulated there. We're coming up to the I guess to the end of this conversation. Is there anything else that you want to leave the audience with? Any words of advice?

Scott Shaw:

Yeah, I think that just to summarize the approach, first of all, decide if multi-cloud is for you. If you're a startup to the point where your business is viable, you probably don't want to think about multi-cloud. Multi-cloud is probably too expensive. You just need to get your applications up and running in the first place. But if you do have a long-term plan and you do need to maintain your applications over a longer period of time and you have to account for the possibility that you might need to change cloud vendors at some point in the future, and in that case you need to understand how do you map the criticality of your application to a certain investment in portability for that application so that you know how much to spend in making it affordable.

Scott Shaw:

And then evaluate each of your workloads separately. Look at the criticality of that workload, look at the business risk of having to port that workload, and then choose the multi-cloud treatment that works best for that particular workload. I think the last thing, sorry. The last thing I want to say is that there are a lot of really common sense patterns. You don't need to invest in a lot of extra kit in order to achieve multi-cloud in order to lower that cost of portability. There's a lot of that we already know about software engineering. There's a lot of good practices that we can already follow to maintain a level of independence from underlying cloud vendors services.

Zhamak Dehghani:

Thank you, Scott. It was wonderful talking to you. Thank you for spending the time with me

Speaker 3:

And on the next episode, we will talk to Luciano Ramahlo, principal consultant at Thoughtworks and the author of the popular Fluent Python book. Luciano we'll talk about the upcoming second edition of his book and the future of Python in general. Hope you will join us for this conversation.