SAP获取企业软件。他们懂得拥有坚如磐石的技术平台、可扩展性、24×7操作、多语言等。他们也非常重视向后兼容性，因为他们明白客户希望能够升级，而无需对自定义代码进行大规模更改，甚至任何更改。

可以说是ABAP应用服务器的巨大技术成就在于它保持向后兼容。30多年前为R/2编写的ABAP代码仍有可能在S/4HANA上运行。这是相当惊人的。

这也是SAP在增强ABAP应用服务器以支持当代开发模式和技术时需要随身携带的一大包袱。由于他们增加了对诸如Internet通信框架和面向对象编程的支持，他们仍然必须支持诸如表参数、带有标题行的内部表、更改参数等。虽然我们都知道我们应该只使用当代语法开发新代码，但我们也知道我们可以使用不推荐的ABAP作为"Get"出狱免费卡"无论何时我们需要它-我们做了。

这很可能是多年来ABAP的一些不推荐的功能实际上被删除了-但我想不起一个单一的。

典型的SAP客户在他们的系统中有许多不同质量和用途的自定义代码。很多很多很多。它的大部分甚至可能从未被使用过，因为随着时间的推移，它已经被新代码所取代，但旧代码从未被删除过——以防万一。同样，客户也不愿意每五年升级一次或两次以上，这就造成了SAP版本的长尾，淘客查询，而SAP必须在几十年内保持对这些版本的支持。我知道客户仍在运行R/3 4.6B–我听说有一些是在3.1H和更早版本上运行的。

SAP现在非常清楚，手机免费建站，他们希望改变这种模式。他们现在希望您在S/4HANA系统之外构建所有自定义代码，不管是内部版本还是云版本。他们希望您抵制用自己的代码污染SAP应用程序的冲动（我说的不是他们的）。相反，他们希望您在另一个系统中构建自定义代码—他们首选的是SAP云平台—并让它调用标准API，以便和您的SAP应用程序集成。

这是允许您更轻松地升级s/4HANA系统的关键，以便您可以很快采用最新版本和相关创新在他们被释放后，他们确信不会破坏现有的代码。客户选择S/4HANA的云版本而不是本地版本也很关键——一旦那些讨厌的API可用了。

但是对于我们用来构建这些所谓"扩展"的平台的持续支持呢？换句话说，就是SAP云平台。SAP的支持计划是什么？

在我们熟悉的ABAP世界中，由于这种向后兼容的特性，对我们的自定义代码的支持几乎得到了保证。但是，当云技术可以在短时间内发生重大变化，而新技术没有义务（或兴趣）支持旧技术时，这就有点问题了。事实上，他们的主要目的是为那些旧技术提供一个替代方案。

以SAP云平台为例。从尼奥开始。大量的应用程序、扩展等已经在SAP云平台上构建并运行。最近，SAP已经开始引导开发人员使用SCP上的云铸造堆栈。我们现在正被鼓励在CF.Neo上构建我们的应用程序和扩展。我觉得你死定了。

今年在SAP TechEd上，SAP宣布他们加入了云原生计算基金会（Cloud Native Computing Foundation），该基金会是Kubernetes的控制机构，Kubernetes是一个开源项目，充当容器的协调层。而且，正如Dick Hirsch在本博客中所描述的那样，SAP已经具备了构建和运行"集装箱化"应用程序的强大能力和经验。

这是否意味着Cloud Foundry对我来说也将很快死去？

所有迹象都表明，"无服务器计算"将是我们构建和运行应用程序方式的下一个重大变化。接下来会发生什么？这是否意味着容器对我来说也会死？

当然不是。很明显，这是一个为手头的工作选择最合适的技术的案例——一如往常。这可能是云铸造，大数据分析网站，集装箱化，FaaS，或其他什么。还要记住，一种运行时技术可以在另一种运行时技术中配置。没有什么必然是相互排斥的。（Neo，我可能还是觉得你死定了。）

我可以看出，SAP现在需要重新考虑他们如何定义和定位对SCP的持续支持，以及他们如何向客户阐明这一点。

向后兼容性意味着支持当前ABAP版本也意味着支持执行所有旧的自定义代码的能力。但是，我的免费云，举例来说，SCP Neo和cloudfoundry运行时之间有一个明显的区别，就像集装箱和FaaS运行时一样。当我们着手为CF构建代码时，我们仍然希望Neo代码继续运行，基于Neo的平台继续可用。可能会持续很长一段时间。

在消费者的世界里，云提供商可能只需删除/更改/增强他们的服务，就可以消除任何负面影响。在企业界，情况并非如此，互联网大数据，引用已故的Les Hayman的话，"企业将自己的未来押在SAP上"

SAP获得了企业软件，因此我认为我们有信心他们也获得了这个问题。