 Welcome everyone to the webinar, multi-cloud strategy, a necessary evil foreign enterprise by Rashmi Thambe and Sunit Parek. So without any further delay, over to you Rashmi. Thanks a lot, I'm just sharing my screen. Thanks everyone, and thanks to Agile India for hosting us. Today, myself and Sunit Parek, we will be talking about multi-cloud strategy. Both of us are part of ThoughtWorks. We work, we are part of a service line which focuses on enterprise modernization, clouds and platforms. And without, we have a packed agenda. So without further ado, let me quickly go through the agenda. So we'll first start with demystifying the multi-cloud deployment model because when you hear the term multi-cloud, it actually means many things. And based on our experience of working with many clients, we realize that they mean many overlapping things when they say that they're looking at multi-cloud. So we realize that it is really important to demystify the terms and to really define what does it actually mean by multi-cloud? What are the various flavors of multi-cloud? Then we understand what does the industry say about multi-cloud? Why are the enterprises embracing multi-cloud? What are the key business drivers? But what are the challenges? While most of the enterprises are going towards multi-cloud, there are challenges. Multi-cloud is hard, it's complex. So what are the challenges in the journey? And finally, in order to build a successful and a sustainable multi-cloud strategy, what is our approach? What is it that ThoughtWorks proposes based on three core tenets evaluating your workload, defining a multi-cloud operating model, and governing your multi-cloud environment? So these are the three core tenets of our multi-cloud strategy. And finally, we'll come to the summary of it. So let's first start with the multi-cloud models. What do clients actually mean when they say they are looking at multi-cloud? So journey to cloud for any enterprise usually starts with mono-cloud. Straight forward term, mono-cloud means one cloud when the enterprises are in the very early stage of their cloud journey and looking to a particular public cloud provider for migrating their workloads, then it's called mono-cloud, which is just one cloud. Hybrid cloud, which is when the workloads are running in combination of your on-premise infrastructure as well as your public cloud infrastructure, then you're looking at a hybrid cloud setup. Now things get really, really interesting when you're looking at more than one public cloud provider. This is what is called as a poly-cloud strategy. It's a start of your true multi-cloud journey where you're looking at more than one public cloud providers. And usually the enterprises choose a particular cloud provider based on various factors like various features and services provided by that cloud, service availability in the particular geo, latency, et cetera. So workload going to either one cloud or another depending on these factors and the guidelines for deciding this is what we call as a poly-cloud strategy. Then comes portable cloud. This is a very, very complex or I would say a little bit of a deliberate choice when enterprises are looking at business critical applications to run across two clouds in order to ensure the continuity of the business in order to ensure the high availability, they are looking at portable clouds. So the same workload, which is a very high business critical workload running in two clouds either in active active mode or active passive mode in a typical DR setup. That's what we call as a portable cloud. The reason it is portable is because the workload has an ability to run on any cloud and it has a cloud agnostic application architecture. So if it's required to move the workload from one cloud to another public cloud, there are obviously efforts involved but it is possible to do that and that's why it's called portable cloud. And last but not the least, distributed cloud. This is the most complex or it's a geographically distributed setup of the workloads across, your on-premise setup across multiple public, private clouds, workloads running on edge. All of this is centrally managed by one public cloud provider. What does it centrally managed means is being able to do uniform policy enforcement and compliance, being able to monitor and manage these environments from one public cloud provider. That this is what is called as a distributed cloud. You can think of, for example, Google has an offering GCP and POS distributed cloud which helps customers do this, which it has a central way of managing workloads which are running across multiple cloud providers on-premise or on-edge, et cetera. So before I move on in the chat, you will see a poll we would like to understand from you based on the scenarios in your enterprises. What do you see most common? And it could be multi-choice. You might have seen both hybrid poly or hybrid poly, portable, et cetera. So let us know what are the typical scenarios that you have come across. So moving on, so multi-cloud, the reason why we have named this session as it's a necessary evill for enterprise. And we don't mean evill in a necessarily negative way. Why evill we mean it is complex. It requires certain set of skills, certain set of maturity and capability to be able to embark on the multi-cloud journey and have a sustainable multi-cloud journey. And that's why we call it as a necessary evill for enterprise. So as you see from your data center to monocloud, hybrid, poly, portable, and distributed, the complexity and the maturity, you have to have more maturity in the organization in terms of skills, in terms of capabilities, in terms of budget, CXO backing, because the journey gets more and more complex. And this is where we advise a lot of clients. For example, we were working with one of the telecom providers in Southeast Asia, who has been working on AWS and looking at GCP as their other cloud provider. When they came to us, they directly started talking about a portable cloud, having ability to run the workloads across clouds. And we showed them this and we told them that, hey, you don't necessarily need that. Do you really have business critical applications with the very high availability requirements? And you probably mean polycloud because you want to choose which went to use AWS and GCP for your workloads. And that's why it's important to, and that's where we help clients based on what their objectives are, how it gets really complex and what kind of deployment model you should choose for the kind of workloads you have. So let's quickly look at what is the industry saying about multi-cloud. You'll see some numbers here. These numbers are from renowned industry analysts, for example, there's a number from IDC, which says 81% of enterprises are looking at multiple public clouds. State of cloud report from Flexera says 89% of enterprises have multi-cloud strategy. The number is same from Gartner. What is interesting is that these numbers are across the flavors that we saw in the earlier slides. For example, when Flexera says 89% have multi-cloud strategy, within that 89% actually they're saying that 80% have a hybrid cloud strategy. So these numbers are, these are mixed, but it sets a trend that in the industry, it is becoming necessary mostly for large enterprises to look at multi-cloud environments. So the 89% number that you saw, the Flexera state of the cloud report, it says 89% enterprises have a multi-cloud strategy and 80% have a hybrid cloud strategy. So this is just a distribution of that 80%. When they say we have a hybrid cloud strategy, for example, 48% of them have, which is pretty large number, half of them are saying that we are looking at multiple public and multiple private. So the private could mean on-premise plus a private cloud setups. 31% says multiple public and one private. So you'll see all more than three fourth of these enterprises are dealing with multiple public cloud providers and private cloud providers. And that's how these numbers are distributed. So why is this number so high? And why the enterprises, when we know that multi-cloud is complex, it really requires maturity. What is it that is driving these enterprises to go to multi-cloud? So some of the key drivers, for example, that we are now listing all of them, I'm going to talk about four key drivers here based on the use cases that we have seen. For example, leveraging best of breed services from multiple cloud providers. In our experiences, we've seen that a typical example where in the clients are embracing GCP for running their data and machine learning workloads and AWS for containerized workloads. So this depends on, for example, you choose a particular cloud, and this is what polycloud strategy is. You choose a particular slide cloud for a particular set of or particular types of workload, depending on the features or services that are provided by that cloud provider. So if you're already an AWSR as your shop, you may be looking at GCP for running your data workload. Just one example, there could be many such examples. Other reason that we have seen is to manage vendor lock-in. And this is especially very relevant for large enterprises who are looking to hedge their business risks. They do not want to completely dependant on one particular cloud provider. And they also want to leverage across cloud providers to negotiate their billing charges, et cetera. So that's why this is especially required for large enterprises to look at multiple cloud scenarios to manage to avoid the vendor lock-in because then that increases your business risk to multifold that if you're completely, if all your business critical applications are running on one particular cloud provider, it increases the business risk. Other use cases that we have seen is addressing the business continuity. For example, in India, one of the largest banks that we are working with who is running their banking and lending platform on AWS is looking at GCP as their DR cloud for the business continuity. And this is also true because of some of the policy guidelines that are coming from RBI, especially if the banks are running workloads in cloud, they need to have a DR capability on another cloud. Other scenario that we have seen is to manage competition. This is true for many of the online retail companies wherein initially when they embraced cloud, they went ahead with AWS, but now Amazon being their key competitor in online retail, they're looking at other cloud options like AWS and Azure, sorry, looking at Azure and GCP as a second cloud provider to address the competition aspect of it because they are in the same business as Amazon. And last but not the least, there are some geopolitical dynamics. For example, multinational companies when they do M&As in other regions, maybe the other company is running on other cloud. Sometimes there are country-specific data residencer requirements because of which they need to consider another cloud. Other reason is, for example, China as part of their digital Silk Route initiative. It has plans of putting more than 1 million companies on cloud in areas like Saudi Arabia, Laos, Turkey, et cetera. So multinational companies who are operating in these regions have to look at multi-cloud as an option if they wanna be relevant in those particular geographies. So I'll take a pause here. Again, you will see another question in the chat and we would like to hear from you. What are the key business drivers that you have seen out of all of this? Or if you think your business driver doesn't fall into this, please let us know by answering the question in the chat. Again, a multi-choice question. What sort of business drivers that you have seen in your enterprises of people embracing multi-cloud? Okay, so with that, sorry, there's one more slide. So as I was saying earlier, these are the key business use cases for multi-cloud that we have seen are in our experience, it is poly-cloud, which is choosing a cloud for a type of workload, as well as disaster recovery for business continuity. Some of the other, and it also matches with this statistics that comes from Plexera State of the Cloud report, which is DR failover apps on different cloud, which is a poly-cloud strategy. And then there are other use cases, like integration across clouds, workload mobility across clouds, which is the portability part of it, and so on and so forth. So this is exactly what we have also seen. These two are the top-to-use cases that we have seen in our experience. So with that, I will stop the share and I will invite Sunita to talk about the next section. So I think we have understood from the discussions that we had so far that multi-cloud is the necessary for every organization now, because of many drivers, business drivers that we end up in, choosing more than one cloud service providers, right? And to start that journey, we first need to understand what are the challenges in adopting the multi-cloud strategy. So let's look at those challenges first, and then go into the next, which is the strategy or the solution part of it, right? So the first challenge in adopting the multi-cloud strategy is that how we are going to provision our infrastructure and manage them across the cloud service provider, right? And I think we have been doing some meta-cloud formation templates and all that so far, but now we have to think about a proper way to manage them. There are really good tools available nowadays, like Terraform, Pulumi and all that, but still we need to have that proper cross-platform provisioning strategy for us, right? So that is first challenge that it starts with. Second, once we have this out of the box, the second challenge is having the uniform security and compliance policy real-out. This is very important for large organizations to not get into some defaults and compliance issues, right? And security has been one of the primary threat to moving to cloud. So if you don't have a uniform security across cloud service providers, it's going to put you on the backseat again. So this is another challenge that we figured out how to do all the security and compliance stuff on one cloud service provider. Now we have to go and put it on the another. You have a different tool set, different ways to implement the actual security. Some securities are provided by the cloud service provider, some are not, all that complexity starts gripping in. Then comes the application. So you got the infrastructure setup, security setup, maybe, and then comes the application, right? Now, if you have to build the portable apps across CSPs, how you are going to have your architecture, which is cloud agnostic, right? And all that is going to play the role there. Moving on, application is set up across, but then to work them, we need to have a data replication availability across the stateful workloads, right? If you have a, let's say, Redis cluster in one of the cloud service provider, how you replicate across if you have to put the caches there, right? If you have a database, how you replicate? If you are using PolyCloud, so application is running on one of the cloud and your data workloads are running on another cloud, you have to move this data across, right? So you have to replicate the data into the another cloud. So all that needs to be sorted out. Then comes the network topology, how you are going to connect your network from on-prem to your cloud service providers from the public, coming to the actual cloud service providers. You need to set up at both the places. And to do all of this, you need to have an in-house or when there is a skill and capability management, you need to now have capability for both our multiple cloud service providers. And you need to think about how we can have a fungible people who can go across and work across multiple cloud service providers. And the last, once we have set up, we got the skills done, the last challenge is the cost. We need to now manage cost and optimize resources usage across the multiple cloud service provider. Now these are the key or the list of the challenges that you will get into once you start adopting the multi-cloud strategy. Here we have tried to put the one view of increased effort and complexity. So with cross-platform infrastructure provisioning, your efforts and complexity increases. But this problem is kind of solved in a way with the help of Terraform and Pulumi and all those tools, right? Security and compliance policy rollout becomes more difficult and challenging because every CSPs have their own tools. Tools like Open Policy Agent and all that will help you further there. So similarly, we go on for the each list and your capability development within the organization is going to be major challenge. And that's where your significant increase in effort and hiring and having people across is going to be required, right? So this is the map of the effort and complexity increase across different challenges. With that, I would like to move to the next part. So we looked at the different deployment models of multi-cloud. We looked at the drivers for adopting multi-cloud. We looked at challenges for adopting the multi-cloud. Now comes the approach to build your own multi-cloud strategy. So we have been working with many clients, customer over the last many years and come with some structured way of solving this problem. And that has helped us a lot and we are sharing that model with everyone here. So we start with the multi-cloud strategy talking about three tenets of the multi-cloud setup that we have to do. The first is to evaluate your workload. Like assess your workload, distribute them, have a clear guidelines and policy around what kind of workloads to be deployed where and all. We'll deep dive into this again. Once you've decided that this workload needs to be deployed in a certain way, let's say polycloud or maybe portable cloud or a true distributed cloud, we need to come up with the operating model for them. And in operating model, we are going to talk about three key aspects, people, process and technology. You have to look at operating model across all these three. And the last, once you have that ready and set up, all that is running. Now you need to start governing your multi-cloud environment and need to have very clear way to govern the multi-cloud environment. And we always say that it should be in a practitioner's view. So you make the team aware of governing their own environments and it becomes more prominent in the multi-cloud because you have so many people working on different types of applications across the clouds. So it's a key three tenets. The first is evaluate, second is operate and third is govern. So we are going to look into this very quickly, each one of these. Over to you, Rashmi. Yeah. So starting with the first part of the framework, evaluating your workload. Before we start with the workload assessment part of it, we need to understand what are the key architecture patterns when you're building applications on cloud. So we have classified it in two key architecture patterns. First one being a cloud agnostic architecture. So when you're building applications mostly using, let's say open source frameworks, for example, you're using Postgres for database, Kafka for messaging, Kubernetes for containers, container orchestration, Docker for containers. Basically you make choices, which are available on all cloud providers. You make, for example, Kubernetes, if you go with Kubernetes as your container orchestration model, then you have managed Kubernetes offerings from each of the cloud providers. So if you are on AWS, you are using EKS, on GCP, you can use GK, which is Google Kubernetes Engine on Azure, you can use Azure Kubernetes. So these are some of the choices that you make when you're building an application in a cloud agnostic architecture. When you do that, the application becomes portable. So then you're looking at a portable cloud strategy, as in it's a deliberate way of building an application so that this application is portable across cloud and if there is a need to port this application from one cloud to another so that you are not tied to the underlying cloud platform. The opposite end of the spectrum is cloud specialized architecture, wherein you are making, and again, this is also a deliberate choice when you are making use of the underlying cloud provider services for building the application. For example, let's say you're building an application on AWS, you're making use of AWS lambdas for serverless, SQS, SNS for messaging, Kinesis for streaming, and Fargate for your managed Kubernetes, rather managed content orchestration and so on. So basically these choices are the reason why you would go for this is, then you're looking at a poly cloud strategy. You have decided to make the most of all the underlying services that the cloud provides and you do not want to make this application a cloud agnostic application and why is that? So we'll talk about that in the next slide. When do you make these choices and what are the trade-offs in these choices? So let's take an example. So let's take an example of let's say a telecom company, the company that I was talking about earlier, for example. So on the X axis, you have architecture styles. There's a cloud agnostic architecture, two cloud specialized architecture. And on the Y axis, you have the criticality of business application. So your business criticality of an application from low to high. So for a typical telecom provider, for example, a network operation related workloads, these are very, very business critical workloads. You cannot have downtime for these workloads, where these have very high availability SLAs around these workloads. So because of the high availability expectations here, when you are looking at building or migrating these applications or modernizing these applications in the multi-cloud environment, you should think of cloud agnostic because you may need to set up your DR on another cloud in either inactive, active or active passive manner. So for that, it is important to have a cloud agnostic architecture and not have too much tied with the underlying cloud platform. So that's when you look at agnostic architecture for a high business critical application. Again, on the other end of the spectrum, let's say you're looking at a promotional website. This is, again, it has let's say a medium and high tier requirements while you want users to quickly come on your site and look at the promotion. So your time to market is very, very quick. And then it makes a lot of sense to make use of underlying cloud specialized services, cloud specialized serverless services to do a very quick go-to market of this. And you are not looking at porting this across clouds because business criticality of this application, while you need this application running, it is still at a lower level as compared to a network operator. That's where you're looking at a cloud specialized architecture. And then another example, order management, the sits in between, order management is also very critical for a telecom company. But here you could architecture wise, you could look at not going too much on agnostic or on specialized, but maybe making use of some of the managed services from the cloud providers which are available across clouds, like by using managed Kafka, managed Kubernetes or basically all the services which has complimentary services from other cloud providers. But again, there are trade-offs. For example, if you are too much on the cloud agnostic side of the architecture, it will give you a lot of flexibility. And on the specialized side, it will do it'll entail in lot of vendor lock-in. But there are other trade-offs, for example, the flexibility comes with high efforts and longer timelines. You will take much longer time to do a go-to market of these applications versus on the other side, if you are going with underlying cloud, if you are building applications with a specialized architecture, these are lower efforts, quick turnaround time. But with that, that's why this is called as trade-off with the lower efforts, you get minimum flexibility. With higher efforts, you get maximum flexibility. So these are some of the guidelines that we suggest to our clients. Again, these are guidelines and they change, they're subject to change for every kind of workload, every kind of client requirements, et cetera. But these are some of the blueprints of the guidelines. So let's look at what are the choices that cloud providers give us. I'm taking an example of AWS here. If you look at services from AWS, they can be bucketed into three very high-level buckets, self-managed services like EC2, Kafka, Cassandra, AWS managed services like Amazon, Redshift, Elastic Cache, RDS, et cetera. And serverless services, which like S3, Lambda, DynamoDB, SQS, et cetera. Again, going back to the earlier slide, when you make architecture choices on the two parts, whether you're going to agnostic, when you go to agnostic, you're using self-managed services. When you're going on the two specialized side of the architecture, you are making use of serverless services and same trade-off supply here. On this side, you have maximum flexibility, but higher efforts. On the other side, you have vendor locking, but quick turnaround time. So depending on the kind of workload you have, the kind of HR requirements it has, the criticality of that workload, these choices of architecture and the services that you use differ. So how do we help clients to make these choices? So this is where our framework comes in, depending on each type of workload, whether it's a business-critical consumer-facing workload with which very high HR requirements or whether it's a backend workload or a workload being used by, maybe these are internal applications, employee applications, or these are some new innovative workloads that you're looking at. Depending on these types of workloads, there are three steps. First is, choose your cloud architecture pattern, or whether you want to go agnostic versus specialized, looking at all the trade-offs that you saw in earlier slide. Make use of the tech stack choice. If you're going to agnostic, then maybe you are somewhere here between self-manage and manage. If you're going to specialize, you are in serverless. And then finally, you will arrive at your multi-cloud deployment model, depending on the choices that you have made. Those models could be, for example, if you have gone agnostic with a self-manage stack, then you are looking at a portable cloud option or vice versa. For example, for specialized serverless, you're looking at a polycloud option. This is how we have defined a metrics or decision metrics to help our clients to choose these options for all the workloads. So with that, we are done with the first part of the framework, which is evaluation. Again, I'll invite Sunit for the next part, which is the operate. So once we have made the decision on, okay, what kind of workload goes where and all that, now we have to come to the operating model for that. In operating model, we talk about three parts. The first part is the people, the organization teams, its capabilities, how you put them, how you structure them, all that stuff. The second part is your processes, your practices, standard operating procedures, KPIs of governance and tracking and all that stuff. And the third part comes the technology where you define your text tag, sensible defaults, guidelines, so that every application knows what is their path and how they can be set up. So all that three aspects, people, process and technology needs to be looked at when we are looking at the operating model. And further, I think this is again huge, we have divided into three, but again, we have to look at dividing it further. So we say that, okay, when you're looking at technology, which is the most complex when it comes to the cloud and when it becomes multi-cloud, it adds up on that, right? So we divide them into again four categories, your days infrastructure, your operational infrastructure, your orchestration and integration infrastructure and application and storage related layer. So these are like four different categories inside the technology and these are the examples of it, right? So when we are looking at the base infrastructure, how you are going to set up your network, right? How you are going to set up your infrastructure security, right? All your WAF and all that across the edge and everything. When it comes to operational, you have to think about how you are going to monitor and observe your system, how you are going to do the secret management and all that. Third layer, when it comes to orchestration, you need to have your API platform, API gateway, how you are going to manage your queues, your service catalog, container orchestration management, all that stuff. And the fourth layer is where you get, how you're going to manage your application lifecycle, stateful workloads, databases, object stores and all that, right? So we divided that into four category. We need to deep dive again into each of these in respect to multi-cloud. We'll give you some example further. And for the business and processes, we have to look at, okay, how we are going to manage our SLAs across the multiple cloud service provider. What kind of application should have, what kind of SLAs? Production environment should have shortly SLAs, but non-product environment should also have some SLAs, right? What kind of metrics and KPIs we are going to measure, right? The top most layer is the people, where you say that how you are going to organize your team and put them across so that you don't have duplication, but you don't have a centralized way of managing also, right? So it has to be thought about that, how you're going to build your skill and technology and capability, right? How you're going to define roles and responsibility. And on top of all of this, your cloud strategy is going to bring a change in the organization. And how you are going to manage this change overall is key. So you need to look at many aspects of people, process and technology. Let's look at two of them in this session. So the first one is observability and monitoring. And second one is the container management. These are classical too. And difficult to manage across multiple cloud service providers. But with the tool and the setups that we have in today, marketplace, I think there are many cloud agnostic tooling available there. So one of the things that we always recommend or we always go for in building our cloud strategy is that having this centralized observability and monitoring. Now the centralized unified observability and monitoring can bring a lot of insights which are correlated, right? Something happened at the infrastructure level and because of that, my transactions reduced. I think this correlation will happen only if you have your business metrics, your infrastructure metrics, all of them are flowing at one place. And if you have multiple cloud service provider, you have to surely think about some solution which is agnostic to the cloud service provider. And when you are defining this, always you should be able to see inside any cloud, any environment, any app from single pane of glass. And that's the key here. Choose any tool, but think about this strategy very carefully and this is one of the most important part when we are defining the multi-cloud strategy. Also, now the data which is there in the metrics and logs and all that needs to be governed by the rate. So you need to think about building a separate account for operational and application data along with your sub-account with IM policy and all that. And the tools like Datadog and all have similar structure like account management structure that we have in AWS and all the cloud service provider. You'll see that in the Datadog also. So when you push the data, automatically your team will see data only related to your applications. So all of that is important as well. Moving on to managing the Kubernetes cluster across CSPs, lot of tools are available in the market. Rancher was the first one that I was aware of when it started like four, five years back. Google Anthos is like moving very fast in the space where you can manage your Kubernetes cluster across multiple cloud service provider, including on-prem. And if the plan is to move all the workloads to container, this could be a very powerful strategy to go with Google Anthos. And if Google Anthos, Google GCP is in your list of cloud service providers, right? Again, for two examples we have seen, we need to think about all of these individual pieces here and create the blueprint for our organization. Moving on to the last part quickly, once we have set up with evaluating the workload, deciding where which kind of workload will go defining the operating model, governance is important, right? Otherwise it'll go out of the hand very soon. Our philosophy is to always have lightweight governance driven by the technology guild, which is more from the practitioner's view. The people who are on the ground are able to fit back to build the policy or the governance for their overall infrastructure. We say here three steps. First, bring real-time insights. Again, real-time insights is key here. You should not have end of the day insights, right? When your application goes down, you need to know what's happening at the real time. That could be very powerful tool to get the insights first. Second part is to have the automated governance with fitness functions and alerts. So we don't think about saying that, okay, we'll have reports every month and we'll see where the teams are doing. Have the governance in an automation way with defining the fitness functions. Third part, once you have these two in place, why only certain group of people need to do the governance? How we can shift this governance to the development team? So the team are self-governing in a way, right? So every team knows and govern their cloud cost management, for example. Every team knows that, okay, what are the security and compliance things that we have to make sure and they have a checklist that they can go through, right? So all of this, again, with a unified experience which will help to build the cloud agnostic. For example, if you're choosing Google Anthos, then they have a config management, policy management across cloud service provider, but only for Kubernetes as of now. So that could be a powerful way of linking this governance along with your operating model. Now, for example, Dora 4 key metrics is the industry leading way to measure and look at how each teams are doing, right? And how each applications are doing, how frequently we are deploying. So lead time, deployment frequency, MTTR, change fail percentage are the key to measure and that can be measured across the teams. So now this way, we look at all three parts of the overall building the structured way in a structured way, building the multi-cloud strategy for your organization. So the first part that we always talk about is do it only if you need it, right? So now these three will be given most of the time, right? I think data center, we are moving to cloud. So you will first have your cloud set up there and hybrid cloud will be given because you have your workloads running on the data center most of the time and now you are moving the workloads that needs to be connected. So this will be given. We say that this is not that difficult and can be managed very nicely. However, once you start and make choices about polycloud that is still manageable, not too difficult, but I think leveraging the best of the bread is the way. So you are doing your innovation experiment, faster time to market with this. So there is a advantage there. But after this, it becomes more and more complex. So we caution a lot to our clients and that, okay, build cloud agnostic applications. Don't try to overdo by 100%. It's okay to have a 5% duplication there, but doing it that way will give you that flexibility as well as ability to move at any point of time, right? And then comes the distributed cloud for very highly critical applications running across the multiple cloud managed centrally is the way to go there. And that is the most difficult. So most of the time we have realized that when in the industry people are talking about multi-cloud, it is either hybrid cloud or polycloud. Sometime it is portable cloud, very rare, it is distributed cloud. And to achieve all of this, apply the strategy of three tenants, evaluate your workload, define the operating model and have the proper governance structure in place. That's all from us. Rashmi, you want to add something at the end? I think we just have a minute left in case of any questions. Otherwise, you know, you can always talk to us in the hangout. Thanks, Sunita and Rashmi for a wonderful cloud session. So we are exactly on time.