 My name is Carl Swanson. I'm the offering manager for IBM Cloud Foundry. Chris? I'm Chris Rosen. I'm the offering manager for our public Kubernetes service in IBM Cloud. So we're going to talk to you today about Cloud Foundry or Kubernetes, a peanut butter and jelly application sandwich. So people know peanut butter and jelly as a delicious sandwich. And we think the two of these technologies together is also delicious, I guess. So we're going to talk about that. So let's start off with Cloud Foundry. What can we talk about Cloud Foundry? No. Chris, I thought you said you're going to remove that slide. No. I understand that we're at CF Summit, but I think all of the people are here to talk about Kubernetes. Fine, if you want to do that. Absolutely. See, two are good at that game. Anyway, OK. All right. In all seriousness, this comes up quite a lot when we're talking to our customers. What type of compute choice do I need to run? Is it Cloud Foundry? Is it Kubernetes? Is it always one or the other? Or when and should they coexist? So that's really what we want to talk about today is that real love relationship that the two have. So let's start off with talking about the basic computes. I think most people in here are familiar with these. None of these are a surprise. And kind of the curve as you increase your focus on business logic and take away from manipulating underlying infrastructure, bare metal, of course, virtual machines, we're all very familiar with those. Containers, not a new technology, but certainly newer on the scene. Cloud Foundry applications, of course, which we all know and love, and functions, serverless type compute option. So let's put in perspective those computes with the type of users you typically find in a development organization. There's two kind of focus-important personas, operators and developers. We kind of know and understand that. What do developers do? What are they responsible for? They're responsible for high throughput development and rapid delivery of quality code. They need easy extensions like services, rapid build and test cycles. They're not focused initially on deploying a full solution and that comes over time. So that's kind of the developer focus. Give them what they need to get through it rapidly and deliver quality code, right? Operators kind of span the other side of the spectrum, responsible for deploying that technology and that application, but to a full solution. Tolerant of and often desire complex tools, flexible deployment features, isolations critical of the hosted environments, and then things like deep, pervasive scaling, HA disaster recovery, right? And of course they have common things beneath them, containers, flexible tool chains, obviously the build packs and microservices. But it takes both of them together to bring out an application and deliver it to customers. So let's talk a bit more about the computer abstractions and then how that applies to those users. It's not working. There we go, yeah. So we start with physical machines, obviously. Move up to virtual machines. There we go. Continue with containers. And of course the Kubernetes now overlaid with that container technology and important piece of the puzzle. And that's kind of the operator experience, right? The developer experience is kind of above that. And as you see on the left, you do sacrifice something to gain something. You sacrifice control of your environment and you lose control of some of the things that you thought you wanted to do, but you gain something in perspective. You gain ease of use and speed, right? So continuing, we have applications and functions and that's kind of how that lays out in kind of a coherent stack. You can actually begin doing something or deploying an application that any one of those stack levels, but the higher up you go, you typically gain speed and ease of use, right? And then when an entire stack is integrated, it delivers all that all that the teams need in one platform, right? So, and here's an example of kind of the difference between a Cloud Foundry and Kubernetes deployment experience, right? On the other side, we have things I barely even understand because they're kind of complicated, right Chris? Anyway, and on the left, we have a Cloud Foundry deployment. And if you guys were watching Dr. Jules this morning talk about Irene, he gave this kind of example of the differences between them, right? So, as we try to decide where the mix of tools comes for the different personas, it's kind of important to get that right because it really accelerates teams quite a bit, right? So from our perspective, we think about the evolution of the platform and what is a platform. And think about 20 years ago, everyone were writing and sanitizing and building and running applications on Java application server because that platform allowed and simplified all of the underlying plumbing to run those applications. Now 20 years ago, it seems like a long time, but fast forward, we're solving the same problems in the Cloud era. But the difference is we're doing it in open source in a very dynamic and ever-changing environment. So as we're moving that workload to Cloud, the developers still have the same three main challenges. How can I deliver things quickly? How can I innovate rapidly? How can I scale up or down at a moment's notice to meet my user's expectations and requirements regardless of the time of day or the time of season for my application? And then the last thing is really around availability, stability, uptime, back to the operational side of the house. Those are what the operators are concerned about. I need the nines of uptime to meet my SLA. I need to be able to roll out new versions. It's great that someone's over here developing and adding all these features and buzzes and whistles and all these things, but the reality is someone ultimately is responsible to run it and ensure its availability. So in any realistic dev project, there are a variety of different use cases and requirements to be able to deliver on those objectives. Now, some components may require a stateless web application. Some components may require some high resource intensive, whether it's a database or other type of workload that's very transactional and those have very different characteristics. It may be something that's event driven serverless. So I'm just sitting out, I'm waiting for some action to take place, something to occur. Now I run an action, I do something else as a result of that. So the challenge is developers have to learn those three different environments and what we're trying to do is simplify the platform to ensure ease of use across all those different requirements, those different use cases in one platform. So as I said, the complexity comes from today. When you think about kind of those, we simplified it to three kind of compute choices here, whether it's Cloud Foundry, Containers, or OpenWesk for Event Driven Serverless, think Lambda capabilities, that they've each been developed in their own silo. So developers naturally have had to gravitate toward one silo versus another, which then increases the complexity of the technology to run it because now we need to handle three different silo types of technologies in one place, or I only know one versus another. So that's the real challenge for developers is that once they're in a silo, they're really stuck in that silo unless they have a platform to be able to run a variety of compute. So if you think about the components of a stack, and you could argue what component should go in a stack, but in this simplified view, we think about the foundation, the building block layer, the actual container engine. Now, it's gone through a lot of change, there's been a lot of projects, but we're really seeing a lot of convergence, at least in my world, to container D as that engine of choice, kind of the standardization. As we move up the stack, 18 months, two years ago, it was a real war if someone said swarm versus Kubernetes, they might fight each other over which one they felt was gonna win the container orchestration war. Fast forward, I think it's very clear and evident to everyone that Kubernetes was chosen by you, by the ecosystem, by the open source community to leverage Kubernetes as that container orchestration. Now, some of the good things as we move up the stack, there's already been convergence and agreement across the different silos of compute about how do we handle open service broker with a service catalog to do that consistently across Kubernetes and Cloud Foundry. At the top, when you think about the service mesh, so is the complexity of my microservices architecture as it grows and grows, I need some insight, some in-depth telemetry, some layered abstract regardless of where that's running. So we've really standardized on things like Istio and sidecar technology with Envoy to be able to deliver that microservice capability. So what does that all mean? It basically brings it together into one unified stack. So now, as a developer, I've got a core base of capability in which I'm building on top of. A lot of times you'll see that's where the operation side of the house is gonna live in that lower layer of the stack. As a developer or development team or development organization, based on my requirements, is it stateless, is it stateful, is it event driven, I can choose the type of compute to meet those requirements. Instead of taking my requirements saying, well, we're all Cloud Foundry all the time, we're all containers all the time, we're all event driven all the time, pick the type of compute that's gonna help with that given component. When you think about breaking down your apps to microservices, the microservices will not have the same compute requirements. So what we wanna do is deliver that options that way you've got the flexibility to run and meet it with the minimal amount of effort as possible. All right, let's take a step back and talk about what some of the stuff Chris talked about between functions, applications, containers, and how do you decide, and we've talked about it a bit already, how do you decide which of the computes you want to use, right? It comes down to basically what are your developed more productive in and what do they perhaps know better? Control over the environment, lack or more control and consistency between them, right? So again, we kind of have a language framework that can typically be used on any platform, bare metal and VMs as it has for a long time. Those can be certainly deployed in containers or Cloud Foundry applications as well and then functions kind of sits there. But it really comes down to what level of control and performance do you need versus speed of development delivery, right? Sometimes in some cases or for some application components you need a great deal of tuning, you need a great deal of speed, you need a great deal of performance, that's why bare metal exists in certain Cloud vendors. But as you move up, you sacrifice control but you do that with the knowledge that you're gaining something which is typically ease and speed of deployment. So when do you need these things and do they fall into different phases, right? So typically day one operations are kind of pretty straightforward. You typically see security as something that's very important. Scale from a basic perspective is pretty important. Knowing how to manage the infrastructure, whether it's going ahead and designing the different containers and stuff you use or deciding on isolation choices which is typically very important. But what happens is when that day one quote unquote is finished and did you kind of begins, you then have to settle into operations, right? You actually have to operate it. You have to have really good and sophisticated DevOps to make sure that when you push things through code it goes very smoothly. You have to have robust logging that actually merges together logging from multiple components and actually processes that and centralizes it. And then you need monitoring to make sure that the things are operating the way they should. Allows you to troubleshooting with logging, making sure you understand the alerts that are happening and designing dashboards and such to make sure you understand it. So part of the decision is not just how do I onboard and start an application. It's just as important as how do I onboard and start an application but then how do I take care of it long term? And that's kind of where that balance is important. Right, so good. So IBM Cloud Kubernetes Service, IKS for short, the C is silent. This is our managed offering in the Kubernetes space. So as Carl likes to point out to me, every day the complexities of running in Kubernetes from a developer perspective. Not every day, every other day. Every day. But also from an operations perspective, Kubernetes is hard. The Kubernetes stack is hard. From container D to fluent D to Prometheus to security to Kubernetes itself, there's a lot of open source projects and I forgot Calico for networking. How do we manage the stack of that? So that's really what we're focused on is simplifying the lifecycle of your Kubernetes clusters so that way you as developers are just deploying applications, adding innovation, helping your line of business objectives Oh no, a new version of Kubernetes came out from the community. Is it gonna break anything in my entire stack? Instead, let us handle the lifecycle for you. And the real value out of IBM Cloud is to extend the capabilities with higher value services. So my application that I've modernized and now I'm running in the cloud, I wanna extend its capabilities. I wanna use something like Watson virtual visual recognition or speech to text to create some cool chat bot to help engage my users in a more meaningful manner. And you'll see, you know, obviously we're part of the CNCF conformance so that way as an end user, you know that the same building blocks that you use, the same YAML, the same everything are consistent in any environment. So there's, you know, coming back to containers, the whole premise of eliminating vendor lock in and having that portability, you get that as you move up the stack and then orchestration level as well. So I could spend an hour on IKS but Carl said I'm limited. So with that, I'll hand it back to you, sir. So, and just to be clear, I only tell you it's difficult on Tuesdays and Thursdays, not every single day. No, I mean, Kubernetes is difficult and container organization is difficult for a reason. It's a difficult space. It's a difficult concept to get around. So that complexity is important, but it's important for the right people. And in contrast, the Cloud Foundry platform delivers things that developer teams want but never want to build themselves. We've gotten to the point where they're out of the path of reinventing the wheel essentially every time. They want a simplified developer experience for rapid, with rapid being the really important word there, rapid development iteration. If it takes you a long time to actually make a change and then test it, that doesn't really go well with your cycle of delivery. Automatic and rapid compilation and deployment is very important. The steps to do that, highly scalable, spelled wrong, highly scalable is obviously very important. Both platforms do that very, very maturely, easily integrated with a range of DevOps tools. We can share the DevOps tools between the two platforms, but obviously it accelerates that as well. And more importantly, full application lifecycle management. So you can actually not only develop and deploy, but you can manage and change, scale up and scale down your application, change its memory requirements or what have you. So the bottom line here is Cloud Foundry lets you move faster and focus on your unique code and business logic, which is after all what you're doing, right? Versus common and countlessly repeated infrastructure tasks. So taking all that, the compute basis and the different users and kind of the different tools here, obviously this brings us to one of the subjects of the summit, which for example, the leadership children, the CTO of the CFF, spoke this morning about, and I grabbed it because I really liked it, adaptation and evolution of large software products. And that's very, very appropriate. He spoke very well about that. Project Irene is one of those evolutionary steps. It's mutational change in the Cloud Foundry and in Kubernetes itself, I suppose, that we believe becomes a better, a positive evolutionary step. So it's the convergence of pieces of technology with Cloud Foundry and Kubernetes and the Irene project was the name of it. And its basic task is enabling a plugin, a pluggable scheduling for a Cloud Foundry application runtime, right? Operators can choose between either the Diego scheduler, which is the default, or Kubernetes, which is the new one, to orchestrate applications and the container instances, right? The goal, of course, behind it and what you're trying to get out of it is, and this is important, reusing an existing Kubernetes cluster infrastructure, right? Being able to work together in that environment or in fact, actually use that as your underlying IaaS, it could very well be new, to host applications deployed by Cloud Foundry, right? And what that gives us is, it allows us to use Kubernetes tools, processes and workflows to manipulate containers in the same way on both layers. And it really simplifies the overall container management. So by this kind of merge, the overall change is hopefully gonna bring about not only more advanced capabilities, better fine-tuning, increased continued speed of delivery, more configuration options like we talked about and that depth of complexity, but also simplification and less effort, right? And of course, this brings us to what we are delivering, what we have delivered to bring together Cloud Foundry Kubernetes. We delivered Cloud Foundry Enterprise Environment last year, which is Cloud Foundry built on top of the IBM and Kubernetes service to create and manage isolated PaaS environments for hosting applications exclusively for a given enterprise, right? Self-service deployment, elastic consumption, rapid provisioning and complete access to both Cloud Foundry and Kubernetes admin operations, which is kind of important. Also mentioned, it just happens to also work on top of our IBM Cloud Private offering as well. So just a different flavor with the same, with the same look, fear and operation, although let me say that final delivery is a future unnamed, unpromised date, so. All right, so again, why bring the two technologies together, right? Every development organization has a story, basically a mission, right? And those stories have heroes. And in this case, those are developers and operators, right? And their mission is enhanced, simplified and more successful when they have the right tools or weapons for the job. So Cloud Foundry and Kubernetes are those tools that when wielded as weapons by the right hero can conquer any challenge. And the heroes we need and the heroes we deserve, I'd way too much fun on this. So, peanut butter and jelly sandwich. Yes, Chris, you are the one in heels. And of course, of course we'll give them weapons as well. So just to, the next steps, the call to action. And it's a call to action for you guys, right? It's a call to action. So many cloud companies were involved in the Irene project across the space. SUSE, for example, the other day, just a day or two ago, released their cloud application platform 1.4. And from what I understand from the blog and from talking to these guys here, they also have a technology preview which demonstrates the merging of CF and Kubernetes with Irene. So it's been done twice now, one by us, by them and other people as well, right? So Project Irene, you can learn a lot more information. Of course, our offering is deployed there and there's a nice TechCrunch article that came out just Google it, you'll find it. And they talked about the whole thing happening at the summit. So I think that's the end. Chris and I are happy to engage and talk about this at any opportunity. And hopefully we created a pretty good sandwich. Does it? And yeah, any questions? We're happy to take questions. Oh, yeah, yeah, yeah, yeah. Any questions? So we're between you and Beard? So if you have any more, catch us in the hallways or whatever, and of course we're easily contactable. So that's it.