 Welcome to this session on Instant Multi-Cloud and how to make it happen. Does anyone, I guess, who thinks that's a major clickbait title? I love it. Well, at least we got your attention, right? I'd rather you be in this session than another one. That's the fact. So, let's get started. This is kind of what we'll cover today. There is going to be a demo. We're gonna try to not inundate you with more than roughly 10 to 12 minutes of slides and then walk you through what this could look like in a very simplified manner. I don't think if you have already experienced OpenShift in the cloud, Kubernetes at all, that you'll have any sort of mind-blowing moments through this presentation. But what we're showing you is the art of the possible with the fact that you can throw two of our managed service offerings together in different clouds and achieve some very interesting results. So, we will cover who we are, why multi-cloud may or may not be good for you, some things you might encounter that could be qualified as speed bumps on the way to trying to do something like this and things that might entice you or disentice you from doing this at all. This may not fit everyone. As with many things with cloud architectures, it might be good for you, it might be bad for you depending on what part in the journey you are for adopting cloud in general. If I'm not mistaken, our talk might be the least hybrid cloud of this conference and the most cloud native. And I'm not trying to be special, it's just that this fits a different customer profile than what Red Hat I think normally would be nudging people towards. We'll cover kind of a short part in here about some progress patterns which will cover sort of a timeline where you might be able to identify where you see your org in making progress towards a multi-cloud architecture. We'll cover the architecture itself that were described in the demo, we'll do the demo itself and summarize and hopefully have some time for Q and A. We have a good bit to cover though. So Jerome. So nice to meet all of you, my name's Jerome Buto. I've been at Red Hat for about 10 years and I'm focused on Azure Red Hat OpenShift. Also a fun little fact that I like to climb rocks and I cannot stop you from telling us so. And my name is Aaron DeYoung. I'm a product manager for Rosa. I've been with Red Hat for about two and a half years now. I am not a Boston local but I do like Nutella and the one thing I think we share in common is that not just Nutella but we happen to speak French but I don't think we'll be doing any of that today. So why would we wanna use multiple clouds? Let's get right into it. So everyone will have started their journey with one cloud over another. You more than likely have a specific set of strengths in that first cloud that you dove into. You will have secondary clouds that will feel very foreign the first time you dip in to the second cloud. Ideally by the time you've reached your third cloud it's all fair game for you and you've mastered the art and you don't need to be here listening to us but at least prepare yourself for the fact that it may be a slight shock to find out that things differ between your clouds. Other reasons why you might use more than one cloud at the same time is to take advantage of the simple things. Special features, strengths related to particular sizing of instances that might fit your workload really well. In other cases it's about expanding your map of resilience. You currently might look at a singular cloud or your private cloud as having just you've got your region and you've got your availability zones. Those are your three failure domains. Now you could argue you could expand that sort of capability to accommodate failures to a point where if you have enough failure domains and you know how to fail across them appropriately you might not even feel them at a certain level of scale. Now you could argue this could be for very large customers or for startups that are doing this fresh and throw fresh talent at it but I think nonetheless it's interesting to think that once you reach a certain level of scale there is a lot that you can accomplish. And then other reasons why you might use multiple clouds is something as simple as acquisitions. Some people want to go based on technological preferences, whatever have you. Let's be honest, that's what drives sometimes a lot of those choices. Any thing you want to add? I mean and obviously the commitment you have with a cloud provider, sometimes you commit to your committed spend and you're going to get this counts based on that and because of that you can decide this next workload or maybe a lot of my workload and you go somewhere and then the decision can change. Like it's not because today you make a choice to go somewhere that tomorrow your next decision can be somewhere else. I kind of like the analogy I've heard from someone once regarding single cloud. Having single cloud forever is a lot like eating at the same restaurant when more than five are within walking distance or on the same block, you're probably missing out if you're sticking to just one cloud. And some interesting stats among many, 70% of orgs are now at least multi-cloud and that includes hybrid, which is good news but that's a relatively high number especially given that it was a small grouping of customers. Onward, so why it might not be good for you? Do you want to go ahead? Yeah, so like we were talking about why you would but the reality is actually let's take a poll. How many people are using multi-clouds today? Bravo. So that's good and some people are but it's a minority. The reality is there's some complexities there. From an infrastructure standpoint you have to learn about all the clouds. You may have different teams that have these expertise. That's gonna take time to acquire that knowledge. There's also areas of lock-in but also flexibility that comes with multiple clouds. So like you use multiple clouds, you want that flexibility but you might already have that lock-in today because you have a commitment with the cloud and based on that cloud your operational excellence is gonna be a single cloud. In the future you may want to have more than one but you haven't been able to expand on that area. And the other part that sometimes is operational so you may have the vision of being able to multi-cloud but how do you get there? Where do you start? How do you think about it? Where do you think of like which team are gonna start going to that journey? Because it is a journey, you have to learn about the environment. And so sometimes that causes teams to just say you know what, this is too hard to start today. Even if sometimes regulators may say you need to have multi-cloud options but the reality is it may not be something you can do today. So have patience. This is the type of journey where you may be locked in due to things like compliance. And the fact is you may never unearth from that original cloud to move to more than just one. I would say any org maybe within the next 10 years is it would be probably, I think we could say it would be a surprise that they wouldn't be in more than one cloud within that time. And I think the one thing that is common from everyone I've at least spoken to just at Summit so far is that they are looking at more than just their private data center now. And so that tells me that the moment you make that step from private data center to the next cloud or even your first, you're effectively doing multi-cloud at that point. So could it be for you? Are your staff willing to expand their skill sets? This is a fair challenge everyone will need to fight with. If your current org is not ready, what will it take to make that happen? It's ideal to skill up your staff, not just for them to want to stay because you've invested in them but so that they can reinvest back into your company. Would existing silos slow down adoption? That's, I think everyone is battling with silos one way or another. There will be a convincing period where you've got silos that are not bought into doing cloud at all. I think the best way to show that there is success that will convince these teams is to have at least one team that has done it even in a POC format initially. That will give everyone kind of the hints that they need to realize, hey, that there's something to this and there's a lot to gain from going beyond just our private data center, going to cloud and then making that step to secondary cloud for all the benefits you can reap. Do you need scalability and capacity? Who, does anyone here not need scalability and capacity at this very moment in their org? It's okay, I'm really happy you guys didn't raise your hands on that one but that's the easy answer for most orgs. That's why we're all at this whole conference, I think. There's so much cloud coverage but this is about gaining scalability and capacity beyond where you're most comfortable and dare I say in some cases we can look within oneself sometimes and say perhaps complacent. We should try and reach beyond that and get to a point where we can leverage more than the tools that we're already comfortable with. Anything else? Yes, the other thing to keep in mind is when you do go on this journey be aware that at least at the beginning there's gonna be a learning experience that'll take place and so that initial team that has to figure out take the approach, figure out how this other cloud works may take a little longer but that cost, the initial cost is worthwhile because future adoption will be made easier. Absolutely taken into consideration that one cloud will have a certain set of compliances, another one will not and maybe the reason why you've not yet jumped over there go and communicate with them because the fact is if your workloads make sense to be in multi-cloud architecture or across more than one cloud at all, every cloud is willing to take your business as we all know but the fact is is if no one knows that you're trying to do it no one will try to help you do it either. So take advantage of the relationships that you can forge even just in this ecosystem of this conference alone and find someone from a cloud that will help you on your journey even in those first few steps. So it is easy to have your hands full, different tool sets. We've got so many options with Service Mesh today it makes my head spin. There is a cost to being, to having this much variety of options. It almost causes decision paralysis as we may already be familiar with just in a singular cloud. We at Red Hat always would argue that the development tool set will always matter. You should always ensure you've got a consistent experience for developers. There's been always this huge focus on operations but the developers that put those apps live are their lives matter as well. Absolutely, are there any devs at heart in the room? Good, I'm glad there's some representation. And the fact is is it's difficult to adopt new clouds if there is a diversity of tools. OpenShift is always pushing for that fact that it's got the consistent experience and wherever you can abstract away the underlying cloud's differences that would help teams with adopting a multi-cloud architecture. Some of the other ones here are very obvious. There are unique new sets of training and certification to deal with but it might sometimes even in regards to certifications or training, get some initial training. Some teams might not have the taste for saying oh, I've been certified in AWS already. Why should I certify in Azure now? Well, the fact is you can train up to near that cert but the investment to the cert itself maybe find out when that's important for you rather than investing in it right away. Gaining the knowledge now is great but it may change by the time your teams are ready to actually certify. Anything else? I think you covered quite a bit of the complexities that you might perceive initially until you get going. Yeah, so some goals to aim for and some of these are absolutely maybe a little bit hand wavy and in some cases we have still found with interactions with some customers are not quite as common sense as some of us think who work with it on the day to day. We would say to avoid decision paralysis look for a consistent platform, hint, hint, nudge, nudge, right? Kubernetes and automation together will address infrastructure complexity by abstracting it. If you're already working with Kubernetes, congratulations, you've abstracted infrastructure enough so that you can get applications in the cloud. Now we're gonna argue through our demo you can take it a step further. Are there any others that are not there but? And some of this is like you should set a goal for the initial team. So I think of this as a goal setting like you wanna learn about the infrastructure, learn about the environment. What are the important components that you want to have to be the same and which ones you're willing to be different? And going back to what we were talking about earlier what are the things you wanna take advantage of in each of these clouds? Is it about the services are unique in this cloud? Is it about the ecosystem? Is it about the instance types? Whatever these things are that you think are important make that list that you identify these as the things that you need to learn about as you start that journey. If you have access to a turnkey platform, thousands of hours have been invested into making it work, run and operate. Take advantage. That is the beauty of the open source platforms that have been built and put together. Take advantage of turnkey platforms. You may not be looking at, you know, Rosa or ARO right away. But if you can get used to and get accustomed to running AKS, GKE and EKS all in, you know, symphonic fashion, you're one step closer to honestly being right away multi-cloud right there and taking advantage of all the benefits that could be available to you. So beyond goals, I would just like to point out that Red Hat's presence in the primary cloud providers is essentially solidified at this point. I'm sure we can obviously always make some improvements. But I think maybe there's some underlying message with us making the on-premise one so tiny versus the logos, right? But nonetheless, you can trust in the fact that we have an open shift that can satisfy you in the three clouds plus one. Here's where we're gonna cover sort of the cloud progress pattern. There's three slides here. And essentially the pattern here is to get a look at where you might be on this journey. And what you see here is there's this section way left where you see in the red, you know, when you're in your on-prem data center. And on the far right, you've reached second cloud and then somewhere in the middle you're in your first cloud part of the journey. Now, this is not by all means a one size fits all scenario but it is something that we've observed some customers go through and through a lot of data gathering we can kind of figure out this tends to be what people hit and what some people trip on and some things where some people could improve. There are, so the three that I was talking about there's the good, there's the rough and there's the better. The rough, I would like everyone to just have a quick gander and say, am I in any of these red blocks? The one that I think I want to pick on the most is the lift and shift. How many of you have heard that muttered in your org before? Did it bother you? So, I don't think it matters which partner I talk to or which customer I talk to. At the end of a lift and shift everyone is generally unhappy. When you're doing a cloud, a multi-cloud progress sort of journey if you will, ideally you don't do a lift and shift, ideally. I admit that's a little hand wavy. Ideally you don't do a lift and shift. You need strong chops in automation and pipelines. You may already know this, like I said this isn't a mind-blowing presentation it's kind of re-solidifying what we've seen and just sort of representing what we think everyone should try to aim for. You've reached multi-cloud once you've done on-prem plus first cloud. Let's call it that, let's give yourself a buzzword and pat on the back. By the time you've hit second cloud you've arguably hit cloud maturity because you've dealt with the abstractions of going from one cloud to the next. The benefits you see here I think speak for themselves in that some of the stuff up top is about serverless and innovation time that's extra time that you've gained hopefully as a result of not getting stuck in the cruft of what happens in this kind of timeline. I really hope none of you have to deal with the hell that could be considering reverting to on-prem. If that's something that you did, that's fine. It may not be the journey for everyone. We're not gonna scold you but the fact is is it would be horrible to have wasted all that effort. There's many ways to hopefully avoid that. This whole crash and burn scenario could be worse, could be a lot better but I think the message is relatively clear. Good is good but there's still no time for innovation because you're still busy with familiarizing by your second cloud and better is better because let's be honest, you have two product managers from Managed OpenShift. We're suggesting you get Managed OpenShift along the way so we're honest here but the fact is if you've taken away the operational overhead, you've been left with the time to do other things, ideally. Do you wanna speak to Divert? Well I was just gonna note something on the previous slide. The beauty about OpenShift, it gives you that consistent platform. So I saw like the other patterns required to relearn every time you go different cloud. By using that consistent pattern, consistent experience, the developer can deploy the same application in one environment and then the next environment without having to learn new skills or minimal new skills. And so that gives it that both accelerates the time to get to multiple clouds and also makes it easier to get there. So just in the interest of time I kinda wanna bubble over these really quick and get to our demo. So the fact that you could use a Managed Platform to divert operations burden from teams, I think everyone understands that there's a benefit there. The whole point of this is we want to encourage that cluster provisioning, putting a Kubernetes platform in the cloud should become boring. You might think, well, shouldn't it be exciting? For some of us who are hardcore nerds, yes, it'll always be exciting. You put a cluster of bits together that happen to make other bits work together. It's fantastic. But the act of provisioning multiple clusters and operating them should become back of the hand easy. Very quick, simple, boring. Because then you can focus on that innovation time and focus on making developers' lives easier. Some would argue multi-cloud needs a complex architecture. Not always. That is essentially the thesis of us getting to the demo. Another item I just wanna quickly harp on is think automation and pipelines instead of migration. If someone says migration, make that a bad word in your org. Migration is from the days when we had VMs to move between hypervisors. The cloud doesn't need that anymore. You've heard the terms cattle, not pets. This is that mindset and sort of culture shift that you need to perhaps encourage in your orgs for this kind of scale adoption. So next time you speak to your groups, your teams, and someone says migration, maybe you say, hey, let's stop using that word here and then instead think of automating deployments, pipelines, and for those that simply must be migrated, take it with a grain of salt, I guess. We're gonna move on to our demo. We put it into video format because we understand the wifi here could be unreliable, but this is in short the, as general sort of bubble-like architecture, we can show you for what this is. Essentially it is our OS toy application, which you may have seen other demos from Red Hat do, that is deployed via a pipeline, which happens to be GitHub actions, and it deploys its image to Quay. Quay then, upon deploying with the GitHub action, sends the image to whichever cluster I want to deploy to. In the end, I've got any sort of solution here that can load balance the access to the apps across the three clusters. This is a very basic multi-cloud architecture. Could be adopted for some very simple applications and prove the point in a proof of concept to your org that this is indeed possible. And if Azure has a bad day or AWS has a region outage or Google happens to be doing something funny with DNS, I can rely on the other two clusters keeping my app up. Now, before this sounds too hand-wavy, this kind of works better if you've got stateless applications, AKA ones that don't need persistent volumes, so that the persistence has to be synchronized across the clouds. That is still something that across the cloud providers is still considered relatively a dark art replicating data between regions. This is why people sometimes come up with funny concepts like doing a stretched open shift cluster I was reminded today. These things are scary. Let's try not to encourage that kind of pattern. Let me move right to the demo here. I do wanna put some thanks to the two gentlemen who helped us build the demo environment and prepared the video with us so that we could show this to you exactly what it looks like. That's August Siminelli and Garav Mida. This is the GitHub Actions Pipeline. The first part of the deploy is a GitHub Actions Pipeline that is prepared for building and pushing to Quay deployment to a Rosa cluster that is considered the dev environment and then later on in the deployment to a production Rosa environment. So this moves forward and within a matter of seconds you can move applications in a pipeline fashion like this between multiple different clusters. So over here, this is the Rosa cluster that we're showing and if in case the branding happens to go in the way and go away on the upper left, we will show it in the OS toy application which can tell which distribution of managed OpenShift we're running. You can also try to discern it from the URL if your eyes are 2020. So the developer application now that it's deployed it's on the way for being deployed. We would trigger it by running the workflow in GitHub Actions a little here. So here it's building and pushing to Quay. That takes a couple of minutes. I'm gonna scrub it forward so that we're not waiting for the build to occur. But here we're starting to see it show up on the Rosa cluster. The entire deployment believe is only two pods. Yes. And then you can see we've got a service. A route will be created, open up the route and you'll see the OS toy application show up currently running on the Rosa cluster. So this is the dev or the prod environment. The same application is going to be pushed to production. So we're gonna look at the production cluster. Here's where we're sort of doing in GitHub Actions you can do an approve and deploy to the production environment. This is the Rosa prod cluster. The deployment is coming in as a result of the action right now. OS toy comes in exact same application deployment. Here it is running on Rosa in the prod environment. Now the next step is to kick it into ARO. I've decided my environment in Rosa is great. I wanna take advantage of the fact I recently procured ARO at some sort of discount. Maybe there was a sale. And then all of a sudden I wanna just plug it into the new cluster. And that would be going into the GitHub Actions pipeline and you'd need to pre-authenticate that cluster with your pipeline so that what you can do is do something like this where you choose which cluster you're going to. Put in your looks good to me. Release it now, release the hounds. Approven deploy and we're moving on to our ARO environment. That is this one here. After a few seconds it shows up in the ARO cluster. Route shows up for it as well. We see OS toy running on ARO. The exact same app deployed within mere minutes to three different clouds. We're at two so far, we will get to the third. Here's our GCP deployment. Same deal, pick the cluster. Put in the message that says things are going and approve and deploy. This environment moves forward into Google Cloud. Here it is building. Route is created and just there before we refreshed there's our OSD app. So this is OSD you're on GCP. We now have within minutes and even though I was scrubbing this whole video is only six minutes long was recorded in real time. So you can effectively deploy the same app to three different clouds in an under 10 minute span. A little hand wavy but assuming you have plugged in your pipelines to all the relevant environments where you wanna deploy your app. Now there's always gonna be that prep to take into account for but the fact is I have a consistent OpenShift cluster in all three clouds and I've deployed the app and at this point it's autopilot and you leave it, if we're gonna throw some grenades over the wall which is a faux pas but it's a bit funny to use sometimes. If the apps are running at this point I'd love to see one cloud go down and then suddenly I'm still live. So as the load balancer refreshes we'll start to see here that every time you refresh we can sometimes see a different cloud every time. As you can imagine this needs to be stateless again in order to accommodate something like this. If you wanna go stateful you have to engineer some sort of replication solution but that is all three clouds behind the same sort of load balancer and I believe in this case they were using front door. That's right, front door has a gateway to direct to any of the clusters. You could use cloud front, cloud flare, et cetera, F5 and achieve the same thing. So nobody's mind should be blown, everyone keep it together. Fact is we've exemplified that this is not witchcraft, a dark art, it's not incredibly complex anymore. I think it's safe to say in this day and age that achieving multi-cloud is realistic. I'm just gonna bring back our presentation here. I think I know where you're going. It absolutely could, it's just another way of achieving it. You could have Ansible event-driven automation do these deployments for you. You could have Ansible without event-driven automation do these deployments for you. You could have Ansible do this instead of GitHub. It is up to some preference here, right? You're pointing, this is the simplicity of showing that you can do this by using, please, not the term migration, but by automating your deployments into pipelines or whatever have you so that you can get the same app deployed everywhere. Let's say this is something a little more weird and very weird like OpenShift releases version five and everyone's like, oh crap, what do I do now? By the way, that's not happening as far as we understand. It's not a matter of migrating to new cluster versions. It's a matter of redeploying with pipelines. So I think if anything, the major takeaway is if you're not comfy with automation and pipelines, that is your next step to getting into multi-cloud. I'm just gonna advance this forward to some other points that we wanted to cover here. We did cover this architecture a little earlier, but in its simplest form, this is what we've achieved, getting your app from your end to the platform so that it serves your customers. Engineered correctly, avoiding migration as much as possible. This is effectively what you can achieve just as well. Could it be as little as two clusters? Yes, maybe you don't need the grand lavish scale of having three clouds under your arm and you simply need two clusters in different clouds for various reasons. Maybe there's certain GPU models that your app works better with on Azure. Maybe there's certain scale or network capabilities on AWS that you need specifically for certain apps. Sure, but at the same time, there was always some apps that you could scale across multiple clouds and take and reap in the benefits. Any, you wanna add to this one? I mean, we obviously think OpenShift is a great solution, but if you don't go with OpenShift, there are other ways, but to Aaron's point, the pipelines really are the tool that's gonna help you get there because that really creates abstractions that you can direct it wherever you want. I think at this point, I think the message is relatively clear, make migration your anti-pattern. This is more of the art of the possible rather than what you've currently dealt with regarding complexities. I think we're pretty good with what we've covered and if we'd like to dive into Q and A, that's entirely fine, I'd love to. And there's some other talks from other members of the cloud services team I wanted to highlight as well that are worth visiting. So I guess if you wanna go, you can, but if you wanna do some Q and A, we're open to that in the corner. Where are the load balancers running? So that's using Azure Front Door and Azure Front Door is an Azure service which allows you to load balance into any of the clouds. So it's actually running in Azure and then redirects to any of the clusters. Yeah, you probably use something different. I mean, it can be as simple as DNS that just directs to different URLs, different places or as complex as some other load balancer that you can implement yourself. Yeah, if you're relying on the OpenShift routes, then that is still each cluster has its own route that you're forwarding the end game load balancer to. Some people call this global load balancing. At some point, you need to choose one cloud or one service somewhere that will aggregate all of your endpoint clusters. At some point, you may have an affinity to one cloud for a particular service by all means. You may have certain reasons to choose one over the other. There were some other questions, yes? Yes, so databases are a unique scenario. You could, in some cases, rely instead of, I mean the pattern that a lot of orgs will use is, yes, as you say, rely on a database. But if you take that a step further and look at consuming, for example, a cloud offering or it's a managed database and they handle scaling it to whatever capacity you need, or use the larger offerings from the clouds that give you nearly infinite database operations per second that could accommodate having one database be back here with your app that feeds all situations, that is one way you could accommodate that. That is not quite the same as having applications that are stateful, so that's a differentiator. Stateful applications is insinuating that I deploy something on my Azure cluster, for example, and that singular app instantiation has its own persistent volume living in that cluster which immediately deviates from the state of the same app in this cluster and this cluster. That is why you would need a replication layer for that data, for persistent volumes. Databases are the unique situation where you could sort of navigate around that. So that was a good question, thank you. They're all good questions, frankly. Any others, yeah? So just for our example, Rosa was the first one. It could have very well been swapped in any which way you want. I could have had arrow been my first deployment and then it was simply my choice because I've been, maybe arrow was my first cloud. And then I've chosen to make arrow, for example, my production environment and then I started to do dev environments in AWS in Rosa and then I chose to expand those off to other clusters, right? In some scenarios, people are doing not large multi-tenant clusters but they might be doing small clusters for a small set of apps, right? Each of those could have their own globally load balanced endpoint or you could get a really smart endpoint that gives you ways to divvy that up however you see fit. Any others? Yeah. Do I have the YAML file for the action? I could probably get it, yeah. Yeah, GitHub actions are really nice because it's very close to your source code. Infrastructure as code is a beautiful thing. Anyone who agrees that infrastructure as code is a beautiful thing? And if you've not figured it out yet, have a read into it because the fact is that is another gateway to making this more possible. Any other questions? Yes. Did you both? I think it depends on organizational structure. For things like this, I think having advanced classroom manager that give you a single pane to see all the clusters is really helpful but in some cases some customers don't have that knowledge or haven't implemented those things. So it kind of depends and in our case it's just easier to just have each different clusters that we can show you the different clusters but it depends on what you want at the entry point. I'm just quickly throwing this up here because I promised marketing I would do this. Fact is there's a lot of benefit to doing as you've seen proof of concepts for environments like this. Take advantage of the fact that you can rejig subscriptions into consuming cloud services and see if this works for you, all right? And it turns out that with a 75% discount, I mean, that's ridiculous. Are we allowed to have that much of a discount? Okay. Wow. This is for ARO or ROSA. I hope, I think that's it. Yeah, great. I hope you guys have enjoyed it and we'd be happy to talk afterwards if you wish. Have a great summit. Thank you.