Let's assume that you've spent the past few years working on the good old SAP backend, and suddenly, those darn clouds, cloud-native, and the SAP Business Technology Platform (BTP) came into play. Let's even say that you once dabbled in BTP Neo, witnessed the emergence of the new and improved cloud-named Cloud Foundry on the horizon. However, the warm and cozy server depths of ABAP didn't release their grip on you to explore the vast skies.

Fast forward to the present, and what do we have? The world of cloud applications largely dominated by containers and Kubernetes. It's literally everywhere, you might have never used it or seen it, but you know it's there, and soon your fridge will be running on a k8s cluster too.

You find yourself back in BTP, where there's almost no escape, with clean core, extensions, integrations - Neo is already passé, but you have three environments - ABAP, Kyma (yes, it has Kubernetes!), and Cloud Foundry.

You wonder why Cloud Something is still here when there's Kubernetes in Kyma.

Why bother learning it at all? They'll probably phase it out soon.

Well, no. SAP TechEd 2023 confirmed (unfortunately, I don't remember which video) that Cloud Foundry stays in BTP. For SAP, it holds value as a platform for cloud applications and services, so investing in learning it won't be in vain. Putting aside various ideas and speculations about the decision, for a developer stepping into BTP, the important thing is to sit down and learn it. You can superficially grasp it to get things running through established paths (tutorials, SAP-specific types of applications, and related services), but for a complete understanding, it's better to delve deeper into the "core" platform. And here lies a certain problem.

Cloud Foundry in BTP has undergone tuning. If you go through the documentation on cloudfoundry.org and then jump into SAP tutorials on using standard things like Fiori + WorkZone (formerly launchpad), CAP, etc., you'll quickly realize that the promised 'from code to running apps as easy as a single cf push command' doesn't quite apply in the SAP version. You enter into rather intricate concepts of multi-target applications and mta.yaml files with magical, not particularly well-documented parameters. To make Service A work with Service B, paste this here because it was described on Blog X, not so much in the documentation. At the end of development, it's just cf deploy, but you can get a bit lost on the way. It was supposed to be cool and enjoyable, and here come some app routers, XSUAA, and other devilries...

What to do? How to get a handle on it? Well, it can't be rushed. You have to go through your own learning curve to start grasping certain things. Unfortunately, the entry threshold from a typical on-premises SAP backend to BTP CF seems high to me. And in all of this, basic knowledge about "base" Cloud Foundry platform as such is useful.

Returning to Kubernetes - from the first paragraphs, you might think I'm picking on it and don't like it. No, it is just its benefits are not for free. And it's not just about cluster costs but rather the level of complexity and the entry threshold. In the world of corporate applications, those with a narrow scope and low demand, based on BTP and developed mostly in one team - I would question whether such a level of complexity is necessary. The worst-case scenario is teams where 'hype/CV driven development' takes precedence over a sober assessment that CF applications + standard BTP services may be good enough for our solution. But that's another big topic for separate considerations (you can find a small discussion on this topic here).

If we're talking about CF and Kubernetes and want to know how these two technologies relate to each other, tutorials on cloudfoundry.org briefly describe it.

In summary - whether you like it or not - at the moment, Cloud Foundry is here to stay in BTP. Learning it through purely SAP tutorials may give you a taste of the SAP approach to this platform, but it's worth the effort to understand its core fundamentals.