Future of Cloud Foundry With Kubernetes – Julian Fischer in Interview

The latest interview between anynines CEO Julian Fischer and TFiR, which took place just before KubeCon & CloudNativeCon EU 2021, covered the future of Cloud Foundry with Kubernetes.

In detail, the following questions were discussed during the interview:

• What discussions can be heard when it comes to Cloud Foundry and Kubernetes?
• What kind of challenges do companies face when they move from Cloud Foundry environments to CF for Kubernetes?
• What are the pitfalls when migrating data services, and what are the right ways to migrate them?
• What are the limitations of CF push when looking at Kubernetes?
• How is Cloud Foundry or CF for Kubernetes trying to address that?
• How is a9s Platform evolving in sync with the changes that can be seen within the ecosystem and the market itself?

Read the full interview here. See the interview video at the end of the article.

Swapnil Bhartiya: Today we are going to talk about the future of Cloud Foundry on Kubernetes. What discussions are you hearing when it comes to Cloud Foundry and Kubernetes?

Julian Fischer: There have been two major projects pushing Cloud Foundry into the direction of Kubernetes, which was KubeCF and CF for Kubernetes.

I think KubeCF has become less popular with CF for Kubernetes being the, let’s say, candidate to move forward. That would have been my assessment in case you asked me a few months back. But now it seems to be that the impact of Kubernetes on Cloud Foundry is more substantial.

The discussions are heading in a new direction. In particular, the idea is that if there are components necessary to offer an application developer experience on Kubernetes, that evolve quickly and have wide adoption in the Kubernetes ecosystem.
So we’re talking about functionality such as service meshes, and ingresses, for example. Then the question is whether there’s value if Cloud Foundry, basically also has the same functionality.

It appears that the direction Cloud Foundry is moving to is to adapt more of the Kubernetes components that have conquered certain niches in the Kubernetes ecosystem, and therefore adapt those Kubernetes native technologies, more.

Reducing the amount of code that Cloud Foundry itself has to govern. And I think that will lead to two effects.

First, the Cloud Foundry experience will become closer to a native Kubernetes experience in the sense that, for example, more Kubernetes idioms will also be supported by Cloud Foundry.
And second, that Cloud Foundry itself becomes leaner and I think also infrastructure overhead will be reduced a bit.

At the same time, it’s also the case that Kubernetes and Cloud Foundry do have this special relationship, so to say. I think where Cloud Foundry will remain strong is in the overall experience of having the famous CF push experience. The CF push experience will be preserved.

I also think that the idea of having Cloud Foundry for Kubernetes clusters, where there are a lot of applications that have to be maintained in a production-grade manner, that also will be a strong focus in Cloud Foundry.

In contrast to other projects, where there’s more focus on getting it started, and have that pleasant experience Cloud Foundry was always a bit more heavyweight, but at the same time robust and suitable for large-scale applications. So I think that will be preserved during the migration towards Kubernetes.

Swapnil Bhartiya: Can you talk about what kind of challenges that you have seen companies do face when they do move from Cloud Foundry environments to CF for Kubernetes?

Julian Fischer: Well, honestly, I think most of the Cloud Foundry users, I’m talking about companies who have invested into Cloud Foundry a while ago, let’s say a few years back. Many of these companies have not already migrated towards a Kubernetes-based stack. Especially if their environments are large, and there are many hundreds or 1000s of applications. I don’t think it’s the time yet to do and perform that migration. I think where most of the organizations are is in observing what happens to Cloud Foundry, how it is integrated with Kubernetes, and what the implications are for migration.

I can basically summarize what are the discussions about migration.
As long as there is a Cloud Foundry interface, migrating Cloud Foundry workloads from one Cloud Foundry to another Cloud Foundry instance is something that is well understood.

We as a company have done that several times when customers move from a commercial Cloud Foundry offering to our a9s Platform.

I think that’s a problem that’s well understood. And I think the migration path from Cloud Foundry towards anything that will be more integrated with Kubernetes will also support such a path. There might be more restrictions than seen in previous changes to Cloud Foundry. For example, when moving from DEA to Diego, that migration that’s upcoming, might be a bit more impactful because moving to Kubernetes technologies may lead to some restrictions.

The teams working on Cloud Foundry, they’ll have to make a trade-off decision between the effort to implement the compatibility and at the same time be open to new changes and adapt a Kubernetes technology.

I think, for most users, migrations will be fine on the application side. Applications running on Cloud Foundry, you can push them to a Kubernetes. And migration, best practices that are already well understood, and to some degree, also documented, they can be applied.

However, Cloud Foundry always has drawn a line in the sand and divided application platforms into the application runtime and anything that provides state. In the original Twelve-Factor Manifest, they were called backing services. Another term would be data services, including databases, message queues, and so on.

So what about them? I don’t think that Cloud Foundry will provide a migration path for anything like that, because it’s basically not in the scope of Cloud Foundry and never has been. Well, I’d say, most of the time, it has not been in the focus of Cloud Foundry. So I think that’s where a lot of the challenges will be. How do you migrate your databases along with your applications?

Swapnil Bhartiya: So you did mention that what all you can or cannot easily migrate. Talk about the pitfalls when migrating data services, and what are the right ways to migrate them?

Julian Fischer: Well, the challenges of migrating data service instances from one Cloud Foundry to another really depend on the circumstances and the context.

So for example, it’s different when all you want to exchange is the Cloud Foundry runtime, let’s say you want to reduce the BOSH-based environment in favor of the Kubernetes-based environment.

If your data services still sit somewhere, and you can still refer to them, well, then you may even have no urge to migrate your data service instances.

I give you an example. Our data service product called a9s Data Services is a set of different service brokers with lifecycle automation. They basically deploy virtual machines triggered by BOSH. Our service broker talks to BOSH and BOSH creates virtual machines.

We recommended all our a9s Platform customers to have the data service installation in an isolated network segment. And not to use, for example, if possible, our PCF tiles, but instead, use BOSH to deploy our automation and also keep it in a separate network segment.

Because this way, you can basically just add another Cloud Foundry instance and refer to the same service brokers and therefore migrate service instances from one Cloud Foundry instance to another. I mean, still, there’s some work to be done, for example, integrating or importing metadata, although service instances. But actually, you will have the service instance available.

Now, it’s a different scenario, when the goal is to really get rid of virtual machines altogether and move to a pure Kubernetes native Container based platform. For this, we’re going to offer suitable solutions starting with PostgreSQL.

We’re going to add operators under the same license as the a9s Data Services. Customers will be able to create service instances natively on Kubernetes, as well.

The challenge is a bit different because then you have to migrate the service instances, you basically have to do either replication-based or a backup restore-based migration path.
With our data services, the advantage will be that backup and restore interfaces will be compatible, so that you can basically bulk export and bulk import service instances.

With the absence of such automation that will span multiple data services, the problem may be more complex. Because for each data service, you’ll have to create your own migration path to get from virtual machines into a container-based solution. So if you have 10 different products doing data service automation, you’ll have to talk to 10 different vendors or find 10 different migration paths somewhere else. And that’s, I think, where a lot of work will cause a lot of effort.

Swapnil Bhartiya: CI/CD is becoming a very critical piece where you’re just pushing a lot of things for security perspectives. What are the limitations of CF push when you’re looking at Kubernetes and how is Cloud Foundry or CF for Kubernetes trying to address that?

Julian Fischer: I think the trend is that whatever is an entity in Cloud Foundry today, the attempt will be to reflect this entity in Kubernetes with a Kubernetes idiomatic format.

For example, anything that’s an API object in Cloud Foundry may become a custom resource in Kubernetes. I think there will be a convergence between Cloud Foundry and Kubernetes. The difference or the gap between the two technologies will become less and less.

The user experience is still one of the strong suits of Cloud Foundry. However, other projects from the Kubernetes ecosystem such as for example, kpack and the likes, seem to be widely adopted and may become the future standard.

The CF user experience will be preserved. But one of the goals will be to make it more declarative because that’s basically a leading paradigm in the Kubernetes ecosystem.

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Accept YouTube Content

The challenge is not only to make those customers happy, who are using Cloud Foundry today.

We have to separate the discussion a bit between those who are already invested in Cloud Foundry and Cloud Foundry as a technology that has to survive in the tech ecosystem, in the sense that it needs to drive adoption.

I think the Cloud Foundry Foundation sees the challenge that they have to position Cloud Foundry in a way that new engineers from, let’s say, the Kubernetes ecosystem will also look into Cloud Foundry.
For those users, the requirements of the user experience will have to be more idiomatic towards Kubernetes than the more imperative approach that came along with the CF command-line utility.
I think that will be exciting to see a shift over time towards that more Kubernetes-like declarative approach.

Swapnil Bhartiya: We have this discussion earlier also that the whole landscape is evolving and a9s Platform is also evolving. Talk about how the platform is evolving, kind of in sync with the changes that you see within the ecosystem, and the market itself.

Julian Fischer: A Platform owner has to modify and has to upgrade has to change and make the platform evolve, and so do we.

One of the thoughts that Cloud Foundry came along with was, it can be the dominant platform within an organization. So the one and only thing will be Cloud Foundry.

If you put all your applications on Cloud Foundry, then the Cloud Foundry marketplace, which is a very, very enriching feature for a platform, offering standardized data services for easy consumption.

The marketplace idea also was a little bit influenced by the fact that Cloud Foundry tried to be the dominant platform.
Now, I think it’s clear that Cloud Foundry is not necessarily in all organizations the dominant platform because some local development teams will require more flexibility, where Kubernetes has advantages.

If you take that into consideration, then you’ll have to break up a platform into smaller modules. And that’s what we do with the a9s Platform as well.
A few years back, if you asked us to build you an application developer platform, we provide you with the Cloud Foundry data service automation, and all the monitoring tools and CI/CD automation, it’s necessary to make that efficient.

Today, if we talk to clients, we’ll ask them to tell us about their requirements, what are the different groups of developers, and what are their particular requirements. Then we’ll find out what kind of platform stack is right for them.

If they, for example, have a lot of Twelve-Factor compliant applications and they want to do an effortless operation, then Cloud Foundry is suitable for them. Especially if they want to have easy access to data services, you know, consuming data services based on well-tested service plans rather than having to fiddle around with objects specs that are more complicated.

However, if there are developers who have very specific needs, and also demand for components from the Kubernetes ecosystem, then providing them with a standardized Cloud Foundry wouldn’t be a good choice.

Making all the modules of the anynines platform optional is the first step where you can take a Cloud Foundry, you can take an on-demand Kubernetes, you can take the a9s Data Services on BOSH or on Kubernetes. And you can arbitrarily combine these modules.

The next step will be that we also think about Kubernetes modules, we’ll call them Kubernetes extensions. That will include service meshes, popular frameworks, workflow managers, CI/CD tooling, Cloud Foundry itself, things like Knative.
You can then take those Kubernetes extensions, which will be automated throughout the lifecycle, similar to what we do with data service today.
And then you can form your own templates for Kubernetes stack, let’s say a Knative stack for one developer group and a Cloud Foundry stack for another.

You’d be able to have those stack templates and instantiate clusters, easily. And you will also be able to guide them through the lifecycle including things like monitoring, Backup and Restore. So the ecosystem is more modulized and Kubernetes. So will be the a9s Platform.