Cloud Foundry ou Kyma : choisir son runtime SAP BTP
Deux runtimes, deux modèles d'exploitation différents
Cloud Foundry est le choix de la simplicité managée : on pousse des buildpacks, et la plateforme gère l'essentiel du provisioning, du scaling et de la surface opérationnelle. C'est le bon choix par défaut quand une équipe veut livrer des extensions sans prendre en charge l'exploitation Kubernetes, et cela couvre la grande majorité des scénarios d'extension side-by-side que nous construisons.
Kyma est l'offre Kubernetes managée de SAP — le bon choix quand une équipe a besoin d'un contrôle au niveau conteneur : runtimes personnalisés, sidecars, comportement réseau ou de scaling spécifique qu'un modèle basé buildpack n'expose pas. Cela demande plus d'attention opérationnelle et offre plus de contrôle en retour.
Comment nous décidons concrètement
Nous traitons rarement cela comme une décision unique et valable pour tout le paysage. La plupart des entreprises font tourner les deux — Cloud Foundry pour la majorité des extensions CAP et des flux d'intégration, Kyma pour la poignée de charges qui ont réellement besoin d'un contrôle Kubernetes-natif, comme des serveurs MCP sur mesure avec des dépendances de runtime spécifiques.
La question que nous posons d'abord n'est pas « quelle plateforme » mais « de quoi cette extension précise a-t-elle réellement besoin sur le plan opérationnel » — et nous dimensionnons la décision de runtime à cela, charge par charge, plutôt que de standardiser sur une seule pour des raisons de simplicité interne que les charges elles-mêmes ne partagent pas.