Alternative models for SAP Cloud Platform trial

SAP is ending the SAP Cloud Platform Neo (SCP Neo) Trial and for everyone to learn and try out SCP services, the SCP Cloud Foundry (SCP CF) Trial is the only offering left. I wrote down my thoughts on this and why I think that the free trial approach is not up-to-date any longer and why the big cloud players perform better with their free tier approach. With a free tier you start for free and when your app grows and you reach certain usage limits, your bill starts to grow too. Compared to the SCP CF trial it’s not free (as in beer), it’s free as in feel free to pay.

Personally, I believe that this approach is a better approach. At the end of my blog I mentioned an alternative: “A possible solution could to be that SAP is offering services not in their multicloud environment, but as services you can add from an AWS or Azure marketplace“.

Saying that SAP needs to improve is easy. Let’s try to add content that can add value for a possible solution to the problem. I’ll detail my marketplace idea here and look forward to some feedback.

One problem SAP has with SCP CF is that they do not own the data center. Services offered in the SCP CF trial are hosted by AWS, Azure, etc. and SAP pays for them. When you use a real SCP CF account, you pay money to SAP. Part of the money goes to the hyperscaler, some money stays at SAP. This setup makes it somewhat complicated to offer a free tier without having to spend millions hoping that someday the trial users start using the real SCP account. This concept is not always the best for customers. For instance, you are already an Azure customer. You do have your subscriptions, services, landscape and you cannot simply add the SCP services to it. They might run on Azure, but not in your account. If you have a good deal with your hyperscaler, your SCP services won’t benefit from it.

I think SAP should offer their SCP services in the marketplace for each hyperscaler. This alternative allows you to select the services you want and can run them in your account. Offering the SCP services as selectable services makes it real multicloud: you can run the services in the cloud you want, in the combination you need. You choose the runtime for each service. In case one team is on Azure, they can add i.e. SAP mobile services to their subscription. Another team uses AWS, and they add it to their landscape. As long as they have credits left to run a VM, it’s free. SAP can negotiate with the hyperscalers to ensure that their services are run in a free tier like offering.

SCP services may not only be offered in a traditional marketplace. Let’s rethink the marketplace concept. In SCP CF, the services already run on cloud foundry. They use a container. Why not use this container registry? Users can use a K8s service from the hyperscaler of their choice, load the SCP service image from SAP’s own container registry, and run them in their own environment. And with own environment I mean: the one the user has chosen and not the one SAP selected as one supported hyperscaler. SAP has tools that help running a K8s cluster. I hope the image below helps to understand the concept.

The container registry is under SAP’s control. They can offer images for free access or restrict success to some images to registered users. Additional benefit for licensed customers could be to offer not only the latest version, but all supported versions. SAP can offer the base version of the image free to all, and when you need a cluster (aka productive usage), access to the operator is restricted to licensed customers. This approach makes it possible to go real multicloud with SCP services: distribute your solution on several hyperscalers. If one goes down or ends operation (hello Google), your app stays online.

Of course there is some serious work involved. You have identity management, secure connections, SAP cloud connector and destinations, to name a few. Redesign some services to work with K8s. One outcome is that the services are generally available and in case of OTC they are running on OpenShift. That’s another flavour SAP can add to its supported runtime list. It won’t be super easy, who said multicloud and customer experience is going to be easy?

A nice twist of this approach is that developers can start using SCP services instantly. They can integrate them in their solution and environment. In case they are in the subscription of their company, it’s free for the developer. This “free tier” makes innovation possible. If the app grows, it grows in the customer environment. When a license is needed from SAP, it should be possible to get one via a fully automated, non-sales driven process.

And for those customers that do not want to run SCP services on their own? That do not want to deal with K8s and all the other hyperscaler services and management overhead? SAP can still offer their current SCP multicloud. It’s just another option from which customers can choose.

The above is my idea for running SCP services in a real multicloud way. Additionally, for the developers and development path only, where you do not need SCP services, but just the environment to run code, SAP should add these to the hyperscaler offerings. For instance, at Azure you can develop web apps using predefined templates. SAP can work with Azure together to get CAP (node.js flavour) in there. While some people think that running CAP outside the very restrictive HANA, XS and CF scenario is a waste of time, developers with actual customer contact see tremendous value in this. Node.js is already available, getting CAP included should be possible, given SAP’s and Microsoft long and outstanding partnership. You can do this today; the Azure offering is for generic web apps including Node.js apps like CAP. To thrive adoption, having it available as a pre-configured template will get more developers experience the SAP way to develop enterprise apps.