To foster more application development in the DevOps era, SAP at the Mobile World Congress 2018 conference announced it is adding a consumption-based pricing option to its SAP Cloud Platform environment.
Based mainly on the Cloud Foundry platform-as-a-service (PaaS) overseen by the Cloud Foundry Foundation, the SAP Cloud Platform provides a way for SAP customers to build custom applications that can be more easily integrated with SAP applications delivered as a cloud service using a standard set of application programming interfaces (APIs). The basic idea is to enable organizations to innovate in a way that doesn’t impact their applications every time SAP, for example, updates the SAP S/4 HANA application portfolio, said Dan Lahl, vice president of product marketing at SAP.
SAP Cloud Platform currently is made available via a set of services an organization subscribes to for a defined amount of time. Under the consumption approach, an organization buys credits that can be applied within a specific amount of time. That makes it more economical for organizations to start multiple custom projects without having to know precisely upfront what services will be employed on the SAP Cloud Platform, Lahl said.
In effect, SAP is creating a licensing model more in keeping with how developers consume services in the age of DevOps, he noted.
SAP also announced an enhanced SAP Cloud Platform SDK for iOS, providing tighter integration with the Apple Xcode integrated development environment (IDE) and additional analytics controls that can be embedded within an iOS application. SAP has also made it easier to consume SAP Leonardo services for building internet of things (IoT) applications using APIs that can be accessed via the SAP API Business Hub.
Lahl said in the coming months SAP also will share with customers best DevOps practices it follows to develop and maintain cloud applications. SAP is now seeing traditional IT organizations now starting to more aggressively adopt DevOps processes, he said, primarily because DevOps processes enable IT organizations to show a proof-of-concept (PoC) to line of business executives much faster. That, in turn, also serves to condense the feedback loop between business units and the internal IT team.
Those projects now span multiple classes of runtimes, including SAP ABAP, Java and Docker containers—all three of which are being employed to create microservices. The challenge many organizations now face is determining when to build a microservice versus invoking a function via an API that already exists in an ERP application. Application developers don’t often have visibility into an existing function, which is why they run into resistance from business executives whenever they attempt to reinvent a wheel that already exists, Lahl said. The challengeis making it easier to discover the APIs that expose functions within an existing monolithic application, especially when it doesn’t make sense to reconstruct a general ledger function as a microservice.
Whatever the ultimate approach employed, the one thing that is clear is that costs associated with either building or consuming a service keep coming down in the age of DevOps.