So it's three o'clock, so I think we can get started. Thanks for coming to this talk. I want to talk a little bit about

a topic which is relatively new and where Zuza has done a lot, and we'll talk a little bit about what this also means for OpenZuza. And the topic is OpenZuza and Platform as a Service. So this is this new area of tools where you run stuff on a platform

with a complex stack, and I will try to break it down into what it is, what it is for, and how we use it, and what we are doing there. So the first perspective I want to take is the one from the application developer. So if you run applications in the cloud, then you don't actually care that much about the cloud.

And the Cloud Foundry mantra is the haiku, which was written by one of the Cloud Foundry leaders, is, here's my source code, run it on the cloud for me. I don't care how. That's the idea basically. So as an application developer, I don't care how the software is run.

I just have my software. I care about this. I don't care about how it's run, but I do want to run it in a way that it is available to everybody to use. And so the application developer story is actually quite simple.

I write some source code, so I have this wonderful web application, great technology, Ruby. Then as an application developer, I have written that, tested that, it works fine. Then I just say, run one command, cf push. That's the Cloud Foundry command line, which pushes the stuff in the cloud. As a developer,

I don't care how it runs, and it runs. So there's an application then running in the cloud. The platform is taking care of everything. That's the application developer story. I don't even care about what product is running below that, how it's named, what open source project it is, but that it is as simple as possible for me to get my code into the cloud.

And one of the big advantages of that is that, as an application developer, I don't even have to talk to this guy. This is admin, who is installing machines, who is plugging cables, who is giving me the hardware

I want to run this stuff on. I don't have to talk to him for these trivial things, because I just get the stuff from the cloud, I just do my cf push, nothing else is needed. So I still better talk to him about the interesting topics, like how to optimize the overall thing, but for running my application, I don't have any delay anymore. I'm in control as a developer, and I can do whatever I want there.

Now, if I am not the application developer, but if I'm this guy, and I run infrastructure in the cloud, then things are a little bit different, of course, because I do care about what is running there, what kind of servers, where it's running, and what kind of products I'm running there.

And this is where Cloud Foundry comes in. Cloud Foundry is a huge open source project, which is providing a platform as a service platform. And here's an overview, that's kind of the architecture overview.

We've seen these programming languages, CLI and IDE integrations, that's the application developer view, where I just get the services, and the platform provides it for all languages which developers are interested in. And then it provides the necessary tooling to make this possible, like container management,

configuration, service catalog, messaging, logging, and all that. So all the interesting bits, I will go a little bit in more detail in a second. And the interesting thing then is, for operations, I care about other things, like the application developer. I care about zero downtime, for example.

I care about failure and recovery, about how to scale things. I care about security and patching, platform upgrades. This is the kind of stuff, as an operator, I care about this, as an application developer, I don't. And this is running on top of the cloud. So on the bottom you see all kind of cloud infrastructure as a service system,

and that's what Cloud Foundry targets. They have an abstraction there, so that you're actually more or less independent of that. As an operator, you can care about operations, you don't care so much about the cloud, you don't care so much about what application developers are doing. So this is the architecture overview.

Cloud Foundry is a pretty complex product. I still want to show one slide, which gives a little bit of an impression what it is and how it runs. This is the overall architecture of the core components. There is a cloud controller, that's the important part from the user's point of view. That's where the API is running.

So that's why I'm interacting with my command line client, where the CF push is actually talking to. Then we have Diego, which is the runtime component. Diego makes sure that things are running on virtual machines, which are called cells, and in these virtual machines they are running containers. So all the grey boxes here, that's the containers where the developer's application then is running,

and where the actual code is executed. There's more to that, there's logging metrics, there's tests, there's some lifecycle management. The details of that can become quite deep, but the point is that for the operator, the operator can take care of these components, run them, and provide the application developer

just with these grey boxes where applications are deployed to. And the big advantage is the operator doesn't have to talk to this guy, the software developer, the application developer. Because when, for example, a security update has to be installed,

the operator doesn't have to talk to the developers and ask them, oh, you have this container running there which contains an outdated versions of the SSL or whatever. The operator can actually just update the platform, so that all the applications are using an updated stack.

That's one of the main features, what Cloud Foundry provides there, that the platform takes care of the middleware, the stack, the operating system below the application, and it is able to restage applications in a way that without service interruption, I can actually update the whole infrastructure

without talking to the developer, without having to rely on others to do that. So this is, again, a great feature for the operator. Still, it probably is good if operators and developers are talking to each other that the overall system is running in a way which is nice, performant, and improves over time.

So the third perspective I want to talk about is the community perspective, the contributor perspective. So if you contribute to Cloud Foundry, that's a little bit special on one hand. On the other hand, it's also an open source project.

The Cloud Foundry Foundation, which is the governance body of the Cloud Foundry community, is a foundation managed by the Linux Foundation, so one of these typical big foundations. It has a lot of members, and you see a number of really big names there. So there is Cisco, there's Dell, IBM, Pivotal, SAP, Zuzu, VMware.

That's the platinum members, which are also taking most of the development load. But what's also interesting is that there are actually a number of huge users of Cloud Foundry in the community as well, so names like Allianz, or Allstate, or Ford, or whatever. So it's a pretty big group where there's a lot of power,

and they have a very dedicated open model. It's open source, but it's dominated by corporate contributions. And this is reflected in the structure of the project.

One thing which is interesting is Cloud Foundry is a microservices architecture. So it contains of all these services, so all the little boxes you saw. These are services which have APIs which talk to each other, and this is reflected in the project organization. So microservices is not only a technical architecture, it's also an architecture for the project.

And this is the list of the official Cloud Foundry projects with the people who are managing. It's separated in three different areas. The runtime, which is most of the platform core, then Bosch, which is the tool to maintain the lifecycle of virtual machines, and extensions, so that stuff which is on top of that.

And all these groups, they work as independent teams. Most of them are actually two development models, as a lot of teams are working with people from Pivotal. They more or less have defined the development model there, and this is actually one of the things which makes Cloud Foundry special,

that a lot of these people are doing extreme programming. So these are co-located teams which are doing pair programming all day. So you see, and you can decipher my wonderful painting here,

two developers using one computer with two monitors, but working on one machine, doing actual pair programming, how it's described by the extreme programming years ago. And this is how the majority of developers in the Cloud Foundry community are working. And this is a model which is quite powerful, but it's also coming with a few things which are pretty specific for Cloud Foundry.

It's harder to get in there if you have to pair for the whole day, of course. On the other hand, it's very effective. So I could talk about this for probably two hours, because there's a lot to know about that. It's an exciting topic, but I want to get to another point,

and that is, where's OpenSUSE in all this? So, as I said, SUSE is a platinum member of the foundation. We are working on Cloud Foundry. We are working with SAP there. Upstream, we have a number of other upstream developers. We will create a product based on Cloud Foundry. But OpenSUSE actually is not there.

And in this space, the clouds are pretty dark, because in Cloud Foundry, as in some other cloud projects, OpenSUSE is just not present. It's just all Ubuntu there. And the thing is that the operating system is not the most important part of these systems.

It's necessary for the implementation, but the focus, as I said at the beginning, is on providing the application developers an experience that they don't care about how things are run. That's, of course, not our perspective as operating system people, but that's what the selling point of the product and the project is.

So, for OpenSUSE, it's actually quite hard there, because Ubuntu is just a normal choice, because everybody is using that. They have a lot more users than everybody else, and for developers, it's the natural choice. It's not the most important choice, so they take that, and OpenSUSE is not there. So, we have to do something about that. And one thing we are doing, we are building an OpenSUSE stem cell.

So, to explain what a stem cell is, that's a specific term from the Bosch universe. So, Bosch is the tool which is used to deploy the virtual machines and manage the virtual machines on which Cloud Foundry are running. That's a default tool used by the upstream community, and it comes with a Bosch director, which is the API endpoint

and does all the control. There's an agent running on the VMs, which is talking to Bosch. There's an abstraction of the clouds, so the cloud provider interface, so that it can run on all kinds of different infrastructures and service systems, and Bosch is taking care of that. And when you deploy something, you take a release.

That's a specific Bosch term for kind of a software package. You do a deployment where you say where it's deployed and how, and you add a stem cell, which is the image for the operating system. So, on which operating system you deploy that. Yeah, this is where we come into play again

and where we created an OpenSUSE stem cell, which can be used to deploy these VMs. And just to illustrate that, I didn't have the time to really do a demo here, but a deployment manifest looks like this. It's a YAML file where it says, okay, example,

deploy a Git server to some endpoint from some repo, add some data there about how it's deployed, and then it defines a stem cell, which is the operating system, and there, now, with what we have developed, we can write OpenSUSE leap, and Bosch will take the stem cell, which is just the operating system image,

run that on a virtual machine, put the software on top of that for this example, Git, run it there, and make sure that it runs, and if you want to scale it, you can tell Bosch, okay, start two more instances, and it will just do it. So, that's the base. So, in some sense, the stem cell is just a special form of the distribution.

It's based on OpenSUSE. It's using the same packages, adding a little bit of extra tooling like the agent we saw before, which is necessary in the virtual machines so that Bosch can talk to them. But in general, it's just a special variant of the OpenSUSE-based system.

Yeah, we built that. That's the upstream built pipeline, extended by what we are doing for OpenSUSE, so we can actually run that and build the stem cell in the same way as it's built for the other operating systems, which are supported there, mainly Ubuntu, and the result we publish then and make available for others to use.

So, Bosch.io is the homepage for Bosch. That's where the official stem cells are and where the documentation for that is. We have some code here for the Bosch Linux stem cell builder, which is the tool which builds the stem cells

where we have added the OpenSUSE support, and we will put the stem cells itself on download opensource.org, so you can download them and can use them in Bosch, play around with that if you want, and use them from there. It's not there yet, so if a hero is somewhere,

send him my way so we can make the final upload happen, and that should be it, and then OpenSUSE is available as a stem cell for use by Bosch, running Cloud Foundry or other applications on top of that. Yeah, and that's basically what I wanted to tell you. That's a rough overview.

It was a short talk, but if you have questions, I'm happy to answer them. So what are your questions? So is Cloud Foundry architecture agnostic,

or would, for instance, if I wanted to... You want to run it on ARM, right? On ARM or anything else, yeah. Yeah, so the architecture is not specific to any hardware platform,

so there are a lot of components involved which have to run on the different hardware platforms. There's a lot of software which has to be compiled on that, but all this build system and all that, that's part of the architecture, so I don't think it's ported to ARM or any other specific hardware platforms,

but it's possible to run it there. It's mostly running in the cloud, so the public cloud or VMware instances, I think are the most common use cases for Cloud Foundry, so whatever hardware is used there is the basic target, and then with individual machines, of course,

the hardware is less relevant, but still, of course, you can run it on other platforms. So does that mean then that the stem cells are architecture agnostic, or are they built for, they're obviously built for a specific architecture? They are built for a specific hardware architecture. They are also built for the specific cloud platform,

so they contain a little bit of, that's a small layer of specific instrumentation for AWS or OpenStack or whatever you need, but in the end, it's all standard open source software which is used there, so porting that to another platform, there's no principal problem there. It's just a matter of somebody has to do it, and there has to be a demand to do it.

Okay, thanks. Is it built in the build service? No. Yeah, the problem is when we had the vagrant images on

downloaded from Zuzock, people complained, hey, this is now unsigned code, nobody could verify it, and that's why we said it should be built in the build service. Yeah. So everything I talked about, that's more or less upstream open source development, so this is not our product yet, so we are working on the product.

I was just talking about the stem cell thingy. So for the stem cell as well, we are using the upstream build system basically, so our goal is to make it part of what upstream is doing, and they are not using the build service, so at the moment, we are more or less constrained to the system which is already there.

So we are looking into building more of that in the build service. We are working on stuff like supporting Docker builds in the build service in a better way. So I hope we can actually bring a lot of that to the build service, but at the moment, we are just using the upstream tooling. And I see all the problems this has, and we are trying to solve them.

Yeah, so getting it working in the build service or just like having a post-build hook that unpacks your RPM with the image inside might be the best way to get it. Also, not on Zuzock. That's a good point, yeah. Other questions?

You're all experts on Cloud Foundry now. All questions answered? Yeah, so if you have more questions, feel free to reach out to me. There's an introduction. I'll talk more about that. If you have specific questions, talk to me.

I'm happy to answer them. It's a pretty new, exciting, interesting project. There's a lot to learn there and also quite a number of interesting challenges like Darik's pointed out. So thank you. Thank you.