 So, thank you everyone for coming this afternoon. Bala and I are here to talk about our experiences hosting large Cloud Foundry deployments through Bluemix. We've had a great, great fun working with Cloud Foundry in the community over the last few years on the foundation really since the beginning and before the idea. I remember Bala and I were both on early projects that led into what Bluemix became and sitting around and what's our strategy? How are we going to do this? And at the time, we were still feeling that out. And a lot of the sentiment, you heard Sam kick off the day this morning about the power of the community and none of us is as smart as all of us. And we've just seen so much growth through the communities we've worked in, whether it's Eclipse or OpenStack and the idea of Cloud Foundry and folks like Chris Ferris and Bala and Rachel and Angel coming in, starting with Pivotal and helping grow this foundation. It's really, really, really been fun. So today we're going to talk a little bit about what we've been doing, share some of our experiences, share some of what we're hearing from the clients that we work with and that are driving a lot of needs that we think as a community we can work together to address. And we'll kind of end with some of the ideas of areas that we can collaborate on moving forward. We hope that our stories resonate with some of you in the audience. And the best result is that people at the end go, yeah, we're experiencing similar things. Or we have visions for the similar. Or our clients are telling us similar things and we'd like to collaborate together around that as part of the community. So a little bit about our implementation of Cloud Foundry. It is the world's largest public hosted deployment of Cloud Foundry. So we've got in production, we've got two data centers today. One in Dallas and one in London. Huge, huge scale. We are onboarding 8,000 new users a week into this environment. So with that, that's helped driven a lot of the quality and a lot of things into Cloud Foundry today. So we have lots of engineers that have been through the dojo process, that are contributing a lot of code. Actually number two in the community in code contributions. And a lot of that is a direct result of just the scale and what we've been experiencing out there in the field. And we've really got multiple deployment options within Bluemix. So that's the public hosted. We've got a private hosted version that we call Bluemix dedicated. We can install that in any soft layer data center around the globe. So in addition to the big public footprint, we're running Cloud Foundry instances specific for clients that say, yeah, I want to go off-premises. I want a cloud, but I want to private within me. So there's also a whole bunch of operations we have to do around that. And we're going to talk more about what we're hearing and what we're doing around hybrid, borderless clouds. And really clients want to use all of these deployments together. And that's really where we see a lot of opportunity. You hear a lot of talk in the hallways about multi-cloud and hybrid cloud, and that's because that's what the market wants, is what customers want. And it's a great focus area and opportunity for us. So really, we've got a feedback and it's given us some good perspectives in a few different areas. So the first one really around cloud foundry customer requirements. You know, one of the early ones that I was familiar with from probably about a year and a half ago going back was, okay, let's pick the Java runtime space. There's lots of different Java runtimes in the market. Some people want to use Tomcat. Some people want to use WebSphere Liberty. Some people want to use Jboss. So we didn't really have a good way to administer that in the community. So we worked together with the community to bring admin build packs and to bring a better administration model to how we can control different runtimes with build packs. Some things around high availability that we brought into. And there's a long list that we're hearing around opportunities for cloud foundry to keep pushing the bounds on really enterprise and scale. And all that designed around what it takes to build real world solutions. I think that's what we hear a lot. There's kind of this myth that, yeah, platform as a service, that's kind of the future. That's not real world production. And we're working with clients that are living the opposite, that are really embraced platform as a services. I know many people are in this room and see the value that you can get out of it when you start to compose applications from services and APIs and your developers don't have to worry about that underlying platform. But even within that, not everything is going to be born on the cloud. So how you connect that back into the enterprise and really how you even navigate this emerging cloud landscape around things that I can build just with Docker on bare metal. Things that I can build in a platform like Cloud Foundry. And when you really get into the use cases, if you start to complement these technologies together, you get a lot of power. And that's what we're excited to that a lot of the partners and the vendors and people here are people that are involved in all these different communities around cloud. We've got a lot of opportunity in that space. And really around the operations. I talked to the beginning about the scale of what we're doing. It takes a lot to operate that not just from Cloud Foundry, but to the services that we bring into that, services that partners bring into that and really what the end user wants is a consistent cohesive experience around a platform. So when I'm running my Cloud Foundry environment, I'm gonna have services from ten different vendors and things I bring myself and how do I manage and operate that altogether as a cohesive platform. So I'm gonna turn it over to Bala, who is our distinguished chief architect newly named IBM Fellow. We can't embarrass him enough. He was very excited about the blue text on the opening chart. So if you like the shade of blue, please let Bala know. But I'm gonna invite Bala to come up on stage and talk a little bit more architecturally about what we've been dealing with Cloud Foundry. Thank you, Adam. And I'm really proud of that blue. I mean, that particular shade is critical. So, Adam said the context, which is, I mean, when we look at Cloud Foundry, I mean, I think there are certainly certain set of workloads that can be put completely in Cloud Foundry. But in many of our engagements, we've seen that it's actually fit into a brownfield environment. So we've been working with a payment provider. And this is kind of an abstraction of their architecture. What you see in the middle is a bunch of legacy stuff. I mean, these are traditional applications, traditional patterns. Legacy not in the derogatory sense, but legacy in the sense of architectural patterns and what tools and technologies they used in the past. And for the most part, they are systems of record, which is they focus on transactional data and some of the processes around transactional data. But it's also been, at least my observation that in the past, you had just a few tools. I mean, you had databases and you had app servers and everything fit into that paradigm. You were forced by the availability of tools into a certain style of architecture. And so you have a whole bunch of legacy code. And many customers, 80% is what stuck in the middle. And when you have a discussion with them around the pragmatics of adopting new technology, especially around things like what's my return on investment, the fringes don't matter as much as sometimes what's happening in the middle. So we have to have a cohesive argument. How do you help change technology in the middle, cloud-enabled existing applications, as well as what are the opportunities that we can bring some of the newer models, like Cloud Foundry, into play? So if you look at the right, typically, systems of engagement, I want to build new portals, whether it's for mobile or for internal use or for customers, etc. I want to build new APIs. I need to build new channels. Multi-channel is a big word, especially in the banking industry. So how do you start addressing some of those use cases via technologies like Cloud Foundry? The other area that we've seen quite a bit of interest is around how you integrate with partners. Partners are exposing a lot of APIs these days. So even if you look at a traditional banking industry, looking at providers who assess risk, for example. They tend to be SaaS-based services. How do you integrate with them? Cloud Foundry and the set of integrations around that gives you a really, really good model to achieve that. I got a pose for this picture. So he said he was going to be a heckler, but I didn't realize he actually meant it, but anyway. So given this particular landscape, when we tried to synthesize some of the discussions we've been having with many of our customers, the foundational aspect is a simplified user experience. And Cloud Foundry and the community has been very, very persistent in that in terms of the abstractions and the maintenance of those abstractions. The role of open technology, the role of community cannot be understated in the sense of importance in buying decisions. And some of the very, very core attributes like reliability, scalability, performance, cost, etc. Are fundamental to the adoption of the platform. We've also found, and Adam alluded to that, around the different deployment models. Public is certainly one of them, but being able to deploy in a dedicated environment, especially for security-sensitive applications on the cloud. It's still off-premises, but it is restricted to a particular customer. And the last one is around local, which is on-premise. On-premise is important for a variety of reasons. Certainly, security is one of them. But when you look at the context above, which is the set of very chatty, low-latency dependent applications within a data center, some of which might include things like old backends or legacy code components. How do you create a flexible environment for developers in that context? And one of our customers basically said, I mean, I have two choices. Either I take everything that's on my premises and move it to the cloud, which I cannot because some of the technologies are on hardware that's not available in the cloud, for example. Or I need something on-premises to the core minimal set that'll let me expose those capabilities to the cloud. So there's roles for different deployment models. Getting polarized around, hey, cloud is only public or cloud is only private or on-premise is probably not worth it. I think that you need the flexibility in how you deploy this stuff. The point to the left, to me, is actually very critical on top, which is hybrid application architectures. When you look at Brownfield environments, I mean, we talk about these different abstractions, whether it's containers, whether it's managed containers like Cloud Foundry, whether it's VMs, whether it's patterns of deployment like Tosca and so on and so forth. Each of them has a role in being able to create effective solutions. You cannot polarize people into saying, hey, this is the only abstraction that works. The only place where you should deploy applications is Cloud Foundry, or it's only Docker, or it's only VMs. All of them, depending on the workload, depending on the legacy of the application, depending on some of the technology, has a role. And how do we accommodate different application architectures is a critical element of what we've found when we go out and talk to customers or deploy Cloud Foundry-based applications. DevOps, obviously, is critical. I think this is a platform that enables DevOps in many different ways. More Dev than Ops, but Ops is an important component and that's one area that we need to continue to focus on is given Cloud Foundry, given an ecosystem of services, given how Cloud Foundry-based applications link up to existing application. How do you manage this? How do you guarantee SLAs around it? How do you manage multiple providers in this space? So the notion of Ops and DevOps is also very critical. Integration, it all comes back to the application architecture that you see on the top. If you have existing components, you have new applications, you have to have effective ways to integrate them. From a data perspective, from an API perspective, from a performance perspective, with the assumption that some of those back-end services might not be elastic and scalable and everything that Cloud applications are targeted to be. Portability is going to come up in a big way. A lot of our customers are particular about the notion of lock-in and not being locked into a particular vendor, a particular location, whether it's on-premise or off-premise. So how do you support portability across different environments, across both the platform as well as the services that are available across these platforms? So that's a very critical requirement as well. Security and compliance, who cares? Management and SLA is, sorry. Security and compliance is perhaps the biggest question that we get from our customers. Security from a fabric perspective, the reliance of security on underlying infrastructure, security of applications, services that enable security, whether it's single sign-on, whether it's encryption, whether it is tokenization services, being able to provide that in the right context around a Cloud Foundry ecosystem is becoming much more of an important topic of conversation. And we need to continue from an architectural perspective and from a community perspective that we focus on that. To me, security, to Sam's point earlier this morning, is not a differentiating capability. It is something that should be in the platform, because one insecure implementation can sink this whole momentum. So to me, personally, I think security and compliance are something that we need to work together and kind of raise the tide and the competence of the platform across that particular capability. And as I was mentioning earlier management and SLA is a key. We are just touching the tip of that when we talk about complex systems that connect existing systems, newer APIs, newer systems. The reliance of the system for more production or mission-critical workloads, having the ability to manage it effectively, do incident management, change management, problem management, SLA management, et cetera, is becoming much more critical in many of our conversations with clients. So as part of what we've been doing and I'll move a little bit quicker here, given the premise, we look at Bluemix as a platform and the ecosystem around Cloud Foundry as one of the principles around it is to provide compute flexibility. So in addition to Cloud Foundry capabilities, we are integrating from a DevOps perspective as from a user experience perspective, capabilities around Docker, capabilities on VMs and patterns and so on and so forth. And we find that a necessary component in being able to position Cloud Foundry and its capabilities in the context of enterprise architectures. The second element is services. We, services are independent entities. They need to be accessed from Cloud Foundry applications. They need to be accessed from Docker applications. They need to be accessible across different environments and maybe across different providers as well. So having services as first class citizens is absolutely key. Data of any cloud platform I've seen, the currency that really matters is data. You put data on the cloud, you get a lot of cohesion around that platform in terms of application, in terms of users, so on and so forth. So having an effective strategy around data for our platform, around persistence, around state management, around moving data in and out, around security of the data is a very critical element of our overall strategy in terms of Cloud Foundry. And the last but not the least integration with its API integration, data integration, so on and so forth with existing systems is an integral part of what we should look at from an overall platform perspective. The reason I said this context is there's an element of Cloud Foundry in that. And for Cloud Foundry to be successful in this context, these other factors around it need to come together as well. And in all of our conversations with clients, it is almost always a case where to not have a polarizing discussion. Having to explain PAS a hundred times over as to what exactly it is. And I don't believe that word anymore. It is how do you put the context around it from a perspective of compute flexibility, data integration, security, and services. I found that to be very critical. The other area that is interesting around the spaces, services, how do you build effective services around Cloud Foundry? So Cloud Foundry is a platform to build services. It is a platform that lets you consume services. But to build effective services, services that are, or microservices, that scale, that are measurable, that are monitorable, that can be updated continuously, you need a set of core services. So as part of our approach to this platform, we are building a set of core services around it, we call them Cloud Foundational Services. Everything from container services to monitoring services to logging services. To even configuration management services like Chef and so on and so forth. So that we have an ecosystem of services that support building applications, supporting the life cycle of the applications from creation through management, as well as building services that can scale elastically and support newer implementations of these services in the Cloud Foundry. This could be a day and I have 25 minutes. No, I have less than 25 minutes. You have minus five minutes now. So, in terms of delivery of Blumex, one of the points that we, our biggest investment of time, effort is around managing the platform as a whole. So if you look at it, we break it down into kind of three distinct pieces. There's a platform, Cloud Foundry, the underlying capabilities around it, how you deploy applications, the APIs, and so on and so forth are the core part of our system. But around it, we have to build an ecosystem of services and we have to build an ecosystem of how do you manage Cloud Foundry deployments and the services underneath Cloud Foundry. So you can see that broken into three pieces. There's a platform, Cloud Foundry is a centerpiece. The set of user interfaces and DevOps that need to come together around the platform, so that you can effectively use the platform and optimize the, and we can go into a lot more detail about that. But the general experience of a developer around the platform, a scalable set up around services, so that we can bring in more services, elastic services, connect those services not only from the purpose of consumption and deployment, but around it, life cycle. How do you monitor it? How do you get security logs? So we have a long way to go from that aspect, in terms of a complete life cycle around services. And off to the left, the whole notion of service delivery, from being able to deploy applications, the CI and CD parts of the applications, BSS to meter and price. The various services in a pay as you go model, for example, infrastructure, NOx, and more importantly SOx are something that we spend quite a bit of time on. So how do you harvest logs across all of the Cloud Foundry components, as well as the network components? Being able to monitor various aspects of it, including the ecosystem around Cloud Foundry, which is other services, perhaps even SaaS services. Support, and support is not just a standard support model. It's how do you support the new paradigm of application development? How do you support in using new digital models? All of the automation that is necessary for a very large scale deployment, and obviously compliance and security and managing it and demonstrating it, is something that's very key. Now I think I need to cede the floor to Adam, but let me think it, go ahead. Hey, I'm happy to sit back down and take a nap. Still on East Coast time. So we hit on this a little bit earlier, kind of the different deployment flavors. And we said today, we've got hosted Bluemix, whether that's public cloud, whether that's private cloud, also bringing that into local data center. And I think that's common across, if you look across other Cloud Foundry vendors, there's a need and a use case for shared off-premises, single-tenant off-premises. And no, these workloads need to be in my data center. What we're learning more and more is that it's really even a hybrid between those. So my mobile push notification service, okay, that can be off-premises. There's nothing secretive that I'm gonna send out there. But it needs to pull off of some data source that contains sensitive information about banking accounts, and that's gonna be on-premises. But still in a cloud, I'm okay in moving that out of the data center where it is today, meeting where it is today, but not out of the data center. With that, what's emerging through that is a seamless experience through that. And that's what we're hearing from clients is, I wanna run DevOps across these different zones. I wanna be able to monitor what's going on across these different zones. And by the way, that also includes applications that may end up in a hybrid state. We see a big trend towards large monolithic application today. But I've got microservices, but I can't break it down and re-architect it overnight. What I wanna do is I wanna slowly break that down and maybe at some period, some of those functions are in microservices in the new world. Some are still in the old world. I may have a mix of these different deployment models and how do I bring that experience together? So we're sharing that because as we get to the punchline here and we talk about just some of the opportunities and areas we think we have as a community. It's a lot of this feedback that's really driving us towards the question of, how does Cloud Foundry fit in this world? And what can we do to make Cloud Foundry even better? So some of what we've been doing is really kind of around. It's we've been working on a single operations console, whether that's resource information, whether that is managing deployments, reports logs, user administration, etc. But it's about multiple channels through that. And I think it's not just the deployments before, but it's multi-cloud. So as we have vendors that maybe are users that start to use Cloud Foundry from multiple sources, we're starting to see that. Yeah, I'm gonna use some Bluemix and some Pivotal Cloud Foundry. I'm gonna take some Cloud Foundry from myself and I'm gonna stand it up on Azure and I want that ecosystem to work well together. Isn't that what you guys told me? It's Cloud Foundry, it should all work the same. It's really critical for us to be working together to make sure that that happens. And really around this idea of collaborative operations, which is where you then start to get to. When it's operations, whether that's collaborative between, okay, it's hosted and there's things that the end user and customer needs to see, and then you as the person hosting it. Or as we get into multi-cloud and it's operations across multiple teams, the lines are gonna start to blur. And it's really about one borderless cloud working together. And that's another area we're gonna have to come through. So I'm gonna ask in the last couple of minutes here, I'll let it come back on stage. We'll try not to talk over each other too much. I don't want this to be interactive, keep you guys on your toes. But I wanted to talk about just some of the opportunities. And we've quickly dove right down into the weeds, but we find that's where you've gotta get to if you wanna take real action. And we really hope that this generates some good conversation in the hallways kind of afterwards for people that wanna help invest in these areas as well from a Cloud Foundry perspective. Yeah, so I mean I think there's just a sample list. I mean there's many, many opportunities. But we kind of, based on the conversation we had, things like security. How do we do things like secure logging? We've seen that as an important element of almost any enterprise deployment where, or even a multi-tenant deployment where logs need to be encrypted and separated and stored. So how do we do secure logging? Services tend to be persistent in terms of how they present their credentials into runtimes. How do you support things like rolling API keys? How do you have, and this is a very interesting case. And we experienced it ourselves, is let's say you have a database, database instance that's exposed into Cloud Foundry, into a particular org for example. And you have four or five privileged users for the production aspect of the database. How do you start providing credentials that separate or modulate what kind of access do you have to that service? Once you can get to the credentials, you can do everything from read the database to destroy the database. Many of our customers, even in a production environment, want to have separate credentials for different levels of access into the underlying services. So that's becoming an interesting element of how do we support services within Blumex. Private DEAs, in many cases for performance reasons or for isolation reasons. They want DEAs that are specific to a particular organization, a particular application for PCI compliance for example. And associated with that, more granular role models. The second broad area is services, how do we blacklist services? In many organizations, even though there's a plethora of services available, they want to restrict which set of services are supported under organizational control. It's great to have a variety of services to start trying out, but in many organizations the support end of it becomes a problematic situation. So they want to be able to provide a blacklist certain sort of set of services that don't have the right security controls or they're not provided appropriately. So that's one important area that we are looking at. And we need to look at it as a community. Microservices enablement and security of those services, ability to move services across different organizations that might have dev and prod, sharing services, or having independent services between CF-based applications and non-CF-based applications are a set of examples of things that as a community we need to get our hands around for adoption. Org-specific build packs, going on to the last column. Org-specific build packs, quarters for various aspects within Blumex or within Cloud Foundry. The ability to deploy apps with context routes more than just the base domains. And the last one is particularly interesting. When you move from the role of an individual developer to managing applications created on Blumex, you get into a whole set of interesting management and operational questions. So the ability, for example, when an application scales up or scales down, might be important to a certain group of management users, say capacity planners within an organization. How do you start generalizing the notion of notifications out beyond the core fabric into the external management systems is one of the areas that we need to look at as a community. So I got the five minute little sheet of paper wave. So let's spend the next couple of minutes on questions. And if you guys refuse to leave this room, that's perfect. I mean, that's fair by me. I don't have a problem with that. We can ignore a sheet of paper. So any questions, any thoughts? I mean, are these problems the kind of things that you guys are seeing? I mean, anyone who does not see that? Contrary and viewpoints are very, very appreciated. I mean, that provides a little bit of fizz to this. 150 people and not one contrary opinion. I have a family of four and I get three contrary opinions. So I mean, this is like, well, any question? I think that is something that's a really, really good question. Because I think when you look at a runtime platform, I mean, and this has gone on forever. If you look at Java or you look at J2E or whatever it is, the core platform is just one bit of it. The ecosystem around it, whether it's monitoring tools, whether it's dev tools, whether it is performance management systems, there's a huge ecosystem around it. I think what we need to do as a community is recognize the fact that for a production deployment, you need many of these pieces. How many of these can we look at, build the right interfaces, build the right data models to make the deployment in customer situations very easy? So that's a very, very good point. You need that ecosystem. Our job is to make that ecosystem flourish across multiple vendors and also provide the right interfaces around it to make it easy and not make it a lockdown ecosystem. And that's why we're here today. So for those who didn't hear the question, it was going to lose. Back on the chart where we had the different components, right, of what we're delivering as cloud, there was a big box in there that had Cloud Foundry. There's a lot of other stuff around that. And what we're learning and it's really driven around these areas and the hybrid nature and the multi-cloud nature we're hearing from clients is that they need more than what's in there today. And we're hearing that a lot and we want to collaborate with the community and kind of grow that box and work together so that way Cloud Foundry can just crush out there and be the premier platform that people develop that to. So I think we're out of time. So we'll cut it there, but please come up or ask us questions. Thank you for spending some time with us today. You can find us on Twitter too, our handles there in the corner. That's an easy way to get ahold of us. And we look forward to working together. Thank you. Thank you guys.