 All right, we're going to go ahead and get started. Welcome, Friday afternoon. You guys made it last session. We appreciate. Woo! We did it, CF Summit. We truly appreciate you guys hanging on till the bitter end to attend our session. And without further ado, let's dive right in. As a friendly reminder, in the event of fire, the exits are behind you. Go down and out. All right, so my name is Cameron Stewart, and I work for Pivotal. My name is Maggie Ambrose. I also work for Pivotal. We're both on the alliances team, so we work with a lot of our cloud providers. And we will be talking about building out multi-cloud applications with Cloud Foundry. We heard earlier on in the summit that 48% of Cloud Foundry users are running across multiple clouds. So we kind of wanted to explore that a little bit and talk about an example use case, an example pattern, where multiple clouds make sense. Yep. So let's talk about the plan. First, we're going to talk about why people are even going to the cloud. We're going to talk about the evolution and the adoption that we're seeing of people adopting a multi-cloud architecture. So we're going to talk about cloud, talk about multi-cloud. We're going to talk about some of the challenges you might face when using multi-cloud. Then we put together a demo application for you all. So we're going to walk through that application from both an architecture perspective but also from a feature and functionality point of view. And in that process of developing this application, we learned numerous lessons. And so we wanted to share with you guys some of the things that we identified as the keys to success. And no surprise here, one of those keys that helped us be successful was Cloud Foundry. So we'll talk about how we really leveraged Cloud Foundry to be successful in this endeavor. So diving right in with why cloud, this seems we're all at sea of summit, so I don't want to preach to the choir too much. We know that people are leveraging the cloud for really what I think it boils down to is the ability to go from an idea in the morning to then running in production in the afternoon. So the time to market is something that leveraging the cloud really enables. And then, of course, the elastic scale so that as your applications have lots of demand, leveraging the cloud and the public cloud allows you to scale out to meet the demand that those applications are receiving in a very quick and efficient way, and then also to scale back down when that demand decreases some. And then workload portability. We're going to talk about this a lot throughout the presentation, but the concept of right once deploy anywhere. And that is something that we were able to do in our application and something that everyone is after. Everyone is trying to achieve this, and using the cloud allows you to do that. So we know that we've seen a lot of popularity and adoption here, but what we're seeing increasingly is people leveraging multi-cloud. So what are some of the benefits of leveraging multi-cloud? First and foremost, choice and flexibility. So you should have the freedom to choose where you're running your workloads. You shouldn't have to make a single decision and be committed to a single tech stack. You should have flexibility to leverage multiple clouds or to move between clouds should your business require that. Geographic proximity. If you want to deploy in a region where maybe one cloud provider isn't currently offering a data center, so you might choose another cloud provider for that reason. And then also data sovereignty and regulations. So within certain regions or within certain industries, there may be data centers that have certain regulations imposed on them. And so the cloud that you're currently using in order to break into that industry or that region may not be available. So that would be another case where you would need to adopt another cloud in order to grow your business that way. And then best of breed services. With the public cloud, something that we've seen is, as they kind of vie for control of the market, what we've seen is the path that they've taken to differentiate themselves between the other clouds is the services that they'll offer on that platform. So a great example here are the machine learning APIs that you can consume if you're running your workloads on GCP. So there's really incredible services that these public cloud providers are offering on their respective platforms. And then resiliency. So this goes back to the notion of not wanting to put all of your eggs in one basket by leveraging multiple clouds. If there's an outage in a particular region or with a particular provider, that doesn't necessarily need to have impact on your overall application because if you're leveraging multiple clouds, it allows you to have a backup option. So that all sounds great, right? All of those benefits are something that are definitely appealing to me. I'll take some of that. But it's not necessarily as easy as it sounds. Some of the benefits that I just talked about can also be quite challenging in order to be successful with it. So with leveraging multiple clouds, you have multiple different environments. And so you can have inconsistency between those environments. If you are consuming those awesome services that are provided by the public cloud providers, you're going to have just different services and how your applications access those services is going to be different. And so all of this really boils down to increased complexity. This is going to increase the complexity for both your developers and your operators because it's going to require that they have a broader skill set in order to take advantage of all of these things, to know how to configure their applications for different clouds, how to consume different services, et cetera. So all of this is going to lead to increased complexity, which as we know, increased complexity slows your overall rate of innovation and your ability to go fast, which is something that we're trying to avoid. So we knew that there were benefits and there were challenges. But we decided we wanted to test it out for ourselves. So we, as Maggie mentioned, built a demo application. And so we tried it. And Maggie's going to take you through that application. All right. So I'm going to take you through this sample multi-cloud retail store application, which we kind of specced out and designed and then built. But first, I want to take you through the architecture so we can kind of talk through why multiple clouds made sense in this particular use case. So as any good business should, we started with our end users in mind. And we wanted our users to have the experience of being able to go to a basic web store and order some teapots from our teapot depot business, which you'll see later on in our demonstration. But this is a simple web store application where users can go in, submit orders, and track their order status. Now, as we continued to design this out, we decided to build out a entirely separate microservice around an order management system. And so this order management system is responsible for all things around order management, keeping track of the order statuses, creating new orders as they come in, and then as the orders go from submitted to processing to fulfilled, keeping track of all that and being able to expose it back out to our end users. And for these two particular microservices of this overall application, we decided to run on Microsoft Azure, on Cloud Foundry, on commercial public Azure. And so we chose the public cloud for these components because we wanted to take advantage of the scalability of the public cloud for some of our user-facing components and be able to scale and demand as well as serve in various regions. What we also wanted to take advantage of in Azure was the Azure Service Bus. So this is the Azure Service Bus logo, which isn't very clear. But we did want to take advantage of that service because Azure Service Bus provides the best of breed messaging service around a lot of these hybrid use cases. And so when our order management creates a new order, we actually publish that order to the Azure Service Bus. And today, since we are just a small teapot business, we have a single fulfillment center. And so along with that single fulfillment center, it is a single fulfillment service deployed alongside that fulfillment center, which we have running locally. So for the fulfillment service, we wanted that to be geographically co-located with our fulfillment centers in the southern region, in this example. And so this part of this microservice that makes up part of this application is running in an on-premise stack. So one environment where Cloud Foundry can run on-premises is Azure Stack. But this could really be any cloud for these purposes. And this fulfillment service is subscribing to those new orders from the order management system. And what we have in our design is the fulfillment service is actually able to determine by itself, in and of itself, whether this is a fulfillment service to fulfill the order. So based on the destination of this order, which is coming in, it will either determine I'm going to ship to this destination or shipping to this destination really doesn't make sense for me, so I'm going to not fulfill this order. And so we'll publish that status back to the Azure Service Bus. The order management system is subscribing to those fulfillment responses and keeping track of that as we go through this process. So like I said, we are at first just a very small teapot business. But we want to see our business grow, and we want to be able to ship to and serve new regions. And so in our design, as we walked through this and talked through this, we said, OK, well, we want to be able to add fulfillment centers on the fly as we go and be able to do that without disruption to the rest of our application. We want to just be able to serve new markets very quickly. And we don't want to be tied into a specific cloud provider. So what you'll actually see when Cameron takes us through a demo of this application is that we're actually able to add an entirely new fulfillment service running in an entirely different cloud. So for our new fulfillment center, which we are adding in the north region, we're going to be running still locally to that fulfillment center. And we'll be running on VMware vSphere with Cloud Foundry, of course, which we'll talk about more, how that helps us out. But once we add this new fulfillment center, we see the process looks a little bit different. So we're able to publish a new order from the order management system. And now we have both fulfillment services subscribing to those orders. And again, each still independently is able to determine whether they are the fulfillment service for the job for that particular order based on the destination. That fulfillment status gets published. And order management is subscribing to those fulfillment responses and keeping track of that status of that order and exposing that to our end users. So that's kind of the overall architecture of the application. I hope that the build out was useful in understanding the need for each of these various cloud providers, the different geographies. And this is really truly how it gets implemented when we go through the demo. So let's see it. All right. So where we're going to start is with our web store. So as Maggie mentioned, we are a small teapot business called Teapot Depot. And we've just launched our new web store, which we're really, really excited about. But currently, we only serve a small local subset of users. So we're going to select our blue teapot as a very popular item. We're going to ship to ourselves in Denver and submit this order. And so right away, our order has been submitted. And so we're going to track our order status. And so this is essentially the information that gets exposed back from our order management service. And it's exposing the values that we communicate with that service. So it's allowing us to know what our order idea is and that our order status is processing. So we don't know which fulfillment center is serving that order because it's running through the algorithm. So if we refresh our screen, we can see that our order status has changed to confirmed and that we're being fulfilled by our southern region. So that's great. We're able to order some teapots being in Colorado. But what if we tried to submit another order with using the pink teapot this time? But if we were trying to ship to New York, let's just say, we're going to have a different user experience. So we go in. We try to track our order status. But because we don't actually have a northern region fulfillment center, we're not going to be able to fulfill this order. So when we refresh our screen, what we're going to say what we're going to see is a message that says, oops, looks like you're trying to ship to somewhere that we don't currently service. Sorry for the inconvenience. And if we expose the values that we're getting back from order management, we've changed the order status on the back end to cancel because we don't have a fulfillment center to service that region. So let's change that. Our business is growing. Clearly, there's demand in the New York region. And we want to be able to make those users happy. So what we're going to do is we're going to do a CF push of our fulfillment service. And while that push is happening, I want to drill into something that Maggie said. So Maggie mentioned that we want to be able to roll out our fulfillment centers very, very quickly. And so we have just a single code base. The fulfillment center is just an application that we don't have to change as we roll out new fulfillment centers. And how we're able to accomplish this to not actually have to change our application to know if it's a different fulfillment center is we provide a different manifest. So you can see here we're using two manifests. We have a manifest for our northern region and a manifest for our southern region. And so if we look at the manifest for our northern region, we can see that we're providing an environment variable to our application. We're setting our spring profiles to north. So this is how we allow our fulfillment centers to self-identify which fulfillment center they are. So it's the exact same application code that exists for a fulfillment center. And then based on the environment variable that we provide it, it enables it to know I'm north, I'm south. So now that we can check in on our push of the fulfillment center, it looks good. So now if we go back and submit another order from our web store and try to ship to Manhattan, what we should see is that when we track our order status and we refresh our screen, because we now have a northern fulfillment center, we should see that our order is going to be fulfilled by that northern region fulfillment center. And indeed we do. So our order status is confirmed. We're using the northern fulfillment center. So it was really easy for us to just take the same application code, deploy it to an entirely new cloud, which is going to be, again, co-located with the new fulfillment center that we're spinning up online, simply provided a new manifest that as an environment variable says, hey, fulfillment center, this is how you know who you are, know what region you're servicing. And we could deploy a new fulfillment center very, very quickly. And the demo that Cameron just took you through is, like I said, behind the scenes. It's architected exactly like we showed. We're using three different cloud providers for these various components of the application. And for the sake of our demo application, we chose simple regions like north and south. But these patterns that we're talking through could be really utilized in any geography. It's not exclusive to just the United States geography. We're kind of mapping it out in this scenario. So we tried it. And here's what we learned. So going through this process, we ran through this very quickly. So in the matter of weeks is the amount of time. And this is also, to be clear, not like a full-time job for us. This is kind of something in extracurricular activity, I would say. So in the matter of a few weeks, we were able to build this out, not even focusing entirely on the amount of our time on this. So how are we able to be successful? We definitely want to talk through some of those things. So to start, the fact that we had development consistency across all of these environments was really, really important and really clutch for us to be able to pull this off. So if you looked at that architecture diagram, we have many cloud providers. We have various services. We have various patterns being used. And we were able to have a single context in which we were developing this application across all of these environments. And that really helped in order for us to be able to maintain the consistency and move very fast. So that was a really big piece. We'll talk about using Cloud Foundry, of course. That's kind of the reason we had that abstraction level. But development consistency was really, really important. And then Maggie talked about kind of the messaging pattern that we implemented for this application. And that was definitely one of the crossroads that we got to and a decision that we needed to make. So we could have, as Maggie mentioned, we were using Azure Service Bus and we were using a PubSub messaging pattern. One other path that we could have taken would be to use a queuing messaging pattern. So the order management service could have queued a message to the queue directly to a fulfillment service to say, hey, you're going to fulfill this order. But while that may have been more simple to implement, what was the ultimate priority for us was to be able to roll out new fulfillment centers very, very quickly. And if we had gone with that approach, all of the logic for deciding which fulfillment center would fulfill a given order would have had to live within the order management system. So it would have had to know of all the fulfillment centers that existed out there and to contain the logic for deciding which one should be selected based on where we were going with a given order. And so in order to roll out a new fulfillment center, you would have had to change that logic within the order management system. So instead of going that route, we decided to do the PubSub pattern so that when an order comes in, the order management service publishes a topic that all of the fulfillment centers are listening to. And that topic essentially is just saying, hey, I've got a new order. Here's where it's going. And then the fulfillment centers are all running the exact same algorithm. Again, it's that exact same code base. But because of that environment variable that we provide it, they're all self-aware of, hey, I'm Norris, I'm South, et cetera. And so based on running through that algorithm and identifying which fulfillment center they are, they also then will publish a topic as a service bus, which the order management service is also listening to. So the fulfillment centers will be able to identify if they are the appropriate fulfillment center to fulfill an order, submit their topic back, which the order management service is listening to, and then they'll be able to say, OK, great. The Southern Fulfillment Center is fulfilling this order. And they'll be able to update that order appropriately. So while it may have been a little more simple to go with the queuing pattern, we decided that, again, the priority for us was to be able to roll out the fulfillment centers very, very quickly and not have to make any code changes. All we have to do, as we saw in the demo, is just provide another manifest with an environment variable. And we were online and up and running. So talking through those trade-offs with various people also within our team, and then choosing a pattern to implement and go with that made sense for us and what we wanted to accomplish was great. But it's trade-offs, right? So various different patterns could be usable with different trade-offs. And what was important is that we knew where we wanted. We knew our business case and where we wanted to take this upfront so that we were able to make that decision very early on before running into a situation in the future and saying, man, it is a pain when we have to roll out a new fulfillment center and update our order management service, wouldn't it be great if all this logic didn't live within our order management service and have to go back and refactor or just live with that decision? So we were able to know that early on and make that decision early on. And of course, a large piece of our success is owed to the fact that we were able to use Cloud Foundry across all of these environments. So let's talk a little bit more about the power of Cloud Foundry and how this really accelerated our ability to create this application and do so in a sustainable manner. So as Maggie talked about, the consistency of environments was key. Consistency across the board was key. So we were really leveraging all of the different abstraction layers that Cloud Foundry provides because we were deploying to different environments on different clouds. We were spinning up services, leveraging services, but all of the interactions that we as developers were going through were consistent. So in all of our deployments, in all of our service provisioning, binding, et cetera, that was a consistent experience across the board thanks to the multiple levels of abstraction that Cloud Foundry provides. So it allowed us to really develop at a very rapid and innovative pace. And we were really, truly able to take advantage of the right once deploy anywhere mantra because of the way that we designed the fulfillment centers. We are truly deploying the same code base to two different clouds and with the externalized configuration that the spring profiles provide, we are able to let them execute their algorithm with the different externalized configuration and come up with their fulfillment statuses based on the same code base. So that was really nice for us, of course, to say we're gonna reuse this piece across all of the fulfillment centers. And in our example, we only grew to two fulfillment centers but you can imagine three, four, five, six as our teapot business continues to grow. This would be even more handy as we grow. And we didn't show this in the demo but we've talked about earlier that one of the benefits of leveraging the public cloud is the ability to auto scale, to scale up and down your applications horizontally very quickly. And you could even leverage a service like the auto scaler so that based on whether it's a threshold like demand or if you wanna set a schedule, so if it was gonna be national tea drinkers day and so we would expect all of our friends in Europe and Asia might wanna buy some fancy teapots from us, we could scale our application in anticipation of that event. So, Cloud Foundry and the auto scaling capabilities that it provides would be very useful for us in this business case so that we could scale our front end to accommodate all that demand and accommodate all those users. And from the resiliency perspective, again, kind of goes back to that consistency and that abstraction layer, but we know that Cloud Foundry provides our applications with a lot of resiliency capabilities built in, self-healing, at the infrastructure layer, we have VM resurrection and things like that provided by Bosch. And we know that across all of these different cloud providers we are getting those levels of HA without any extra tuning or configuration at the IaaS layer, but we have a lot of the resiliency built in across the various different cloud providers and our teapot business is not at risk of failing for our end users. So the resiliency piece of CF is also really nice. So that was the plan, we covered it. Again, thank you guys so much for holding on with us, hanging out on Friday afternoon. And this is just one example of a pattern that could benefit from and leverage multiple clouds. I'm sure there's many other patterns and many other use cases that maybe you all are implementing or working through yourselves. So it would be really interested to hear about that after the session. So thank you. We'll be around. Thank you. Also, a little bit of a plug. You probably have seen this slide before, but there's no better practice than marketing another conference while you're at a conference. So if you want to talk more about all the Cloud Foundry goodness and Spring and all of that, Pivotal has a really awesome conference that they put on. It's gonna be in DC this year and it's happening in September. And if you want to be one of the lucky ones that gets $100 off, you should snap a picture of this discount code and come hang out with us in Washington in September. See you guys there. Thank you guys.