 Welcome everybody to this session on designing for multi-cloud. My name is Mark. I'm a product manager at Pivotal working on the service properties with the public clouds. Our team developed the service broker for AWS. We'll talk a bit about that in these experiences. Google is here later in this week. They're going to present their service broker and demo that. And we've been working with Azure as well. So by the end of this year, they probably will have service brokers connecting to all of these three clouds. A little bit about what is multi-cloud and why it's important. This is the Wikipedia definition. Multiple cloud computing services and a single heterogeneous architecture. And you'll see that as we talk about the examples that people are using this fairly loosely, we're not trying to say that multi-cloud is something where you want to put all the applications distributed across them. People are using multi-cloud in certain ways. The main objective was to reduce reliance on a single vendor. So reduce lock-in. But in fact, people are using cost as a justification to move to another cloud. And people are using fitting the workload to the services in particular cloud as a reason for moving. And this differs from hybrid cloud, which is really a deployment model. So this is not about deployment models. Because there's a single vendor cloud that can give you those different deployment models. This is not using different clouds. We'll have some time for questions at the end. This is probably the most important point I want to make today is that a cloud strategy provides you and enables economies of scale. But a multi-cloud strategy enables economies of arbitrage. And part of the reason for that is that today the difference, the spread of cost for a set of compute instances varies by as much as 80 percent across these cloud vendors. So there's a lot of opportunity for you to, instead of paying a dollar, pay 20 cents. And you have to be able to ready yourself to move for the right application. While your businesses will demand multi-clouds, it's cheaper, right? And the cost of cloud computing has been dropping over the years. More than 80 percent, typically, of your cloud costs are compute resources and the charging granularity between providers. Some people charge by the hour, others charge by the minute or by the second. So the cost can make a big difference. And you'll see that your competitors will already be moving to this model, especially in North America. Clouds are still emerging here. In terms of having it geographically available. But the same issues will happen here. Give me a few examples that you may have heard about it. Dropbox, which was actually implemented in public cloud with HB's assistance, has moved to hybrid cloud to reduce cost. Now they haven't moved everything. They've moved a portion of it. But this is the kind of use case where people are moving from one cloud to another provider to lower cost. Johnson & Johnson is another example. A Fortune 100 company moved a lot of data to AWS, Azure and NTT. And they have no mainframe now, right? Imagine that. And they plan to have 85 percent of their apps in the cloud in two years. And in an example where customers are using new services in the cloud, GCP came out last month with preemptible VMs for 20 percent of the cost of a regular VM. And already a number of customers have found ways to use this to move their workload across clouds. And they can actually move it back and forth as necessary, not every day, but as the context change. So what is the pattern of usage that we're seeing with customers who are doing multi-cloud? They're choosing two to three cloud partners, not one, because that's lock-in, not five, because that's too complicated. They're focusing their efforts either on something that's highest cost or something that's highest growth. They're trying to fit the workload to the cloud service, right? And that's an important part of this. And they're learning how to leverage new computing infrastructure offerings, right? So for example, we talked about the preemptible VMs, new services came out. This is a number of different customers who've moved to that. I want to talk a bit about cloud brokering because that's really the approach that we're using. It was identified by Gartner in 2009. And they identified different types of brokering in a mediation where you were providing the same kind of service wrapped to your customer aggregation where you were combining some services and providing it to the customer. An arbitrage where you were essentially taking compute from one and finding a cheaper cloud. And they thought this would be a business rather than software, right? So if you're a cloud broker, how many of you are there in the room? None, right? So Gartner just always get it right. But they thought this would be a business and really we're building this cloud brokering capability and kind of family space. So it's not a business, software is already disrupted this way. So I don't know how many of you are familiar with the service broker API. There's a few. So I apologize if you already know this stuff. But I'm going to walk you through the concepts of what we've done because using multi-cloud fits really, really well with the service broker concept in Cloud Foundry. So a service broker is essentially something you write once. You write one service broker and when you install it, it can have multiple services. So the approach that we've taken, that everybody's taken in Google and Azure is you install one service broker and it will install the cloud services for that particular cloud in your marketplace. So if you install two brokers, one from AWS and one from Azure, you will see in the marketplace side by side services that allow you to go and create from the CF command line, a database in RDS, one AWS or a database in Azure. And that's a pretty powerful concept, right? You as a developer being able to select which cloud you're going to use. And customers are starting to realize that maybe they can use Google for development or GCP, but maybe their production environment is not AWS. These are cost decisions they're making, performance decisions. We're going to talk about service plans because each service can have multiple service plans. And we'll talk a little bit about how DevOps is simplified by this and made more secure by this. Because one of the concepts of all of these is how do you manage credentials, right? So in the service broker, the broker actually keeps the credentials. The operator installs the broker. The developer never needs to worry about credentials. You're just going to go into your command line. You've already been given access to an organ space. The broker already knows what credentials it's going to use and it's going to tag them with your particular details, right? So it really simplifies setting up anything in AWS or in Azure or any of the clouds. We're going to talk about each one of these. But let's start with the service brokers. There are four operations that are kind of difficult for the service broker. Create service which creates your database instance. Buying service which is binding your app and getting credentials back from the broker. Unbinding service and delete service. And then CF marketplace is really where the broker places the services into the marketplace and you can list them all. So the service broker can implement multiple services each with multiple service plans. And really these service plans are custom or predefined configurations. So think about what you can now set up as an operator. We have customers who want to define their policies. So for example, they want storage encryption across the board. Or maybe they want storage encryption on certain plans. They can go in and actually declare that as a specific type of plan. So you can have a configuration of use for development. You can have a configuration that would be used for production or several configurations. And all the developer has to do is pick one. Say I want to use that plan and it gets created along with all of the settings and the VPC, the security groups that you would use in the typical file. So that makes it very, very easy for you to list what services are available, what plans are available and go off and create those. Basically this provisioning is a feature that was added in the last year that really makes it possible for us to use this concept of go provision something and then check the status. So it enables you to create resources, BNs, databases and check on the status. And the other concept that we had a lot of interest in was being able to add what we call arbitrary parameters at the point at which you create the instance. So a lot of times the operator has set up plans that maybe aren't quite perfect for you. You want to increase the cache or you want to increase the size of the database. And so being able to create instance type time, change the parameters to something you can do in the fly on the command line. So you can see here that you can add tags, we can pick a region, we can change some of the things in the broker when you're creating the database instance. The other concept that kind of came up and we've leveraged service keys in Cloud Foundry is that app developers sometimes want to do more than just create the database instance to delete it or buy it or run it. They may want to list the tags on it, they may want to create a snapshot of the database. And so we can use service keys to get temporary credentials that then allow you to use the database Cloud CLI. So in the case of AWS, you'll go off and get your keys and then you can use that in the existing AWS CLI. What this gives you is a consistent experience for DevOps. So PC app operators again can set policies and create the service plans. App developers use existing create, bind, update and delete commands. And then you can do one-time tasks and other management via service keys. So one service broker provides multiple services for Cloud and that's what you get to multi-cloud. Now there is a bunch of activity going on in different service brokers for multi-cloud. We've got the Pivotal Cloud Foundry service broker for AWS that we're building. We've got the Azure service broker which is in GitHub with open source. We've got the service broker for GCP which they're going to demo here this week and they're going to release that I think next month but definitely by end of year. And we've also got AT&F which has an open source service broker. I believe they only built it for AWS at this time. So just to kind of summarize in terms of multi-cloud you can build your own service brokers as well. There's no constraint, it's an open platform. Anybody can build their own service broker. We have customers who built their own AWS service brokers and are using our service broker for other services. Cloud Foundry is the best platform for enterprise workrooms and multi-cloud. Make sure you tell everybody that. We want you to adopt and use service brokers look for cloud R&T opportunities because there is a lot of opportunity today as you move it to cloud to figure out which cloud and which service to put your applications on. And ask me and others about multi-cloud here at the conference from where we see the trends today. North America customers are a little bit further ahead and using multi-cloud. But the costs of savings, the arbitration opportunities, the workloads, the performance means that that's going to come as data centers get built here as well. Thank you. A question. So I think there's a mic somewhere in the room. Feel free to just put your hand up if you have a question. Can you also share some problems or challenges you've faced when moving from one cloud to another? So one of the things that gets more complicated as you have more clouds is reading the security aspects. Because you really don't want to just go ahead and use a cloud and have public access to your databases. You've got to set up your private connection. You have to set up firewall rules. So setting up the security and learning that security for each of the clouds you use is important. And it is different. So fortunately, the cloud providers are pretty good about giving you best practices. But that is definitely one challenge is making sure that you have the best practices in place for each cloud. I'd say the second challenge is probably around the maturity of these clouds. So not all the features that you'd need are available on all of that. They're coming, but none of them are. And tagging is an example that is absolutely critical for anybody on AWS. We have enterprise investigators who refuse to install this without tagging because they need to know what instance when they have a thousand databases and compute instances, they need to know what application is using it. So that's available on AWS Azure right now. GCP is still going to add that. Different clouds have different ways of grouping applications. So that's a consideration as well. But it's a trade-off. Like right now, there's a big value to using some clouds in certain ways. You'll see a number of instances with that. Have you really found companies to save money by being multi-cloud? Because like when I'm observing prices, they all seem to be going down in a very short term in the same way. So the prices are going down, but the spread is literally 28,000. So you can get essentially the same amount of compute for 80% less. So that's a big saving. So especially when you're using a lot of compute for machine learning or model training and things like that. Yeah, storage is not as big as compute. The storage costs are pretty minimal. It's the compute costs. Pretty much everybody is 80% to 90% compute cost. So this was about service brokers and how about the elastic wrap time? I mean, this is where the application's from. Yeah, so for us, the service brokers are actually written as apps. So they run in the elastic runtime, right? So they get all the value of elastic runtime. But we don't actually do anything fancy. We're just a regular app that runs in elastic runtime. So the elastic runtime is still in one cloud? Yeah. For each foundation or cluster. But if you're running in different clouds, then there's one running in each cloud. Let me ask you a question. I mean, how many of you are thinking of using multi-cloud? It's going to be a show, man. A small number, less than 10% at the moment. It'd be interesting to see that in a year. It will be higher. It's a lot of buzz on service providers. Some of you are service providers, yes. So you really don't want anybody else's cloud. You're just only yours. It's going to end up very much the same way that people do run their internet and they buy one line from you and one line from the other. That's why you don't see. That's kind of what is going to happen on top of today. But in the short term, between now and then, when it matures, there's cloud arbitrage is leading the game. There's a bunch of deals. People are moving. People are using multiple clouds. The multi-cloud is definitely a thing that's only going to get bigger. So being able to use Cloud Foundry as the platform and being able to write your own service brokers or leverage service brokers, that's really where the innovation is. The productivity savings is going to be being able to leverage other people's brokers rather than having to write your own. That's a huge, huge plus. You don't have to learn all the lessons that the original author had to learn in building them. One of the other lessons we kind of learned was really in the building of service clients. People really want flexibility in that. So it's not enough to have one or two service clients. You want to have pre-built best practices. For example, databases, we all know what small, medium, large looks like in an enterprise database. We all know in production, you want backups and multi-AZ, but in development, you probably don't. And then being able to allow the operators to customize is really important as well, because that's the flexibility. If there's no more questions, thank you very much for your time.