 So welcome everyone to Cloud Foundry 101 for Kubernetes Users. I have the pleasure to introduce you to Alex Sinko. He works for Pivotal. He's currently a member of the Irene team and he previously worked on the Cloud Foundry Container runtime. And here is Stefan. He works at IBM. He also, sorry. Hi. So here is Stefan. He works at IBM. Also works in Irene. Before that, he worked on BitService and he really loves programming in Ruby. And I suppose people here know something about Kubernetes, so Kubernetes users. But let's do some quick refresher. This is like, I hope it's typical Kubernetes application. And as you can see, there's like ingress, service, ports, and they connect to some database services and ports, and they have some secret to connect to it. And there are some invisible parts such as security policies, maybe config maps, maybe service accounts, things, and docker. And yeah, I think that you've done it, and it doesn't look that hard. It doesn't look complicated. But if you introduce more applications, it's basically everything is the same, except code is different. And yeah, from a Kubernetes point of view, most of the same and all YAML templates are mostly the same. It's just tiny changes maybe in docker files. And what people usually do, they just do copy-paste, copy one YAML to another, copy docker files. And I think this is a problem. And actually the question, can we do better than this and just copy YAML files? And the answer, as I hope you guessed, because you're on Cloud Foundry Summit, is Cloud Foundry. Because Cloud Foundry can do it for you. And that because Cloud Foundry and Kubernetes are very similar. They both based on the Google Borg, which was doing the same thing as Cloud Foundry and Kubernetes, does, you just declare desired state of the world. And it will do everything for you. It will deploy applications, start application, will run the code, and everything will work. And it's not only that. The common things, one more thing is YAML, because everyone wants to be certified YAML developer. And it runs applications in containers, both in Cloud Foundry. It's a container sent in Kubernetes, like basically docker containers. And there are two main concepts, long-running processes that has to be monitored and, say, restart it if needed, and then to be monitored they have some health checks and tasks that just execute once, and when they stop, they stop. But that's, if they're so similar, you will think that I just still use Kubernetes, but there's something that is unique to CF. And Stefan will tell us about it. Right, so if you come from a Kubernetes world, you may be used to be able to do everything, right? There is enormous flexibility. You can do all sorts of things with Kubernetes, declare whatever you want to do. In Cloud Foundry, it's a little bit different. Cloud Foundry has opinions, and Cloud Foundry is mostly about the application developer. So this is a tweet that is, I think, around four years old or so, and the concept of CF push is actually even older. And the idea is everything in Cloud Foundry is centered around that concept of the developer pushing code from the local workstation, from your hard disk. Then you push it to the cloud, and the cloud will take care of what needs to happen to that application. So this is the most important opinion in Cloud Foundry. It doesn't give you all the points to configure something. It gives you only the points where things you should have and say about how things work. So this is the strongest point about Cloud Foundry. So with these opinions comes a set of things, a set of objects that are present in Cloud Foundry that are important to know. So for instance, there's organizations, and there's spaces, and there's roles. So instead of centering everything around an operator, it is everything centered around the application developer about the person that is pushing the application or making sure that the application is in the right state and additional things. Also, Cloud Foundry has opinions about routing. So there's a very well-defined way of how traffic reaches your application and how the router knows about your application and what should happen in what state of your application. And also services is another important concept. It's a first-class citizen in Cloud Foundry. Services are something that exists, that can be bound to, and everything that needs to be managed to get your application to access the services. So CfPush is that one single thing. It's not, of course, not the only command that you can run on Cloud Foundry, but that's the main focus. So you're, as an application developer, you're mostly concerned about your application code itself that implements the business logic, whatever you want to achieve. And once you push it to the Cloud Foundry instance, you basically let go and let the platform do its thing and make sure it's available. So this is what it's all about. It's about that user experience that CfPush to get your stuff over to Cloud Foundry. Another differentiator is that in many cases, Cloud Foundry, it is about HTTP applications, applications that are reachable via the HTTP protocol, which isn't to say that it's not possible to do others. There is TCP routing, so you can do basically also the arbitrary applications in Cloud Foundry, but the majority of workflows is really centered around the idea of there is a web application that is running. The next concept that is unique to Cloud Foundry is the idea of BuildPacks. So BuildPacks are basically another expression of these opinions. How should you go from your application code to something that is actually responding to the HTTP protocol? So that could be some HTTP server coming with your BuildPack. That could be something that needs to compile any source code or just bundle it together in certain ways, maybe create a wall file or a char file or whatever it is. So BuildPacks take everything that needs to be done from your application to something that is actually running or listening on some port, maybe 8080 or something else. BuildPacks also make it easy to update versions of your applications or if you have dependencies on external things in the Ruby world, for instance, there is gems. So the BuildPack will download all the dependencies of your application and make sure your application can run in the right way. So BuildPacks are mostly language or framework specific. So there is a number of BuildPacks that come with the Cloud Foundry platform where we express the opinions that we have around how a Ruby app or how a set of static HTML files should be deployed. So if you have a couple of files that you just want to push somewhere and serve with a static web server, there's the nginx BuildPack or there's the static file BuildPack for Ruby. There's a Ruby BuildPack that comes with Ruby implementation also with the tools to download the gems that are required. So you can really start only with your applications files and everything else will be taken care of by the BuildPack. So this is some of the core BuildPacks that come with the platform. There's also community BuildPacks. So people have contributed to the Cloud Foundry platform, BuildPacks about other frameworks, about other languages, and there's even the way to bring your own BuildPacks since it's an open source product. It's easy to bring your own BuildPack and do whatever you want to do. So does BuildPack actually create image for us, Docker image? You would think that it actually, what comes out of that is a container image, but it's not. It's in between that Cloud Foundry again has opinions about and this is the idea of a Droplet. The Droplet is that intermediate BuildPack, sorry, that intermediate Build product that comes out of the Build process. So the application and the BuildPack together, that output is what we call the Droplet. And only once you take that Droplet and add it to a root file system, you come up with something that is known as the application image that can then be used to create a container. But that's a little bit complicated. Why do you just see a push and create an image? Why do you need this intermediate step? Yeah, that's a good question. And the answer to that is actually that when we run applications in the Cloud, it's not enough to care only about the application developer. This is the main focus in Cloud Foundry, but we also have people running the platform. We have the operators of the Cloud Foundry platform. The separation between Droplets and the actual final image, we get the chance to actually update the root file system without bothering the application developer. So as a platform operator, you can patch your root file system, restage the applications, and all the security fixes that you have added to the root file system will automatically apply to all of the applications that are running, which is very important for small and also larger, of course, platform developers. Okay, let's now talk about something that we come here to. Here, how Kubernetes features map to Cloud Foundry features and how it all works. So let's just start from the application access. So applications in Kubernetes run as pods, and they're ephemeral, and they're multiple pods, and to load balad them, you deploy service. You create service in Kubernetes, and the service can be exported to the Internet using Notepad, a load balancer, or Ingress, and multiple options in Kubernetes. What about CF? Yeah, in CF, there is one single idea of how application traffic reaches your application from the outside, and this is the GoWater component. So the GoWater is something that sits there and waits for registration messages. When your application comes up, becomes healthy, a message is sent to the GoWater, and it will, from then on, will route traffic to that application. There is this one idea, and that is central to Cloud Foundry, and there is no other way around doing this. So when you deploy application, you actually want to access database surprise, and in Kubernetes, you either bring your own services and then do some secrets manually, or you can try to deploy service catalog, and I think it comes from CF. Right, so the idea of having services as a first-class citizen, as an object that you can manage, bind to, and all the things, actually was extracted from Cloud Foundry, and there is where it has its natural place, so an application just binds to a service, and you can instantiate a service, and therefore you can access services from the application. You don't have to deal with the details of creating that service unless you want to become a service provider. And by the way, if you want to find out how to bring your own services from Kubernetes to Cloud Foundry, so there is one interesting talk. Unfortunately, it's happening right now, but you can check the recording later. And since we started about secrets, so in Kubernetes, if you want to, usually when you connect to database, you want to somehow get the secrets and the special secrets object, and if you use some custom configuration, you use ConfigMap, which will create file on the disk, and there are also many more options. You can set environment variables in the container, and multiple options as usual in Kubernetes. What about Cloud Foundry? You could argue that there is not really a need to manage secrets in Cloud Foundry, because in the end, if you ask why do you need secrets, well, you need secrets in order to be able to access a service. And when you have that service binding as a first-class citizen, what happens in Cloud Foundry is once you bind to that service, all the necessary configuration as well as secrets get injected into your application's environment, and you just have to consume an environment variable where the application can find all of the things that are needed. So there is not really a need to do that from the application perspective. However, if you really want to do that for whatever reason, maybe for some customization or because your application is written in a certain style, there is other environment variables. These are called user-provided environment variables where you can achieve a similar configuration using a manual approach. Yeah, and then next part, when you deploy application, you want it to be highly available, so you want to place container somehow so they won't influence each other. And in Kubernetes, I wrote multiple lots of ways because there are so many ways and they have very long names. They don't fit the slide, it's affinity and affinity rules, and you can base it on labels so it can be on different AZs on same AZ or in different VMs, so maybe some post needs to run with some other posts, and then you can specify different priorities on the post, so maybe some nodes will allow to run only some specific posts, and yeah, many options, many options. What about Cloud Foundry? As always, it's much simpler in Cloud Foundry. There is one default scheduler that's called Diego, and as an application developer, you don't have almost no say about container placement. Diego does the right thing because Cloud Foundry is opinionated and will make sure that your application is running on the right nodes and will make sure that it's up in all the things. Having said that, there is one way to actually influence placement that is the concept of isolation segments so that you can implicitly specify which parts of your deployment, of your infrastructure, the application is actually running and how it's distributed, but this is way more coarse-grained than all the things that you have available in Kubernetes. Yeah, and as usual for storage, Kubernetes has many options, so it depends. Again, you can use Cloud-specific volumes like Google Storage or IBM Storage, or you can use NFS, SMB, it's connected easily, or some other external services like Gloucester Fares, or you can even use local disk to store information. So many ways to store data in Kubernetes. In Cloud Foundry, it's way simpler again because we recommend to follow the 12-factor pattern or manifesto and that one says any data that needs to persist must be stored in a stateful backing service, typically a database. So what you usually do in Cloud Foundry is you have an object store or you have a database where the application can actually persist stuff. Again, there is an option in Cloud Foundry and that is created by the Percy project where you can actually do mount NFS or SMB volumes so you can actually have a disk that is not ephemeral but kind of the 80% of the applications that we see is actually not using persistence in local disks but actually goes out and stores it, for instance, in an object store. So, as you said, the long-run process is central in both Cloud Foundry and Kubernetes and to make it long-run, we need to monitor it and make sure that if it's broken, it should be restarted. So how to do it in Kubernetes? There are two different things, Linus probe and Ragnus probe. If port is not ready, it just doesn't serve traffic. If it's not alive, it gets recreated and they both support the same set of checks. It's either just HTTP get or just connected to TCP port socket. But if you need something fancy, you can basically execute any command on the container and verify that your application is up and running. Cloud Foundry, again, it's very straightforward. There are three types of health checks. There is HTTP. So just checking whether something is responding via HTTP protocol on the pre-configured port. Then there is the port check. That is especially interesting for TCP applications that we discussed before. And then there's a third kind of check to make sure that in a process actually exists and the application is considered healthy when that process is up and running. Yeah. And also, you want to monitor it properly. You want to see the metrics. And in Kubernetes, you have to deploy something. You have to deploy a metric service. But also, if you want to use dashboard, you need to deploy obsolete hipster, unfortunately. And then you need to something to store metrics. So people use promise use. And there are multiple things that you have to add to the class to make it show you metrics and store metrics. In Cloud Foundry, it's two-fold. There is, of course, platform metrics. So something that is interesting for the platform operator and that is built into the platform. But from the application perspective, there isn't really a first-level concept of metrics. So, of course, you can build this yourself and make it part of the application infrastructure. And then, of course, you can use services to actually make sure that your events or metrics actually end up in the right infrastructure. But from an application perspective, there isn't really a high-level concept that is sort of available in Cloud Foundry. Yeah. And where metrics are logs. So in Kubernetes, logs are just stored on the disk in plain text or in JSON and on specific location. And then you can access these logs from directly. Kubernetes knows this known location. You can just run kubectl logs. But if you want to forward them, people just deploy a demand set which will forward all the logs to some different storage, some metric storage, some log storage. And that's how you do it. Cloud Foundry, it's, again, about the user experience, mostly as an application developer. So if you have an application with several instances, all of the logs of all of the instances are merged together into one stream of logs. And they get very easily piped into your terminal. So you can just call CFLogs and see all the logs from all your applications' instances. And you just switch the application name to see logs from a different instance. So it's all, like, done for you by a component that's called LoggerGitter. Same idea, again. Logs are a central concept. And therefore are catered for. Yeah. And then one nice concept that Kubernetes has is automatic rollouts and rollbacks. So there is deployment object, which allows you to deploy a new version. And when you deploy a new version with deployment, it will scale internal replica set, new replica set to the desired size and downscale existing one. And you can stop it at any moment and then roll back to previous version, which is very nice. What about CF? Yeah, that's something that really doesn't exist in Cloud Foundry. There is extensions coming, as you might heard before. There's new features. But right now, there is nothing like automated rollouts and rollbacks. It is trivial, of course, with external scripting. There is the established pattern of green blue deployments that you can use. And since the command line of Cloud Foundry is so simple, it's not very hard to build yourself. But it's not part of the platform yet. Yeah. And then the other concept is batch execution. So if you want to execute some single-round script, again, so many choices in Kubernetes. So you can reuse jobs, which will just run container with the script. Or you can use pre-start script, which will start something before start your main application. Or you can use init container, which will start before your port starts. So many choices. What about Cloud Foundry? No choice at all. It's just the concept of tasks. So this is, again, a concept that is sent side-by-side with the application. And it just runs to completion and does its thing. Yeah. And now we'll talk a little bit how it works off the map. So in Kubernetes, it's very operator-specific. You just have control plane. And then you can do whatever you want to do. You can operate it. You can choose so many things. You guessed the answer in Cloud Foundry. It's, again, a very clear separation. There is two roles. Basically, there is the application developer or application developer that is also deploying via CF push. And there is the platform operator. Both use different tools. Both use different metrics, and so on. So there's a very clear distinction between them. Yeah. Let's see the typical developer workflow. So I want to deploy a new application in Kubernetes. That happens. So first, create Docker image. Usually, I just Google it, find some existing Docker image, replace URL for GitHub repo from existing, from the source, Docker image to my own. Then I put this Docker image to register. I might be creating something. Then I get credentials for database, because it's all deployed in Kubernetes. Put it in some specified secret. And then I want to deploy. I almost have to deploy. And I create Kubernetes spec file with my multiple YAML sections. It's service, all these things, as I mentioned. Service, deployment, policies. And again, I don't write it because it's impossible to write. I just copy some existing and replace names with said. It's very easy. Everyone loves replacing it. And then when I do it, I do just apply this file, keep cartel apply, and then I just run this command and wait for it to finish. And let's see Cloud Foundry workflow. I think it might have more steps, I hope. Yeah. That's all. You guessed it, right? That's all you need to do when you deploy a new application. It's, again, CF push. And if you're using services, you only once need to do the defined service. So the application knows about the service instance and keeps the configuration for future pushes. Yeah. And now updating application because, yeah, for some reason you need to write new code. And I mean, if you run in production, you for sure use some pipeline that will deploy it for you. But if you try to run it in, like, develop and follow and want to test it manually. So you want to do, again, update Docker image, maybe just update the manually build it and then just change it to the new code, then push this Docker image to registry because it has to be somewhere. Then you change the spec command spec to use this new image. Then apply the spec and then wait again until it's deployed. Yeah. So simple. Indeed. It's simple. Sorry. Are we missing a slide? No. I just clicked and you clicked. Okay. That was a race condition. Yeah. I mean, obviously, right, CF push. Nothing else needs to be done in Cloud Foundry to update your application. You just push your code again. Yeah. So I hope now you really want to start, use Cloud Foundry, and you can use public providers such as speedups, IBM Cloud or maybe something else. And if you have Kubernetes cluster, you can even deploy it yourself. It will take 30 seconds. Yeah. You'll find out. Yeah. And what you got is you just do CF push and then I really does magic. And as a result, you have application in Kubernetes, which almost looks the same as I showed on first slide. Almost because we haven't finished the project yet. So there are some missing parts, but yeah, very, very close. And let's see how it looks. Unfortunately, we don't have so much time, but you can see there some fancy names and you can take a pictures. Unfortunately, it's like three minutes left for the talk. We can describe it afterwards, or you can just come to irony sessions. So check irony sessions tomorrow or just find us and talk to us and we'll explain it for you. Thank you for your time. Here's your role for our talk. You can see it. Thank you. Questions? Feel free to find us. Yes. So if your question was, why would you use Cloud Foundry or Kubernetes? Why would you choose Cloud Foundry? Why would you choose Kubernetes? So if you just deploy application, I would say Cloud Foundry. If you want to experiment a lot, if you like choosing things, use Kubernetes. If you want to deploy database and kind of don't like Bosch, you can use Kubernetes. If you have sounds that really need persistent storage, you can do it in Cloud Foundry, but maybe in Kubernetes it will be easier. If you like YAML, you definitely choose Kubernetes. What else? But you don't have to choose. You can deploy Cloud Foundry out of Kubernetes and that's like maybe best of two worlds. I hope it's best of two worlds. Yeah. What is not as big YAML as Cloud Foundry manifest? Any more questions? All right. Thank you very much.