 Hey, my name is Neven. I'm from Pivotal. I'm a platform architect, developer by trade. How many developers are here? Wow. Almost everyone. Great. Any operators of Cloud Foundry? Few of them. Great. OK. I'll have to disappoint you. This is a more developer topic, but you're welcome to stay, please. There is a lot of insights in this talk, hopefully. So let's get started. The purpose of this talk is to explore some of the experiences that developers have with using Cloud Foundry and Kubernetes. And we want to look at those two platforms side by side and see, where should I deploy my apps? Why would I care about deploying on one or the other platform? Few words about myself. As I said, developer, you can find me on Twitter's and GitHub's and the other social media. I did post some source code for this, so find it on my Twitter or look at the slides later. So what is developer experience? Developer experience is a user experience that's applied to developers, because developers are users as well. So what are some of the experiences that developers have? Well, they use developer tools, IDEs, frameworks, libraries, APIs, and of course, they use platforms. So that's what I want to focus in this talk. What is the developer experience using these two platforms? Specifically, we'll look at the Cloud Foundry, traditionally called Cloud Foundry, or Cloud Foundry application runtime, and the Cloud Foundry container runtime, or Kubernetes implementation of that. So before we get started, we probably should look at the Cloud Platform abstractions. So ultimately, everything runs on hardware. That hardware, we do implement some VMs using hypervisors, virtualization. We do implement some containers on top of that. We have applications that are leveraging some of that container platforms. And finally, we have abstraction called functions as a service for some of the event-driven Lambda-style functional workloads. So I'm asserting that the further you go up the platform hierarchy, your developer experience is going to be different. You're going to need to worry about less things, different things, possibly. But also, you might be limited in some of the workloads that could not really run on the functional service, for example. But that comes with a price. So if you want more flexibility, you need to worry about more things. So it's always a fine balance. Where should I run my workloads? Anyhow, for more details, look at Richard Sirotor's talk from last year's spring one, December last year. He gets into details of these abstractions, and it's really great. Take a look. So what do I care as a developer? So what are the things that I typically do? I'm developing code. So I'm developing my apps. There's a purpose I do that. So I want to run those apps somewhere. So I want to maybe deploy those applications, prepare them from deployment, maybe deploy them to production, to dev test, UA, UAT, five, seven different stages possibly. I might want to connect them to some external systems, databases, queues, message queues, maybe some other microservices, stuff like that. Also, I want to update my application. I want to do some rolling upgrades possibly. Also, I want to see what's going on with my app. I want to look at the logs. I want to look at some metrics, some monitoring, stuff like that. And of course, I want to make my applications a bit more resilient to the problems that I have in my underlying infrastructure or the other apps. So there is a lot of different aspects of developers everyday's life. So given that, so what do I need to know as a developer? So of course, I need to know how I build my application. How do I package my application? Maybe I need to containerize my application. So I need to know about the container image. Maybe I need to build a Docker file. Maybe I need to, maybe I use some other technology, OCI compliant technology. Maybe I need to optimize this container for the best performance, specifically with Java apps. We might want to look at some of the memory heuristics. We want to optimize the size of the heap size, some of the garbage collectors, and stuff like that. Maybe I want to configure my application for logging, for monitoring. Maybe I want to do some tracing of the application. Also, I might need to, there's maybe some different specifics about my platform where I run. So no platform is the same, hopefully, or yeah. I do need to possibly configure my load balancing, my DNS, my certificates, a lot of different constructs. You need to configure security, some networking policy. So there's a lot, a lot of things that I need to worry about as a developer. Would you agree with that? Who wants to think about all these different things? One person, two people. You must be an operator. Anyhow, so here are some assumptions that I assume that you know, so I'm not going to go into details of that. So I definitely know how you build your app. You probably know how to connect to the external systems. You probably used the Cloud Foundry before, or Kubernetes, so you know how to connect to that. And how many of you have done CF push so far? OK, good assumption, right? Well, we are Cloud Foundry Summit, right? So let's take a look at the developers. Here are some things that I want to run through, and then we'll reflect on those and draw some conclusions. So source code examples, feel free to browse through them. I also recorded some demo screens and screen casts. Because I'm not going to run demos, we only have half an hour here. But happy to find us upstairs at the pivotal booth. We can do some of those demos, and we can show you some of the stuff. So self-service platforms make my life easy. Who said that? Who would like to see self-servicing platform? I don't need to wait for all those tickets, right? I need to create my database. Oh, wait for 28 days. OK, a week, right? Anyhow, so how do we interact with platform? Both platforms are container-based platforms, so Cloud Foundry's container-based platform based on Diego. Kubernetes is also container-based platform. We interact in the same way, right? So we have a client. We have, essentially, a developer API. It's our contract with the platform. So with Cloud Foundry, that's CFCLI. There's other clients as well, other tooling. And Kubernetes has a very similar Go client, kubectl or kubectl, many people call it differently. Ultimately, it's the same thing, right? It's a developer API, and I interact with a developer API. So how do I log in? See if I log in. Kubernetes, I actually need to get credentials. I need to configure my kubectl config file for different platforms. It's very similar. Get credentials on PKS or Google Cloud for GKR or AKS, there's a lot of different flavors. And finally, I can use my contacts for my specific cluster and get details. How do I deploy an application? So here's an example. I call it the beer service. I guess any objections to beer tonight? No? OK. Yeah, anyhow. So it's a very simple Spring Boot Java app. Ultimately, it's the same app for Cloud Foundry and Kubernetes. On Kubernetes, I had to build a Docker file, and I have some other Java tooling. Specifically, it's a Spotify plugin that helps me build a Docker image from my Docker file. You don't have to do that. Of course, you can build that externally to your Maven plugin or Gradle plugin. You could just use Docker, build, and build the image outside of your application. Great. You can readily download them, look at some of the screencasts. It's a Java Spring Boot app. It could have been any other app. At Piotl, we really like Spring Boot. How many of you have played with Spring Boot? Show hands. Oh, nice. More than two-thirds of the room. So how do we build an application? Well, very simple, clean package. How do we push an app? Well, just see if push. And the app gets deployed. Here, I specify from a command line. I didn't use the manifest. I'll show you manifest in a moment. How do they deploy to Kubernetes? Well, very similar. Build the application. But also, I have extra steps that I need to push the application, not the application. I build an image, and image needs to be deployed to some registry. So that Docker Hub, or Harbor, or GCR, ECR, ACR, there is a lot of different image registries. Hopefully, the image will get scanned upon your push. So for some vulnerabilities and things like that, your operator team can help you with that, set up some of those things. Great. So now we have the image in the registry, and we are ready to deploy this app. So I can do a command from a command line. I can run the image. And I specify my image with a specific tag. I run it on port 8080. But we are not there yet. I have a deployment on Kubernetes, but I need to expose my application as a service. In this specific example, I'm using a low balancer. So I expose my deployment called beer service, and I'm going to serve it on a port 80. So these things are very similar. So CF push, Kubernetes, build an image, run an image. Essentially, there is an extra step where I need to build my image and push it to container registry. I can deploy it with manifests. Manifests for Cloud Foundries should be very simple. I could put more things here, a number of instances, memory, how many instances, backing services, a few other things. And in Kubernetes, I have a deployment file, and I have a service file. Typically, we would combine those two. It's a one single deployment, deployment artifact, which is a deployment and a service. How do we scale an application? Well, CF scale or Cube CTL scale. So it's a very, very similar. I provided here some endpoint entries. They are slightly different. Kubernetes, we have the environment host name. When we deploy to Cloud Foundry, Cloud Foundry is going to provide some VCAP services, sorry, VCAP environment variables so we can see which instance we are talking to. Connecting to database, so on Cloud Foundry, we have a readily available marketplace that hopefully our platform team has configured. So I would have my PMySQL, my Postgres, or maybe some other external service that I'm going to hard code and use a user-provided service. And then those credentials would be provided to me as environment variables. So my Spring Boot app can actually readily just look at the environment variables, parse it, and use it, and create everything on fly. On Kubernetes, things are similar. I could possibly, because Kubernetes is really great for some data services as well, I could create my database right there. Or I could leverage some of the similar service brokers through the Open Service Broker API, and I could create my services through the service brokers, through some config maps, and things like that. Great. Also, I could connect to some other type of databases, no SQL database such as Redis or Mongo. Also, I could connect to some native public clouds. How many of you run on native public clouds? Google, Amazon, Azure? It's about half a people. The other half I would assume on vSphere or OpenStack. Yeah, great. So sometimes I do have some native public cloud services, such as data stores, blob stores, or some other constructs. So at Cloud Foundry, we have service brokers for each one of the clouds, Google, Azure, Amazon. And we could leverage similar Open Service Broker API as well to configure those on Kubernetes. How do I update my application? So typically, both platforms do provide zero downtime application updates. Cloud Foundry traditionally provides that through the use of blue-green deployments and through the mapping alteration. But that's often managed externally. So I would have a concur or Jenkins that's driving my pipelines and implementing that blue-green deployment. And we have a new tool coming up, Spinnaker, that's going to orchestrate and sort of stateful deployments, continuous deployments. And I did reference two videos here, actually. They are interesting to watch. So one video is on Spinnaker from John Snyder from just a few weeks ago at Spring, one platform in Washington, DC. Great video. And the other video actually is that our Cloud Foundry team, Cloud Controller API team, is working on a new CF push experience with a better push. So you actually have out-of-the-box CF push experience, so it's not stopping deployment. On Kubernetes, that looks much easier. It's built in the rolling upgrades. So also, I have a rollout histories and things like that, which is coming to Cloud Controller as well. I can SSH into container, both platforms. I can look at the logs on Cloud Foundry. I can look at the aggregated. On Cloud Foundry, I have a logigator that aggregates all the logs in a firehose that I can redirect to some of my logging facilities, like Splunk, Elk, whatever it is, PCF metrics, hopefully. On Kubernetes, that's not as you have to build that yourself. So it's not trivial, but it's not hard either. But each logs are separated for every pod. But you can tag them. You can redirect them all in the same spot, and then you get a really nice developer experience. Visibliotracing, in Cloud Foundry, Zipkin tracing is built in into the Go router. So out-of-the-box, you get that. If you're using Spring and Spring Boot, Spring Cloud Sleuth makes it very easy to instrument your services as well, add some tracing information. And it's easy because all the logs are aggregated to a single log stream. On Kubernetes, it's not as trivial. So you have a bit of work to do, but it's not hard either. So this was a nice run up through the sort of experiences. So I'd like to reflect back. And this is just scratching the surface of the developer experiences. So what do I need to know as a developer? So on the Cloud Foundry side, we build an application. On Kubernetes side, we also build an application. So we need to worry about how to build application. OK, that's given. On Cloud Foundry, Cloud Foundry builds a platform image. So it builds a container for you. On Kubernetes, your developer is responsible for building an image, container image. And pushing it to the registry, possibly do some leverage the base image strategy. So that's a very neglected. I see that all the time in the enterprises. There is a sprawl of different images. And yeah, we love Docker. Yes, great. But what is the corporate governance around that? So security team is going to have a nice conversation with you. Anyhow, on Cloud Foundry, that's managed by the BuildPack. So the BuildPack is the one that builds an image for you. They're provided by your favorite vendor. And vendors are providing the BuildPack and changes in the, for example, Java BuildPack, JDK, Java options. And there is a lot of goodies built into these BuildPacks. Fortunately, BuildPacks have graduated as an incubator project on Kubernetes as well, Cloud CNCF. So we'll see a BuildPack technology as well being brought to the Kubernetes world as well. So that would be great. On Cloud Foundry's side, we have a very rich existing marketplace that's readily available. On Kubernetes, I need to build a lot of these things. So what are some of the other things that I need to do on Kubernetes? Well, I probably need to write those manifests, right? So I need to know a lot of things before I can write one. There is a lot of different objects, and replica sets, and deployments, and services, and stateful sets. And there is a lot, a lot of components in Kubernetes that I kind of need to understand what it is, so I can write my manifest successfully. Yes, I could leverage some of the manifest writing utilities, like Helm, or there's a few other ones. I'll mention them in a moment. Also, I need to understand some of the specifics of my Kubernetes cluster. Kubernetes cluster can run on your vSphere cluster, or an OpenStack, possibly, or on public Cloud. So they are not exactly the same. Some of the networking constructs are different. Some of the storage constructs are different. I need to know these little details when I'm writing these manifests, right? And hopefully, we'll templatize some of these manifests and build Helm charts and other installations for our platform. So I talked about the BuildPacks. So they're a traditional reserve for Heroku and Cloud Foundry platforms. They're coming with the Cloud-native BuildPacks. So that's great. Definitely watch this video. Actually, I think Stephen is here at Cloud Foundry. There was a talk on BuildPacks. But do watch the Spring 1 video as well, BuildPacks anywhere. It's really great. They're really delving into why this is a good thing when you do un-patching. So it's more kind of operator. Would really, really love this when they need to upgrade their 500 apps that are using the same base image that has problems. So do you want to update 100 or so images, rebuild them? Well, use BuildPacks, right? Anyhow, so definitely increased security posture, increased developer productivity for every workload, operational efficiency, and things like that. So what are some of the specifics of the Kubernetes platform that I need to know? So we said native cloud providers are quite different. So GKE, EKS, AKS, native cloud providers, maybe PKS, is running on GCP, or Amazon, or possibly on-prem with vSphere, OpenStack. PKS is a Pivotal container service. It's Kubernetes managed by Bosch. So some of the networking constructs are different, low balancing, networking policies, storage is quite different. Luckily, we have storage classes that our Kubernetes operators can configure. And then we as developers can just use those storage classes to configure our persistent volumes and PVCs and things like that. So how do I write my manifest file for my app? Well, as I said, you need to know some of these characteristics of the cluster. You probably also need to know the architectural object constructs, right? So deployments, replica sets. There's a number of tools that help us with that. So maybe we're going to leverage some of the projects that someone else wrote. So I need a MySQL, or Kafka, or something. I might use some of the existing Helm charts, or GitCube, case on it, scaffold, metaparticle. So there's a number of tooling that help us build this and templatize our Kubernetes manifests. OK, great. We just scratched the surface, right? So OK, we have an app. But how do we expose the app, right? So definitely, we need to understand the specifics of our cluster. We need to understand the various constructs, low balancers, labels, services. I might need to choose. There is a lot of different ways that you can do things in Kubernetes, so which is the right way? Which is what are all different trade-offs, right? So cluster IP, node port, low balancer, external name. I might use some of the ingress controllers that are given to me. And then finally, we would add a service description to the manifest. So back to the point. So what do I need to know as a developer? Well, on Cloud Foundry, my responsibilities are around the app. So my artifact that I'm producing is an application. On Kubernetes, it's an image, right? So it's an image that I'm deploying to Kubernetes. That is described with manifest, deployment, and service manifest. And that's a fundamental difference, right? So the things that we need to know are much larger at the Kubernetes world. There is different ways that we can do things. And therefore, our responsibilities are bigger as well as developers, right? So where should I run my application workloads? So if you're developing apps and you worry about time to market, deliver as fast as you can, lines of businesses are breathing down your neck, right? And you've got to deliver features, features, features, right? So how do you deal with a constant change and that fast-paced delivery? Well, Cloud Foundry can help, right? So for your custom-built software on Linux and Windows, for those modern Cloud-native applications, 12-factor, 4-factor, polyglot web applications, APIs, batch jobs, Spring Boot apps, if you're writing Spring Boot apps, probably Cloud Foundry is a much better fit, OK? But that's not enough, right? So we don't write just Cloud-native apps. We don't write just those, right? So we have a bunch of other workloads that are going to run next to our Cloud Foundry. So for those type of workloads, stateful workloads, maybe you don't have a source code. Maybe a vendor packages the software and provide the image. So for that kind of software, probably Kubernetes is a better fit. Some of the short-lived apps, some of the workloads, maybe there is a Helm chart. It's easier to install it that way. Maybe for some apps that have a non-standard ports, networking, some of the legacy applications, it's easier to port them to Kubernetes first. And of course, data services. So there is Kafka, Greenplan, MongoDB. There is a lot of different data services that have readily made Kubernetes manifests. So that is it. Thank you for the questions. I did provide the references, so I'll take a few questions. And I'll see you at the pivotal boot upstairs, maybe demo some of these things. Thank you. Nevin, could you go to the previous slide? This one? If we would consider to use Kafka next to Cloud Foundry for temporary storage or whatever, then you proposed to, did I understand well that you proposed to install Kubernetes for that? Possibly, yeah. I mean, it depends. There is actually a really great talk. I'll send you the link at spring 1 on there is a Confluent, there's a company behind Kafka. So there was a really great story around how to deploy Kafka on the platform. So yeah, that's the idea. I would probably use Kafka, and I would use Kubernetes to deploy that. If you don't have another way someone else is managing your Kafka clusters, all right? OK, thank you. Thank you, Jürgen. One of the things that I'm thinking about is bridging the gap between those two, because we have customers that are deploying their Cloud Foundry on Kubernetes, and they're using the Open Service Broker API to exactly run the back-end services on the same Kubernetes cluster that the Cloud Foundry is running on. And I believe that, at the moment, the easiest way to have a single platform where you can run basically everything and have the very good developer experience on the Cloud Foundry side and the operations part on the Kubernetes side. Sorry, was that the question or statement? No, it was like, where do you see this bridging the gap happening? Yeah, well, that's exactly right. So we do need both, right? So we need data services, we need to run them somewhere. So running them side by side is perfectly fine and acceptable and desirable, right? And having Bosch under the covers is a big win because of all the operational aspect. Me as developer, I really don't care, right? I can connect it to anywhere I want. I can, through the Service Broker, that can be created for me. Would that be on a public Cloud somewhere? Or ultimately, I don't care, it's just an endpoint, right? But from operational standpoint, the operators really care about managing those, right? So if you do have those data services and you wanna manage them, Bosch really helps you patch those, right? So because they run on some VMs and Bosch is gonna help you manage the, well, sorry, that's under the covers, under the Kubernetes, right? But the Kubernetes is gonna help you manage those data services, right? So they're gonna get restarted and you have all the benefits of enterprise resource management that Kubernetes provides. Sorry, I confused it there for a moment, right? Yeah, okay, great. Any other questions? There's time for one more question. I think we have about 30 seconds left. Well, thank you, everyone, and see you at the Pivotal booth.