 Google, Microsoft, feels like there's something missing. Oh, should I leave the chair for the other provider? This is other clouds, right? Yeah. What's the deal with that? Why are they? Well, I'm saving them a seat. Somebody from AWS wants to come up and take a seat. Anybody here from AWS? We welcome you up here. Anybody with an AWS account? Devin, you've got prime membership, right? All right, you qualify, you qualify. Thanks for being here, guys. Why don't you just briefly introduce yourself and tell us what you do in the context of Cloud Foundry? Right. My name is KY Srinivasan. I run the Enterprise Open Source Group at Microsoft. We do a bunch of upstream projects, one of which, obviously, is Cloud Foundry. My team is also responsible for making sure that Linux runs well on various Microsoft platforms, including Azure, given that a lot of the open source projects are born on Linux. The work that we do in making Linux run well on Hyper-V is a foundational piece for projects such as Cloud Foundry to run well on our platforms. I'm Eric Johnson. I lead an engineering team working on open source integrations for Google Cloud Platform. And we've been working in the Cloud Foundry community for probably over a year now, that's it. Yeah, I'm Chip Childers. My job is to run over in my keynote. And he drives Uber doing his work. So we're here to talk about multi-cloud. And I'm really interested in what you are doing to help your customers make that progression to multi-cloud. Right. Multi-cloud means different things to different people. One is the ability to deploy workloads on different clouds, different public clouds. And Cloud Foundry is a wonderful mechanism to make that happen. We support Cloud Foundry. And the goal there is to make sure that we don't deviate in our implementation of Cloud Foundry so that workloads that are deployed on Azure could just move over and run elsewhere as well. And for somebody like Microsoft that actually has had a long history with enterprise customers, multi-cloud also means hybrid cloud, meaning we want to bridge the gap between on-prem cloud infrastructures to public cloud infrastructures. So we do have offerings on the on-prem side, like the Azure Stack. So we have Cloud Foundry enabled on Azure Stack as well. So the entire spectrum of both private clouds as well as public clouds is addressed in our multi-cloud strategy. Once Azure Stack is actually available to everybody. Well, we've had previews of it going out. Sometimes this year it will be available. Eric, what's your definition of multi-cloud? Yeah, I think it's obviously about customer choice. I think that Cloud Foundry is a great way to abstract a lot of the differences from cloud providers. What I think is also very important in the Cloud Foundry ecosystem is that you still have the capability to utilize platform differentiators through the open service broker API and service broker model. But you're still abstracting away a lot of the complexities that you probably don't necessarily care about. So you could have foundations running on Azure or Amazon or Google and still take advantage of platform differentiators. Yeah, I think it's an interesting buzzword. But in all honesty, I think it represents what's a hard reality of true enterprise. But we can use whatever word we want to use because it used to be hybrid cloud. And then we had this cloud bursting thing, which turns out isn't really a thing. And now we're talking about multi-cloud. But what it actually means is that there's enterprise environments are complicated. You're going to want to place your applications in public clouds if that makes the most sense. You're going to want to do it in hopefully agile local infrastructure when that makes sense. And I think it's just more of a way to step back and accept complexity in particular geographic and location complexity and then service variance between those environments. Is that something you're actually seeing your customers do? Yes, the cloud journey has started. And we need to make sure that we bring along everybody that had a significant investment in their legacy applications, tags, and infrastructure. So that's the intention to bring our existing customers over to the cloud. And Azure Stack, as I mentioned earlier, we feel is a bridge to that journey. And now born in the cloud customers, they want choice. They want choice. And Microsoft is all about choice these days. And Microsoft also traditionally has made the complex simple. My grandmother could read email because of Microsoft offerings. So that simplicity is what Cloud Foundry offers, being able to deploy workloads, complex workloads on different infrastructures. Yeah, we've definitely worked on architectures with customers that have an on-premise Cloud Foundry. And they're looking at expanding out into the cloud. So as they start to feel much more comfortable moving to public cloud, they don't want to continue to make investment in data center capacity. They're looking at how do they continue to use Cloud Foundry where they're already using that on-prem and then start using Cloud, right? So Cloud Foundry, again, allows them to bridge that gap. And we've been working on architectures that take advantage of a lot of Google's infrastructure, how we service Gmail and YouTube and stuff like that, making that available to Cloud Foundry users. I think there's going to be some interesting use cases coming up in keynotes later in the conference talking about the use of different public cloud providers. I mean, frequently we talk about our first thought is this, first you start private, then you kind of go public. But public cloud adoption has already reached the stage where now we're starting to say, I'm using more than one. I'm going to use Microsoft for some. I'm going to use Google for others. And I'm still going to possibly have an on-prem open stack deployment or vSphere or VMware photon deployment. And I think that we're going to increasingly see that. The other thing we seem to be seeing more is people starting out in the cloud and then going private because it's sometimes cheaper for them to do that, too. I mean, the biggest lie you can tell yourself is that public cloud is a cost reduction, right? I mean, it's just not true. It's not. Oh, you are? I thought it was. I don't know. If you have a spreadsheet that proves it, I'd love that. I think I've got a margin. I mean, it's about agility. It's not about operational extent. I mean, total cost of ownership is going to be lower, yes. But you're going to spend money for each thing that you're using. And you all are going to fight it out on price and quality. And there's a way to kind of measure that. But it is, in many ways, more expensive than going to buy one server and then advertising that over however many years, right? But you have to buy that server and wait for the truck to show up with it. So I think the other advantage, I think, standardizing on Cloud Foundry, it's not just about technology or abstracting away the infrastructure. It's also the expertise of the team. You've got the new developer program out there that just launched recently, right? So you have developers that are learning how to use, effectively, many different clouds with a single abstraction. Yeah, we hope that that's powerful. When they're making their choice, though, which clouds to use, there is something called service gravity, right? If I'm using already a bunch of Microsoft or Google or AWS services, I probably want to be close to those, right? Do you see that as an advantage? Is it disadvantage for you? Right. So we talked about how Cloud Foundry kind of abstracts the platforms and gives a uniform runtime for applications. But applications don't run in isolation, right? They need to consume services. And Microsoft has a rich set of service offerings that have been used by enterprise customers for quite some time. So we believe the Cloud Choice often is made not just on the price and other tangible differentiators, but also what is the ecosystem, right? And how closely does that ecosystem match with what they're already used to in their on-prem world? Yes, I do believe that the ecosystem has a great bearing on the choice. Now, most people don't run Google on-prem, so it's... No, not too much. That would be cool, though. Do you have a product announcement you want to make? No. OK. GCP stack, it's coming. Yeah. In a Docker image. In a container. Yeah. Big, very big container. My question, given that... You can tell we rehearsed, right? Do you see that as a disadvantage for you? No, I don't think so. I think, again, with the Cloud Foundry, right, you can run that anywhere. So yes, service gravity is probably something that you would want to take advantage of. So if you're using an Azure service or a GCP service, you definitely have a foundation nearby, right? But it doesn't still require that you're just locked in on a single provider, right? It just may be for those sets of applications, you would do your application deployments in that particular foundation that utilizes those services. But you could just as easily use Spanner, where you've got to maybe vendor lock-in with GCP, and you've got a foundation there. Again, your developers are being able to do CF push to applications, depending on where they need access to those services. If service gravity is important to them. I've actually got a question for both of you. Both of your organizations have had a pretty interesting relationship with open source in the past, but you're increasing the engagement in these communities at a really high velocity, right? Both of you, it's an amazing work. So can you just tell us a little bit more about what that means to Google, what that means to Microsoft, and your customers? I think, I'll jump in first on this one. I think for Google, all of Google is built on top of open source, right? Every server that we have runs Linux. Every developer workstation runs some form of Unix, whether that's even Mac, right? And it's basically Unix under the hood. Every engineer in Google knows how to use set and grab and all of these things, right? It's all open source, has been since day one. And we care a lot about making sure that we're giving back to that community, right? So obviously some of the contributions that we've made, you know, C groups back to enable containers in the first place from Android operating system, right? All of the stuff is Linux-based. You know, participating in standards bodies, all of those things are incredibly important to Google's business. Well, the Microsoft journey into open source has been more recent. And again, it's really based on choice. And we see customers asking us to support them in the choices they've made, right? If somebody wants to run an open source stack as part of their application, as part of their workload, we want to make sure that our platform can support it as best as we can, right? And we also see value in the open source development model. Tooling that's there, for instance, it's just about a couple of months ago. All of the windows kernel development moved from our own proprietary repos to use Git, okay? We saw that, you know, Git was a better tool for managing source. And so we moved 25, 30 years of history back from our repos to Git. So we participate in open source projects in one of three different ways, right? One is we participate in a large project, we contribute to that. Cloud Foundry is one of that. Linux Kernel is another example of that. We also are the owners of some open source projects, .NET, for instance. We open source that, and we are the main maintainers of that project. And lastly, we use open source tools internally to make our own development more agile. So for us, open source has brought us back to our core developer focused company that we were to begin with, right? So this is a different way of doing things, and certainly it's something that, you know, people are very happy about. In fact, within Microsoft, there are about 15,000 GitHub accounts. People are just developing software and using open source software to build products within Microsoft. I particularly like the point you made there about the focus on really the developer experience and taking some of the open source approach to software engineering. And that honestly, it's not free as in free software, right? It's, I mean, we're all doing this to affect outcomes. And in the case of, you know, the end user organizations here, it's to affect outcomes for their business that might not have nothing to do with technology, but it's enabling it. And in the case of technology vendors, of course it's to service your customers and make sure that they have what they need. So that's great. Well, well, Chip goes totally off topic here right now. Let's bring it back to Cloud Foundry for a moment. What is it you're actually doing? You talked about the developer experience. Is it, what are you actually doing to enhance the developer experience for Cloud Foundry developers? Well, the support of Cloud Foundry on Azure, we expect it to be second to none, meaning, you know, it's going to be a first rate experience for people that want to develop Cloud Foundry-based workload for Azure. And that says it all really, nothing specific, but we make sure that all of the most up to date Cloud Foundry bits are supported on Azure. I think, I guess I would say the same thing, right? Same goal, right? We want to be sort of the best public cloud provider, right? Some of the things that we're done to try and differentiate ourselves is, you know, utilizing a lot of Google's infrastructure innovations. You know, our global load balancers, right? Single IP address all over the planet. Right, you did the closest foundation. You don't have to do any setup. Other things like wiring in your logging and monitoring, right? So you're taking all of your application and operator logs and putting that into our Stackdriver logging tool. You can tie into it like our debugger. So that's, we're putting agents into the build packs for that. So you can actually live debug your applications that are running on top of Cloud Foundry on GCP. So just trying to make those innovations available to Cloud Foundry users on GCP. To those, once I do that though, once I've built all those monitoring tools into my processes, I'm not that likely to move away from your cloud, am I? You could. I could, that seems like a lot more work. I think that goes back to your topic about, you know, service sort of gravity, right? But there's nothing that would preclude you from being able to do that. And even, you know, we have customers that are using that today on-prem. They're still ingesting their logs into Stackdriver. And they're doing that from on-prem Cloud Foundry foundation. That's also an area where we have tried to add value to the Cloud Foundry infrastructure. We do have a fairly extensive log analytics that's backed by machine learning and AI and all that. So we have plugged that infrastructure with Cloud Foundry so that we can actually reason about the logs and give some recommendations to Cloud Foundry users on our platforms. What about if, when you're seeing people move to two multi-cloud setups, what are some of the mistakes they make that maybe the people in the audience here can avoid and learn from you? Not using Cloud Foundry patterns, perhaps. Good man, I'll give you the timeline. That's it? Well, you know, as long as they restrict themselves to the best practices that's laid out in the Cloud Foundry patterns, I think they'll be in a good shape. Yeah, I think it's really, I think that the best thing that you could do to take advantage of multi-cloud is to use something like Cloud Foundry, right? Go after the things that you care about on the platform, but otherwise, the rest of the stuff, you just kind of abstract away so that you don't really have to learn all of those idiosyncrasies. You know, every major cloud provider has a virtual machine as a service, but they're all a little bit different. And why would you want to have to go through and remember, like, these parameters for this or these parameters for that? You just let Bosch take care of that for you. And then just focus on developing your applications. That's the best multi-cloud strategy, I think. Yeah. That's, I'm sure Chip will agree with that. Absolutely. I have nothing to add. It's a great job. I'll be paying them later. Oh, later. Sorry. You're not seeing anybody just screwing up, though, in their setups? I'm not going to talk about it. Fair enough, fair enough. Well, I mean, Frederick, let's be honest. It is hard to make these architectural choices, right? But it's not any different, really. You've got the same set of criteria in your thought process around availability, resiliency, how you're going to store your data, how you're going to ensure it. All of those same things that we used to think about when we were racking and stacking the hardware in our own closets and calling it a data center. All of those same problems that you have to think about. When you start spanning across multiple clouds, the complexity doesn't go away, but you have more tools available to you to solve those problems. And you can rely more on the service providers. So for example, you need to back up your data. You should probably just use the native service for backing it up for the various clouds that your infrastructure is on, right? Because that's not a value-added thing that even your platform operations group should be focused on. What's looking ahead a little bit? What is still needed? What do you still want to build into the platform to enable easier multi-cloud deployments, for example? Is that something you're thinking about? What I'm seeing is the platforms are evolving and raising the bar. A lot of things that wash data, for instance, are going to be part of the underlying platform moving forward. And that journey is going to continue. The platform is going to do more and more things with regards to availability and scaling and load balancing and all that. And so while it might have made sense in the past to have that value-add on top of the platform, we need to figure out a way where we can have a flexible way of leveraging what the platform has to offer in building these higher level orchestration engines. Now, if all the cloud providers could just synchronize your release schedules, that'd be really helpful because then the abstractions would evolve together. But I think the serious point here, the points where you interface with the platform have to allow for that journey to occur at our pace. All of them are not going to do the same thing at the same time. But we should be able to say, OK, if this platform provides it, let's use it. If not, we'll build up something that does it. I think I had an interesting conversation last night with Dimitri about this, talking about how Bosh, the way that I look at it today, if you're setting up Cloud Foundry on top of any provider, there's a certain set of infrastructure you need to create. Bosh takes care of disks and VMs for you. But there are at least other things left as out of band. I could see a future where Bosh is starting to do a lot of that extra stuff for you and then making that even easier to abstract away some of the platform differences where Bosh is handling a lot more. Not that he signed up for any of that, I should say. It was just a conversation. But that's why we're here to have great conversations. Great conversations. And that wraps up that great conversation. Thank you very much. Thank you for reading the panel. Thank you all for coming right now. Thank you. All right, thanks, chef. Thanks.