Cloud Foundry: should be part of Eurostack

On Cloud Foundry

The Lidl cloud, StackIT, is getting a lot of attention these days. This is for good reason, as Europe realises it needs European based cloud providers, it is clear that there is not much that can seriously compete with the well known Hyperscalers. As Bert Hubert explained quite well in his analogy of selling wood in stead of furniture, there are enough large scale and competent hosters, but they lack some options. The most advanced option is often Kubernetes. StackIT however is getting closer to the Hyperscalers portfolio of offerings and there is a particular interesting offering: Cloud Foundry

Cloud Foundry, a well establised open source project, has been around for quite some time. It was even released a few years as open source before Kubernetes was. It is an enterprise Platform As A Service (PaaS) stack that from the beginning was focused on the Developer experience. With it you can host your own PaaS-platform. It provides DevOps teams a platform that handles a lot of the ‘plumbing’ of hosting your application. Simply push your code to the platform and the platform takes care of most of the requirements such as building container images, running containers at scale, certificates and DNS for hosting and a lot more. Cloud Foundry is governed by the Cloud Foundry Foundation directed and funded by the Linux Foundation. The closes comparison that can made is with Heroku.

Aside from these public offerings, it is a well established platform and used by many large organisations, both in the USA and Europe.

What sets Cloud Foundry apart from Kubernetes

Without a doubt Kubernetes is much more well known. In fact it is quite common that even seasoned IT people active in the Cloud Native world have not heard of Cloud Foundry. This probably has to do with that the appeal of Cloud Foundry is especially for larger organisations, or when you found a hoster that delivers the Paas platform.

What Cloud Foundry offers the developers

From the developers point of view Cloud Foundry does a lot for you:

• It will build container images for you. You do not need to learn how create container images. It does this by using build packs If you as an example want to create a Java based container, send the Java code to platform. You can specify that it’s a Java application, although if nothing is specified the platform will most likely autodect this. The platform will then build the entire container image. That includes including a Tomcat server, downloading all the libraries etc.
• You don’t need to worry about things like https certifcates. The platform handles this for you. So need to know how to add them, but maybe even more importantly, no need to timely renew them. That’s all done for you
• The same applies to DNS. You simply tell it what DNS name you want and is handled. There is though an important caveat, the entries will usually be part of one of the configured domains. In your organisation that is often even desired.
• Scaling is matter of choosing how you want to scale. You can tell it to autoscale, you can also simply tell it how many containers you want running and Cloud Foundry will spin up those.
• It is self healing. This really works, ones your application runs, Cloud Foundry will keep it running. If a container fails, it will simply be replaced by a new instance. That means that DevOps teams, as per the DevOps definition responsible for production, usually don’t ever have to deal with outages. If an outage happens, it is usually a larger issue to be handled by the team maintaing the platform. On-call turns into free money.

A DevOps team is responsible for both developing applications as well as running them in production. However, most of them want to focus on the development part of the application itself and be least bothered by the deployment itself. The more the platform does for them, the better the developer experience.

What Cloud Foundry offers organisations

Aside from a better developer experience with the developers having to worry less about the ‘plumbing’ of the deployments, there are more advantages especially for organisations.

Central visibility and control of what is running. As the core of the container images is build by the platform and not by the developers, the stack is controlled and visible. What this gives you: -The platform team can easily create dashboards showing the basic stack of the containers: that includes versions of i.e. the Java version, webservers etc. Basically all the parts of a container excluding the code added by the DevOps teams -They can even forcibly ‘restage’ images. That means the platform will rebuild the containers with the latest stack. Although that does not give you control over the code created by the DevOps teams, it does mean you can update the underlying stack.

• Segmention of the applications handled by the platform. The platform can control what applications can connect to. That reduces the blast radius of an issue with a misbehaving or even malware infested application

Simply put, if a container was build i.e. as a Java container, you can:

• be sure that no other language code is running it as that would be discarded at build time.
• know exactly the Java version running in the container.
• know exactly what Tomcat server is running in it
• even forcibly rebuild it with the latest buildpack in case of DevOps teams lagging behind or reported vulnerabilities
• even add extra java startup parameters.

So Cloud Foundry can play an important part in your organisation to achieve compliance, get control of keeping the hosting stack up to date and play important part in staying secure.

Furthermore, as Cloud Foundry can run on-premises, on public cloud offerings, it provides organisations with easy portability of the applications. This will be elaborated further on.

What it can’t do and what gap Kubernetes can fill

Whilst it offers many advantages, there are limitations. It is known and by design an ‘opiniated’ platform. If works great if you application can make use of it, but there are certainly cases where it is not the right fit:

• it is strictly stateless. That means that no (persistent) data can live in the containers.
• as a result it is highly dependent on data services delivered as a service as well. So if you need a database type that is not also part of the platforms offerings, it is not the right fit
• lot’s of software, both Cots and Open Source, these days comes with Kubernetes Helm charts (deployments) delivered. Whilst in many cases you could create your own deployment in Cloud Foundry, it makes more sense to just use the supplied deployment. Both in work to maintain the deployment and support of the builders of the software

As a result in many situations Cloud Foundry and Kubernetes are complimentary.

Visualised

fig. 1: visualisation of what DevOps teams are responsible for and what a platform team is responsible for.

In the picture above, green represents what a DevOps teams has to deal with in green and in white the components that are handled by the platform.

Bottomline

The bottomline here is that Cloud Foundry is ‘higher up in the stack’. As a result, your DevOps teams have a better developer experience. And organisations get better control over the applications and can have more centralised control of the security and compliance of the applications.

How it works: BOSH, the Market Place and the Cloud Provider interface

Fundamental to understand the stack is the role of BOSH, the Marketplace and the Cloud Provider Interface (CPI)

The Marketplace

The containers from Cloud Foundry are stateless. This means that they may not contain any data. Aside from that is good practice, this is also necessary since the platform will at times replace containers. Since there are very few applications that are without data, the plaform needs to provide a solution. This is the Marketplace. This is where DevOps teams can consume several ‘As A Service’ services such as:

• Databases As A Service (DBaaS), usually MySQL and/or PostgreSQL
• Redis
• RabbitMQ
• Object storage (s3 compatible)

For the DevOps teams this means that the same interface they use for Cloud Foundry can be used to consume these services. To be precise it as simple as the command: cf creat-service to have the platform spin up any of these services. These services can be fully a part of the platform and hosted in the same stack. They can also be completely outside of the platform and i.e. be delivered by another team as long as they are served ‘As A Service’ and can be consumed via an API. In that case a broker in the Marketplace will handle the integration.

BOSH

A fundamental part of supplying is BOSH. This is also fully open source software. BOSH is the orchestrator. This means it will provide Cloud Foundry and its Marketplace. BOSH will automatically spin up all the components. This means it will create virtual machines, virtual storage, handle networking etc. The creation of virtual machines (VM’s) is required as they are needed to host the containers. BOSH does this fully according to the ‘Pets vs Cattle’ paradigm in that in stead of patching VM’s it will on every update simply replace them. In fact it may even do this without the need for an update. The interesting part of this is that BOSH can also be used to provide BOSH managed servers. So if you want to provide VM’s in your, you can use BOSH for it and get the additional benefits that the base image and stack in a VM is handled by the platform. This effectively allows you to apply the cattle approach to VM’s as well. Important though is that BOSH requires an infrastructure on which to create the components. Out of the box supported are on-premises solutions such as Open Stack and the Broadcom/VMware stack. Also supported are all the major hyperscalers such as AWS, Azure and Google’s cloud. You don’t have to handle the differences yourself. The translation is handled by the Cloud Provider Interface (CPI) in BOSH.

The Cloud Provider Interface (CPI)

The CPI is a part of BOSH that can be seen as sort of a driver. If you use VMware’s virtualisation BOSH will, if it needs to create a VM, create a vsphere instances. If it runs on AWS it will create an EC2. That means you don’t need to know the intricacies of those platforms. It is handled for you. But more over, it provides portability. Changing the underlying infrastructure will not require any changes for the applications running on the platform. You can also run hybrid solutions combining an on-premises platform with one at a public cloud. Applications can be moved without changes. Apparently it is not that hard to create a CPI for not yet supported platforms. So if you have the skills if your infrastructure is not in the list, such as Proxmox or Apache Cloudstack, you can add it. And obviously it would be nice if you provide it upstream to the open source project so others can use it as well.

So what it offers

So what this stack will offer

• portability
• independence or an exit strategy from your cloud or IaaS provider
• a better way to offer Virtual Machines (as cattle)

Viablity

When assesing a key part of your IT infrastructure it makes sense to check the viability. That means looking into who is behind the development as well how invested other organisations are into it or to put it differently: who else is using it?

Who is behind Cloud Foundry?

Open Source software like this is usually not created and maintained by volunteers/hobbyist despite the romantic view some have on Open Source. As stated earlier, Cloud Foundry is governed by the Cloud Foundry Foundation directed and funded by the Linux Foundation. You will see that there are multiple organisations that play an active role. If you the foundations membership page you get a good impression.

One of the key players is VMware. VMware provides Cloud Foundry via its Tanzu product line and has a long history with it.
VMware is interesting if you want to use Cloud Foundry and want to have support and some of their additional tooling. They will provide you with their version and help you. Another major player is SAP where Cloud Foundry is a core component of its Business Technology Platform.

Then there several other organisations contributing to Cloud Foundry. Some since they use it themselves. Others because they offer Cloud Foundry professional services, or as in the case of StackIt they are a service provider. So there is a strong commercial backing by multiple companies.

Who else is using it?

It also matters to see who else is using it. It is well known that both in Europe it is widely used, notably in the financial and automotive sector. There are many more organisations relying on it. So it is good thing to know the demand is strong, which means it definately viable.

Is Cloud Foundry for you?

There are several ways to start with Cloud Foundry:

• choose a public offering from i.e. StackIt
• or self host:
  • get support from any of supporting companies in setting it up
  • or rely on the documentation and learn how to run it yourself If you self regardless if you get support or become self reliant, you need a team to set up and maintain a Cloud Foundry platform. Experience shows that a small team of circa five engineers can run a Cloud Foundry platform, regardless of how many apps are running on it. It depends more on how many services you run in the Marketplace and how much assistance they provide than how many apps are running on the platform. This means that scale matters. If you have just a couple of apps to run, self-hosting and outfitting a platform team is not cost effective. In that case often setting up a Kubernetes platform can be better for you or opting for a public offering.

Another reason to opt for Kubernetes if you need Kubernetes anyway as your apps are not the right fit for the reasons mentioned beofre and your staff is already well versed in maintaining Kubernetes deployments.

So if you have many apps with many teams. Cloud Foundry will be give you many benefits, saves your DevOps teams lots of work, help you standardise deployments and be an important part in your security posture. But if not self hosting Cloud Foundry may not be the right fit.

Why should this be part of Euro Stack

In my not so humble opinion Cloud Foundry and with it BOSH should be part of the EuroStack. EuroStack is an initiative to decrease the dependence on non-EU technology. By defintion Open Source software qualifies as you cannot legally be stopped from using and further developing Open Source software. Not all Open Source software needs to be part of the stack. What makes Cloud Foundry a candidate is that it:

• provides a PaaS solution, which is missing from most EU based cloud offerings
• already has a strong European footprint with many large companies in the EU using it
• already adopted by a leading European public cloud: StackIt
• very mature and proven technology
• has a strong professional Open Source community maintaining

Cloud Foundry on its own can not make European cloud offerings on par with the Hyper Scalers, but it can be a vital part in making them more than just Infrastructure as a Service. It can also help your applications become less tied in to specific vendors and allow you to easily move away to different Cloud or hosting providers.

---

No AI was hurt or used in the creation of this blog post. ProfOps can help you if you have more questions and can be reached via info@profops.com