 How are you guys doing? Welcome to the Cloud Foundry Summit 2016. Thank you. Welcome, guys. Come on. Oh, you know, Sam will be up in a moment. But we are so excited about Cloud Foundry. When I go back and I think about when you all started the foundation, there was literally 100 folks in the first summit. And here we are, close to 2,000 people. It's absolutely unbelievable. And what we want to try to do in the next, I don't know, 19 minutes and 23 seconds, there's a clock up here. We'd like to kind of take a moment and think about what does Cloud Foundry mean to our organizations, in particular the code, community, and culture aspects of Cloud Foundry, and also perhaps reflect a little bit about where we need to head in the future. Because when you think about when this all started, and Sam and the team kind of started to galvanize and bring folks together, it was a small band of disruptors, people that were building out the basic DNA of a open governance system. Transparency from the start. Are you all hooked into the Slack system? I'm sure you are. Email list, distribution lists, how you track changes. A well-defined meritocracy, and very, very clear levels of participation. That's how people engage. You're a developer, you're a project lead, you're a board member. This basic DNA started to go and grow and multiply, and become something else. And what it became, it became a platform. And you all have heard me say this before, a platform for the people, a platform for innovation. That vision translated to close to 60 or so odd member companies joining. Six physical dojos. Everyone know what a dojo is? These are physical locations where if you want to go contribute to Cloud Foundry, you can go and do some pair programming with someone and work on a project and accelerate your committer status. They're all over the world, right? Sponsored by various companies and the foundation and so forth. As Sam said, there's over 100 or so dedicated full-time committers. And then most importantly, there's user groups, right? I'm sure a lot of you all run them, a lot of you all are new to Cloud Foundry. Find a user group near you and get engaged. But just this past year, this ecosystem has exploded. I mean, just today, we went from seven to nine certified Cloud Foundries. Come on, guys, round of applause. That's interoperability, freedom of choice, right? We have literally thousands of organizations, large and small, governments using Cloud Foundry. And I am told that if you look at the shared development costs across the community of the Cloud Foundry base, it's about $455 million. And Dr. Nick is committing today. Where are you? He's committed today to pitch in the other $45 to make it half a billion. Very much. Yeah. Thank you. Thank you. Half a billion, thanks to you. It's in my other pants. Oh, love. All right. All right, very good. So it is a very vibrant, healthy, and fun place to be. Now, there's many reasons to be involved. But why are we involved? Why is Kaiser Permanente involved? Well, look, for us, it's about providing a platform of innovation. Clearly, you're going to need capability on-premise, off-premise, dedicated. There is no single Cloud. There are multiple Clouds. You need to integrate the world as hybrid, right? But what about all of those colors that Sam talked about in that intro video? All of the APIs, all of the services that you need to kind of build applications faster, your cognitive capability, your analytic capability, your Internet of Things capability, your weather data? That's what we're trying to do. We're trying to actually add value to the platform so that you all, the end user, can do more. You can build more. You can federate your application across Clouds and use the right tool, the right brush, the right palette for what you're trying to get done. So with that, let me ask Sam to come up and share his story of how he's using Cloud Foundry and IBM. Sam, give him a round of applause, please. All right, thank you. Hi, everyone. So I want to, yes, I work for Kaiser Permanente. So first, I want to intro some of you into what Kaiser Permanente is, some of you are familiar, some of you are not. And then take you through our journey, which is about a year old. So you'll see some stuff where we've been, where we're going and what we're doing, what we're planning to do in the future. So who we are, Kaiser Permanente, right? We are an integrated health provider organization with close to more than 10 plus a million members. And what we do is we sell the insurance and we also provide care. So it's a close end system. That's why we call it integrated system. As you see, we have a city hospitals, a lot of medical office buildings. But we're in a healthcare space, right? At the end of the day, we are trying to innovate for our consumers, for our members. And what the next slide shows is when we looked at everything, we said, well, we're no different from any other company or most of the companies. We need a consistent system of engagement. And for us, when we're talking about system of engagement, we are talking about consumers. We are talking about us, workforce, as well as our physicians, care team as you see there. And also all of the supporting staff that you see. So when you go in the hospital, you see a lot of people. And to bring you one example, today when you walk into the room, you would say, well, okay, I have all the stuff that is monitoring me as a patient. But then from a workforce perspective, you basically say, well, somebody monitors all of this equipment. And all of this equipment has to be interconnected so somebody can actually get a sense of it. So when you look in this situation, you're saying, well, this is kind of a system of engagement. So all this equipment is engagement with me as a patient and it's engaging with providers that are providing care to me. So, and as you see on the slide, what we were trying to achieve was that, why we thought it's gonna be very important for us is, we need to increase dynamic engagement, healthcare is shifting. We were used to be selling to brokers, now we are selling to end consumers in the US at least. We wanted to shorten time to market. We didn't want to worry about infrastructure. We didn't want to worry about security. We want to provide our developers with the central platform. And also we wanted to maximize into existing system of records. So Kaiser has a lot of system of records. So we want to maximize that investment and we've been doing all kinds of integration and web services since 2008, but now we kind of wanted to take it and really expand on it. And as you see on the bottom, I'm not gonna go through that, but some of the driver for change time to market on demand integration, like any company today, you would see kind of the same words for everyone. Now, what we created, and this is a logical view of our system of engagement, we have a hybrid cloud, like everyone was pointing out, our Sam was talking about 4.6 clouds. I can say that we're in that boat. I'm just showing two clouds today. We have an internal cloud, which is based on VCE, Vblock. And then we have an external cloud, which is a soft layer for us. And when we are thinking about, and we have a bunch of external clouds, we just ask providers, as you've seen here, and on the bottom, you see a system of record system of engagement, right? So we said that we need to unify this and we wanna have consistency across both layers. We wanna be able to shift workload for us between something that lives really on a cloud in a software data center, IBM software data center, or in our own data centers on our private clouds. And for that, as you see here, we kind of said, okay, here's our system of engagement. Here's how we're gonna operate as a company going forward. This decision was made. This architecture was put together in, I believe, in September of last year, because we started on the pilot. And again, I'm moving very quickly through it. So for us, we said, okay, if you're gonna standardize on system of engagement, we really wanted to standardize on platform as a service, really. And with that, we said, well, platform as a service, and again, specifically for us, it made sense to standardize on Bluemix, on IBM's platform as a service. Why? Some of those points you will see are very generic. So you can say, well, that applies to any platform as a service. And I'll kind of explain why we went that direction because I see a lot of companies, like I talked to a lot of different companies and we say, well, why did we go this direction versus another direction? So for us, it made sense for other companies to make sense to go with different cloud founder distribution. But it provides rapid application delivery based on Cloud Foundry Docker OpenStack, rapid infrastructure, platform, cost advantages, we only pay for actual resources that we're using instead of paying for capacity. We're like any enterprises, maybe not, but we have boxes that have been there that have not been utilized. We have Rich Library of Services. I mean, Cloud Foundry provides, IBM provides Rich Library of Services. So for us, it made sense because some of the existing tools that we're using on-premise are already provided in the Bluemix Cloud Foundry distribution. So for us, the skill set, the existing skill set of developers, we didn't have to retrain them. They already had some of those capabilities. And also what it provides, what is not shown on the slide, but it actually provides some of the Watson capabilities that we in healthcare would like to utilize very heavily. So even that made sense for us. We had some Watson capabilities on-premise from a search engine perspective, but it kind of landed itself for us to actually go in that direction. And I'll just take you through, so this is kind of our roadmap, very high level roadmap. So we did pilots. In pilots, we did close to 20 different use cases. We had close to 50 developers involved and we had IBM team heavily involved too, helping us out. We had our partners consulting companies also kind of learning about it and partnering. After all of that exploration, we decided that that is, it was about five months for us. In December of last year, we decided that we're gonna go with the Bluemix as the platform of choice. And to take you quickly through one example, we had an application that actually, when you walk into the patient room, you see a lot of, like I mentioned to you, we see a lot of different devices. Those devices need to interconnect and work with each other. And those devices, when you bring in need to pass security, credentials need to press vendor credentials, all types of compliance and require me. So for us, there was an application that was developed to basically screen some of those devices before we come in, before we actually make a suggestion to buy. It was developed and redeveloped and redeveloped again and it was cumbersome process to infrastructure all that stuff. So we said, okay, why don't we safely, because it's kind of workforce applications where you screen in the devices. We said, why don't we take that application, try to build it on top of this Bluemix platform? And requirements took some time, still because we had to normalize them. But the whole build out process took us about three to four weeks, I would say. And I can say that this application has been deployed already today onto the Bluemix dedicated platform sitting on top of software data center. And this application is actually being used today. And this year, like you see on the graph, we are going after the workforce type of applications. Safe for approach for us. We don't wanna expose Bluemix type of capability yet to our end consumers. For this year, it's more workforce type of applications, but we are moving very rapidly. Healthcare is evolving very rapidly. So in 2017, as you see, we wanna actually stand up Bluemix on the local environment too. We have dedicated now, as I mentioned. And then we wanna use for all types of system of engagement application, including interactions with our consumers. So that's kind of very quickly, I gave an example and I wanna turn it back to Angel to kind of take you the rest of the way. Thank you very much. Thank you so much. Thank you. Thank you. What a wonderful story. Now, DNA. You know, when it comes to open source, there's many really, really important strands of DNA. And we built our cloud out of what I would say, probably the best open source DNA out there. Cloud Foundry being a really important one. But if you think about it, we've got 40 plus data centers across the world. We use OpenStack. I know Jonathan's here. There's a whole bunch of OpenStack people here. OpenStack for compute storage and network. We've got our container services that use Docker and what we're building at the Open Container Initiative and the Cloud Native Computing Foundation. Cloud Foundry, of course. And OpenWhisk are our newest strand of DNA for event-driven architectures. Then when you have that layer, right, you start to build applications that bring in runtimes and APIs and inputs and feeds and integration across many, many different sources. All of a sudden now your Cloud Foundry app, right, doesn't live in a box. It can be used across many multiple platforms. In fact, the number one architectural principle that we have here is choice with consistency. I know Jason McGee, our CTO, for the platforms in there somewhere, we talk about choice with consistency. So whether you need access to bare metal, right, because you want to optimize and perform, have network, you can do that, but then you can gradiate all the way to the levels of abstraction and accelerate the ability to deliver applications. That's how we think about this. Now, back to Cloud Foundry. We are committed, not crazy, committed to Cloud Foundry from the beginning, right? We contribute to 12 to 20 projects. We help participate in many important projects like what we did with RunSea. We help open a Dojo and Rally North Carolina, which were focused on the runtime OG part of this. We've contributed code from Bluemix, which you just heard about, and we've got, I think, on 24 or so folks who are full-time and Dojo graduates within Cloud Foundry. We are absolutely dedicated and we will remain so with all of you. So, in closing, I'd like to encourage you all to take the leap, to jump. Now, you're not gonna fall into some big chasm, right? This is a pro mountain climber here, right? Okay, and there's really kind of two things I'd like you to think about. The first of all, if you're new to Cloud Foundry and you wanna take the jump and the leap into Cloud Foundry, Sam and the team have an amazing set of ways and processes and procedures for you all to get engaged, whether it's at the Cloud Foundry code base itself proper or whether you wanna create a build pack or be part of the larger application solution ecosystem, right? There are ways to do that. Now, if you are a Cloud Foundry veteran and you've been around from the beginning, I encourage you to kind of take your hand, right? You don't have to be an ambassador, right? And bring someone in and help them. If we do that, this time next year, we're gonna triple the size of this multi-cloud conference. So with that, thank you so much and have a great conference. Thank you. Thank you.