 The queues, timing queues, who is giving the timing queues? Hello, everyone. Thanks for joining. My name is Animesh Singh. And these are my colleagues, Daniel Crook and Manuel Silvera. We are part of the IBM Cloud team and have been working on OpenStack, CloudFondly, and Docker for the last few years. Specifically around OpenStack, in the beginning of 2013, IBM made a decision that all our infrastructure as a service offerings are going to be based on OpenStack. And then last year, we made a big bet on CloudFondly by investing $1 billion in IBM Bluemix, which is our platform as a service offering based on that. We are also doing a lot of work around Docker, about which we'll definitely be hearing soon. Now, according to a research, which was done by CRISPR Research, OpenStack, CloudFondly, and Docker sit in the top four of the leading open source cloud technologies, which is not surprising, because of the growth of the community and the capabilities they offer and the way they compliment each other, they deserve that place there. In IBM, our cloud strategy is being based on open source standards. Be it at the infrastructure as a service layer with OpenStack, Open Daylight, OSLC, or platform as a service layer with CloudFondly, MQTT, Node.js, et cetera. Even at the software as a service layer, we are using open standards like JSON, HTML, Eclipse. And that's where the cloud strategy is evolving within IBM, and that's where it's based on. Now, where does Docker fit into that? Is it infrastructure as a service? Is it platform as a service? Our view is that it actually fits into both of these spectrum. And as we go through this talk, we'll get a little bit of idea in terms of why we say so. With that, let me come to the agenda. Manuel is going to talk about OpenStack, CloudFondly, and Docker, given an overview of the architecture as well as the community around them. Daniel is then going to come and talk about how to CloudFondly and OpenStack intersect, and also a lot of projects which are happening at the intersection of OpenStack and Docker itself. Finally, I'm going to come back and talk about the CloudFondly and Docker intersection and how do all these three different technologies then come together. With that, let me pass on to Manuel to talk about OpenStack, CloudFondly, and Docker. Thank you, Anamesh. So I'm supposed to give you an introduction and background into OpenStack. I think we all understand what OpenStack is, right? We agree that it's a collection of well-integrated modules that give you compute, networking, and storage, and it really provides your infrastructure as a service. At IBM, we agree with this statement that OpenStack is the ubiquitous open-source cloud computing platform for public, private, and hybrid clouds regardless of size. So let's talk about CloudFoundly. There's really four points I want to make in this slide. The first point is that CloudFoundly is open-source. This is just like OpenStack. CloudFoundly is the big advantage to be in open-source is that you're really not tied into any single vendor. At the end of the day, if you choose to move whatever your workloads are, you're free to do so. So this freedom is very powerful. The second point is that CloudFoundly is a platform as a service that utilizes your infrastructure as a service. So the big advantage here is that there's really no interference, no interaction, no duplication of efforts in the work that is done with CloudFoundly and the work that's done with OpenStack. The third point is that CloudFoundly is very developer focused. It's not as opposed to being operator focused as OpenStack is. It's very developer focused. So the whole idea is that you create an application, you deploy an application, and let the system, let the platform as a service, take care of actually how it's going to get deployed, where it's going to get deployed, actually what deployed means. And the last point is that there's a big community, a compelling community, built around CloudFoundly. So what we're seeing is that in CloudFoundly, you'll see in a little bit, there's this concept of run times and this concept of services. So your run times and services, every day there's new and exciting services and run times available. So this is the architecture for CloudFoundly. And what you'll see, it's sort of similar to OpenStack in the sense that you have a lot of very isolated, very separate components, services. The big difference between CloudFoundly and OpenStack is that these components are dynamically discoverable and loosely coupled. And the way that this happens is that CloudFoundly has this central service called Bosch. And what Bosch does is it's the way that it controls, it interfaces with your IaaS. And then it actually manages whether systems are up and running, it manages the health of the environment, manages what needs to be deployed, what it means to deploy, where you deploy. And the way Bosch does that is through monitoring of health. So basically, every service end point, every service advertises their health and status and then other agents then monitor that and act accordingly. So let's talk about Docker. So in Docker, there's two things I want to talk about in this slide. The first thing is that Docker is really built around creating applications and then running these applications on any infrastructure. It's the same application run anywhere, whether it's Red Hat or whether it's running on Ubuntu or whatever. It's the same application. You don't have to worry about what the underlying infrastructure is. And the second thing you want to think about is that with CloudFoundly and OpenStack, you have very clear separation between what your platform is and what your platform does and what your infrastructure is and what it does. With Docker, you have this interesting situation where you basically think of everything as developers sort of think of what's inside the container. And what's inside the container is sort of a hybrid between an IaaS and a PaaS in the sense that you have your application, but you also worry about the middleware and the applications that are built around it. And then as an operator, you worry about what's on the outside of your container. So once I have a container, how do I deploy it? How do I scale it? How do I run it on different servers? How do I create patterns out of that? How do I have orchestration related with that? And so at the end of the day, again, like I said, it's not a clear separation. So sometimes the developers have to worry about patterns. And sometimes the operators have to worry inside the container. The architecture for Docker is very simple. It really basically consists of two things, a Docker server, a demon process that's running. And this is the one that does all the heavy lifting. It does the building. It manages the building, the running, the distributing of these containers. And then you have the client server, the client service. And what the client application does is it manages, it's the interface. It manages the server. These two can typically be co-located on one machine if you're running on your laptop. But if you have a larger environment, the one client would connect to multiple servers wherever they be. And the way it connects to these servers is through a RESTful API. OK. So the Docker container really consists of, I mean, it takes a while to understand this. But at the end of the day, it is running and leverages the kernel from the host operating system. But then everything else is built. It has to be packaged on the container. So you have a very small operating system. In fact, it's only the required, it's the bare minimum of libraries and services that your application requires. So if your application doesn't require certain libraries, languages, documents, it's not included. So this is why the packages can be so small. And all the other components and services provided by the kernel are actually given by the host operating system. The Docker image is a read-only image. So once it's mounted, what we have is something called the union file system, which gives you the ability to then mount a read-write layer on top of your file system. And all of this, Docker makes all the reason that all this is possible is a bunch of really cool technologies that are built into the Linux kernel. These are, for example, namespaces, control groups, union file system, and then the container technologies. So the big question you get is, what's the big difference between a virtual machine and a Docker container? And really, the answer to that is a question of how much control you want. With a virtual machine, you have effectively all of the control and all of the isolation that you would have with a physical machine. But the cost is that you have a performance hit because you're virtualizing hardware. You have to install the entire operating system. However, this can be a small operating system. And then you have to install the middleware application, libraries, anything else that you need. So at the end of the day, Docker gives you the ability to simply focus on the application and the bare minimum libraries associated and required by that. And so the big advantage is that Docker, the CPU performance, is it's almost native performance. It's effectively native performance because it's using the same kernel as your host operating system. The memory performance, there's a small hit. And the reason there's a hit is that Docker is doing some accounting. But if you don't want that accounting, you can actually turn that off. The network performance, the network performance can be there's a small overhead associated with some tagging. But that can be optimized and be down to zero. Creating a new image is almost, for those of you who've tried it, it's almost instantaneous. It takes a few seconds. And because we're using something called copy on write. And with a virtual machine, you know that you have to bring it up. You have to boot. You have to copy it, do all that. And finally, apps in different containers can share the same libraries and binaries. So now let me hand this over to Dan to talk to us about Cloud Foundry and OpenStack. Great. So Manuel gave you the overview of what OpenStack, Cloud Foundry, and Docker are independently. Basically what they focus on, the developer communities that they target, basically the technology behind them. So this part of the talk, we're going to move into actually how they integrate, how they build on each other to provide good hosting environments for next generation cloud native workloads. So let's look at Cloud Foundry and OpenStack integration. So as Manuel noted earlier, Cloud Foundry, just like OpenStack, is the deployment architecture, very highly distributed, made of different virtual machines that are assigned different roles. So each of these components, they need some primitives from underlying infrastructures of service. So storage, compute, networking, things like that. And in order to provision those resources in a cloud agnostic way, it uses a cloud provider interface and a tool called Bosch, Bosch Outer Shell, a core component of Cloud Foundry, to actually get the primitives, the compute, the network, and the storage. And this abstraction makes it very nice for hybrid scenarios, for development scenarios. So it can provision out those resources into a public cloud, like SoftLayer or Amazon web services, but also on OpenStack in a private deployment, or even on a developer workstation using containers, using a Bosch LightDriver. So how does Bosch actually bring up a Cloud Foundry cluster on top of an OpenStack or another cloud? It basically, like other deployment tools like Chef or Puppet, Ansible Assault, it's basically infrastructure as code. You basically have a declared model. That's represented by a release, which specifies components such as the Cloud Controller or a MySQL service or an application runtime. And that's given a version and some startup scripts, some lifecycle scripts in the form of a release. And that's combined with a stem cell, which is an IaaS-specific operating system image. So for Amazon or VMware, you might have a different package format around that operating system. It also includes the agent that Bosch talks to and a deployment manifest that basically describes what exactly your whole Cloud Foundry cluster is going to look like, whether it has five cloud controllers at the front of it, whether it provides capability for dozens of MySQL databases. And Bosch takes this declarative information. It goes out to an infrastructure as a service and deploys those resources. And it also goes a little bit further than those other tools in that it manages the lifecycle of the deployed virtual machines. So if one of the virtual machines goes away on a Nova compute cluster, it'll resurrect that declared role for a new virtual machine to make sure that it always matches the number in the deployment manifest. So in the deployment manifest, here's a sample of, as Manuel mentioned, Cloud Foundry's a PAS. So you have the runtimes and services, one of which could be a MySQL service that you deployed out there. Here's a sample basically describing that it is a MySQL database. It's going to provide, in a multi-tenant environment, 100 instances, as well as connection parameters, max size, things like that. And Bosch will go ahead and make sure there's always the fixed number of those, and they're always available to the system. OK, so going on to Docker integration with OpenStack, it gets a little bit less clear. With Cloud Foundry, it's basically the contract is the CPI, the cloud provider interface. With Docker, you have a few options. So the oldest option was actually a Nova Docker driver. So something that actually worked directly with Nova could be plugged in just as you have for KVM, or VMware, or any other compute driver. And it wanted to be able to work with Docker containers as first-class citizens, and essentially work with Glance as well to provide images that you could deploy out to an OpenStack cluster, and of course provide the same interface from the command line tools from Glance and Nova, as well as the Horizon dashboard. There was another alternative that came out, a plug-in. And basically what this lets you do was put containers on top of Nova-running virtual machines. So with this, you could declare entire topologies or larger amounts of linked Docker containers using the actual Docker tools rather than relying on some of the external OpenStack-provided components to do that for you. And that also had very nice integration with Horizon in that you could declare your stack's containers, combine all the resources that he gives for you, and put that into the same user interface. But more recently, there's two new OpenStack projects that have come about, one of which was announced or talked about in detail in Paris, was basically OpenStack-Cola. And the point of this is actually to containerize the OpenStack runtime itself. So what's providing the services in terms of the Nova API, for example, or any of the various components themselves. And to manage these as groups of services, the goal here is instead of working with bare metal or virtual machine primitives, what you're working with are the actual containers. So you get better density, you got quicker deployments, and you have reduced downtime and more atomic upgrades than you would with virtual machines or deploying those in replacement for failover situations, for example. So originally, it was based on Kubernetes. That's what this diagram here reflects. It's moved now towards some of the Docker tools themselves. So Docker Compose, the old fig, is now used to stand up these clusters. And the other OpenStack container project you'll probably have heard of or will hear about in the coming days here is OpenStack Magnum. So there was a containers group that was started up at the Atlanta Summit about a year ago. And there was work at the design sessions in Paris to define what exactly it would look like to make best use of containers in OpenStack. Some people felt that directly managing containers from Nova wasn't the best way to do it. And instead, it was more valuable to provide a framework and rely on other open source projects like Kubernetes or Docker Swarm to actually do the container management on their behalf. So it becomes more of a platform as a service on top of OpenStack, but it also delegates out to other open source projects. So again, integrating with Docker there. And the goal here too is why wouldn't you just do Kubernetes on its own? One of the key features of Magnum is really multi-tenanted clouds. So building on the things that OpenStack does well, the multi-tenant aspects, all the shared identity, and yet being able to create individual clusters within different tenants. And also by being container technology agnostic, not being purely focused on Docker, there's an opportunity to put in Rocket, for example, or even Windows containers in the future. OK. So I'll hand it over to Animesh again to cover the rest of the Docker and Cloud Foundry. Thanks, Daniel. That was a great overview of all the projects which are happening at the intersection of Cloud Foundry and Docker and OpenStack. So what I'm going to talk about right now is what's actually happening at the intersection of Docker and Cloud Foundry. So Manuel did touch a bit on this. For example, the Cloud Foundry developer experience. As you know right now, the way it happens is that you either can go through a CLI, through your favorite IDE like Eclipse or Visual Studio, or even from Browser. You can push an application, and once Cloud Foundry deploys it, you get a URL, and you can access it. Very simple. What's happening under the covers? So once you push your application, it's actually hitting what's called the Cloud Controller within Cloud Foundry. The job of Cloud Controller is actually not only to deploy your application, but also to manage the lifecycle of the deployed application. So in that sense, it's the heart and brain of a Cloud Foundry deployment. And once your application is deployed, the route is registered in the router, and that's what you get back. Now behind the scenes, your application is actually getting deployed on top of VM pools, and it's pushed there. Now these are not just any VMs. I mean, these are specialized VMs called DEA VMs or Droplet Execution Agent VMs. So when your application is pushed, it's actually combined with a runtime. So if it's a Java application, it will be combined with a J2E-based runtime or a Java runtime. And then finally, it's actually deployed in containers running on those DEA VMs. And once your application is deployed in those containers, there is a Health Manager component in Cloud Foundry, which is actually responsible to ensure that your application is up and running, and it does by communicating with messages over the NATS messaging bus. So this is the current architecture of Cloud Foundry. Now the container technology which is used currently is Warden. So there is a Warden server, a container manager, and your containers are actually deployed, which is part of one single system. So this is one way to consume containers within Cloud Foundry. Now there is another way. So as I mentioned, Cloud Foundry is not only a runtime platform, but it's also a platform for services. So essentially, that means that you can actually have services which your applications can consume. And to do that, you need a service broker. So there is a Docker service broker which has been written by one of my great friends, Ferran Rodinas. I don't know whether he's here. He has contributed to the open source community, and it's being heavily used in terms of being able to provision Docker instances. So the way it works is that what you get from a CLI, or a browser, or Eclipse is create a service. It fetches the catalog of the services, selects the service you want to provision. And in this case, there is a Docker service, and it goes and creates Docker instances on that back end. Now that back end could actually be running on OpenStack, and this Docker service broker runs on OpenStack as well. It can also run on VMware. Now just provisioning a service is not sufficient in case of Cloud Foundry. You need to bind these services. So the Docker service broker also provides interfaces to be actually creating bindings between the Docker instances and your apps which are running on top of those DEA pools. So these are the two ways in terms of consuming containers within Cloud Foundry. Now the current Cloud Foundry architecture is being rewritten. So what part is being rewritten? The part which you see here, which is the Vodin server, container manager, the NATS, and health manager. Now why is it being rewritten? So first of all, there is one tight coupling. As I mentioned, Cloud Controller is the heart and brain of Cloud Foundry. So that means all the client interactions go through Cloud Controller, and all the other components also need to interact with Cloud Controller. There are also triangular dependencies between Cloud Controller, health manager, and DEAs. And there are situations where health manager and DEAs can participate and make a decision without communicating with the Cloud Controller, which leads to some inconsistencies. Domain specific. So that means Cloud Foundry is targeted towards apps, apps, and only apps. So it makes it very hard to run something like cron-like jobs or any long-running processes. So that's one of the big limitation in the current model. And last but not the least, the Vodin container technology, which I talked about, is very platform-specific. So that means you can run those custom Linux containers. There is no support for other type of containers. So with that, there is a rewrite happening. And what's the goal of that lealite? To be able to run loosely-coupled, one-off tasks and long-running processes. So instead of thinking in terms of apps, thinking in terms of one-off tasks or long-running processes, which can be run on that back-end, by using generic recipes, which can be spawned and run across various container back-ends. So that means you can not only run the Vodin-based containers, but also Docker containers, as well as Windows-based.net containers. So that back-end, that Vodin is now being rewritten in Go, and that's why the name Garden. So Garden is actually ensuring that it's changing some of the back-end parameters. So with that, let me introduce Diego, which is a distributed system that orchestrates containerized workloads. So if you see the three major components of Diego are a brain, a BBS, or a bulletin board system, and then the Garden back-end, which is comprising of cells, which are actually running your containers. What does brain do? So brain's job is actually to schedule deployments using an auction mechanism. And then once the deployments are done, monitor the health. So it actually runs those one-off tasks. A long-running process is it schedules them to be pushed onto the Garden back-end. Then there is bulletin board system. So the job of the bulletin board system is to maintain and up-to-date cache of the state of the whole Diego cluster. So that means that what all long-running tasks are running? What are the new requests coming? And is it inconsistent with the Cloud Controller, et cetera? And finally, as I talked about, the Garden back-end, which is a rewrite of the whole warden container technology, so as to provide an API-based interface to spawn containers. And then the provider has to implement the back-end, whether it's a Linux warden-based container or a Docker container or a .NET container for those Garden APIs. So this is Diego. Looking a little bit deeper into the Diego architecture, if you see at the very bottom for the brain, there is an auctioneer, the job of which is to run auctions, et cetera, so that it can actually push and find ward cells. It can push those long-running processes or tasks. The whole state of the system, as I mentioned, is being maintained by the BBS or the bulletin board system, which is running on top of HCD. At the very top, you see that there is Rep, which actually participates in these auctions and then makes sure whatever cells it is choosing, the tasks are getting pushed there. And finally, there is an API which has been written to actually interface all these functionalities of the Diego back-end. So currently, and now, so this is lattice, so which is essentially what we are doing here is taking the core Diego back-end and then adding some of the core cloud-forming components back. That means the router is coming back, the dropper or the traffic controller is coming back. So what you are getting here is a system which can stand on its own where you can actually run tasks or long-running processes in a very generic way, not being tied to an app-specific domain, and it will be actually running on containers. So lattice is becoming very popular with the open-source community in terms of being a container orchestration mechanism. It's currently supported for AWS and GAE, and the community is actually making great progress in terms of providing support for OpenStack. So that means that you can actually run lattice on top of OpenStack and spawn containers there. So that's lattice. And if we add back some of the other components of Cloud Foundry, for example, the Cloud Controller and a new component which has been written, which is called the Cloud Controller Bridge, you get the next generation of Cloud Foundry, which is Cloud Foundry v3. Now, why did we need to add a Cloud Controller Bridge? So as I was telling, Cloud Controller was very, very app-specific. So the kind of commands it executes is like stage an app, run an app. Diago, or lattice in this case, is going towards that generic model that run these tasks, run long-running processes. So the job of the Cloud Controller Bridge is to take those app-specific requests and translate it into generic tasks and long-running processes based request, which Diago understands. And with that, you get the same user experience which you had, but with some added capabilities. So essentially, now instead of just having a CF push for an application, you're also getting a way to actually push Docker containers on top of Cloud Foundry, a way to push .NET containers on top of Cloud Foundry. And once they are there, you're getting the same URL. So it's the same user experience, but with some enhanced capabilities. So we talked about Cloud Foundry and OpenStack, OpenStack and Docker, and Docker and Cloud Foundry. Now, how all these different technologies coming together? So as I mentioned, what exists now is there is a Docker service broker, which can run on top of OpenStack, and Cloud Foundry, which can also run on top of OpenStack. And if you make requests to that Docker service broker, it will actually spawn Docker containers if your service backend is being configured on top of Cloud Foundry. So this is what is possible now. What's coming next, based on all the things I was talking about, Lattice, Diago, et cetera, is that the whole rewrite of the component where you will have Docker files in addition to build packs and also the whole Diago pool. So that's one work which is happening. And also, as Daniel mentioned, for example, the OpenStack COLA project, where you can actually run the whole OpenStack inside containers as well. So this is definitely what's coming next. What can be a possible future for this? Now, there are some interest in the community, some work which is going on inside the community in terms of also taking the approach which OpenStack has taken with respect to COLA, and trying to make the whole Cloud Foundry management components also run in Docker containers. So that's something in very incubation stages. There are some experimental projects out there. But that's something which can be future. OpenStack is running in containers. The Cloud Foundry management stack is running in containers. Your apps are being spawned on containers on top of those containers. So that's something which can happen. With that, let me just wrap up by talking about what IBM is doing in terms of bringing all these different technologies together. So as I mentioned, IBM made a big bit last year, $1 million investment in BlueBix, which is a platform as a service offering based on top of Cloud Foundry. Now, when BlueBix started, it started as a public pass platform. But over the course of last year, there are other flavors of BlueBix which are available. And in fact, we are also now going to launch very soon BlueBix which you can run in your data center as well. Now, as we move forward, we also added support from some other capabilities. So not only services which are app-specific, we added support for container service and virtual machine service in BlueBix. So what does that mean? For example, take virtual machine service. So that's something which is being spawned on top of OpenStack under the covers and you're getting OpenStack-based virtual machines. There is also a service which actually interfaces with the OpenStack object storage Swift, and that's exposed in BlueBix as well. Docker Container Service. Again, you can actually go to the BlueBix catalog, request Docker containers, and bind them to your apps. Now, in back end, this is also actually running on top of OpenStack. So this is an uptend from BlueBix in terms of bringing all these different technologies, be it OpenStack, Docker, and CloudFondly together. And as the community evolves, as the CloudFondly matures, you'll be seeing a lot of those capabilities coming in BlueBix as well. So with that, there are a lot of other projects and products within IBM which are centered around these open source technologies. So if you're interested, we'll be uploading these slides. Do go through them. Some of them are doing very exciting work in terms of taking these open source technologies and enhancing them for you to consume in a better way. So with that, we covered what we wanted to cover in the agenda in terms of taking you through the intersection of these different technologies together and also by tying how do they come together. If you have any questions, please bring it up. And I will request Manuel and Dan to come on stage. You can also reach to our Twitter handles, which are mentioned there, if you have any questions later on with respect to that. I think everyone wants to go get their swag. And last but not the least, there is a talk I'm giving tomorrow and our team is giving tomorrow about how to run BlueBix on OpenStack. So if you are interested in building a prediction grade past platform on top of OpenStack, or if you like BlueBix enough and want to see how it can be run on top of OpenStack, do join that. That's tomorrow at 2 PM. Thanks. Thank you. Thank you.