SAP Cloud Platform - Open or opinionated?

matt_steiner · ‎10-22-2018

In my role as cloud platform evangelist I wrote many blog posts about SAP Cloud Platform over the course of the last years. From the very beginning [1], one of the key talking points was our explicit focus of building the platform with openness as a fundamental design principle. And while openness is an important aspect for many reasons, overemphasising this aspect can also back-fire and in the worst case may distract from what truly sets SAP Cloud Platform apart from other cloud platforms.
Sort of:

"When you stand for nothing, you fall for everything." [2]

In that context, it's important to explain both sides - openness and differentiators - in order to get the big picture. So, with today's blog post I want to do exactly that: explain why offering an open platform matters and at the same time elaborate on one key differentiator of SAP Cloud Platform (in an opinionated way).

The Platform Play

When it comes to a "platform play" [3] there is really just one thing that matters: adoption. The rationale is quite simple: the more customers use your platform, the more interesting it becomes for partners and developers to develop for. And the more parties developing great solutions on top of your platform, the more attractive it is for customers. SAP's CTO and President of Cloud Platform, Björn Goerke, sums it up perfectly [4]:

"[...] any platform is only as successful as the ecosystem around it and that – if done right – platform is a positive sum-game."

So, how to gain adoption? There are two main aspects: business value and ease-of-use. Those need to go hand in hand in order to be successful. Hence, from a provider view one needs to strike a fine balance between openness and differentiators. Consequently, let's have a closer look at these two angles.

Open Platform

In a nutshell, the main value of a cloud platform can be condensed to one major value proposition: business agility. Cloud platforms facilitate the rapid deployment of new solutions, regardless of whether custom developed (build) or by subscribing to existing solutions (buy).

For both approaches, it's fundamental to offer a platform that provides both a development and a runtime environment for cloud applications. In addition, the buy scenarios also addresses the delivery and marketplace aspects of a cloud platform.

At SAP - we believe that the best way to ease and accelerate the development of new cloud solutions is via an open platform, based on open standards and open-source. This lowers the entry barrier (due to well-known technologies), reduces the total cost of development (via best practices, a global talent pool and the collective mind of the open-source community) and ensures a future-proof foundation in this time of fast-paced technology innovation.

Multi-cloud Foundation

Getting more concrete, this maps to the so called 'multi-cloud foundation' that comprises the technical groundwork of SAP Cloud Platform. It's an explicit abstraction layer that decouples from the underlying infrastructure (via multi-cloud) and runtime technologies (via multiple, complementing and interoperable environments). At this level, using cloud-native open-source technologies (aka cloud-native core) as the backbone of our cloud platform ensures that our customers and partners benefit from the rapid innovations. Given that open-source foundations such as Cloud Foundry Foundation and Cloud Native Computing Foundation are bringing together all major technology and enterprise software vendors, there's common interest in the industry to continuously enhance these strategic topics.

With openness comes options. And options boil down to choices. Making the right choice requires a throughout understanding of both the business challenge to solve and technical possibilities. And that's where guidance is needed to address questions like "Which environment to use for a given scenario?" or "Which services and tools to use to build my solution?" Needless to say, such guidance has to go beyond the classic consulting answer "It depends!" - and consequently, every guidance provided will (have to) be opinionated.

So, looking at the broader scheme of things related to cloud-native technologies we see three primary concepts addressing the development of business solutions and microservices: Container-as-a-Service (CaaS), Platform-as-a-Service (PaaS) and Function-as-a-Service (FaaS). If we map this to SAP Cloud Platform we see this being reflected in the short term roadmap with Kubernetes and Functions soon complimenting our PaaS environments (Neo, Cloud Foundry and most recently ABAP.)

For the sake of keeping this blog post at a reasonable length, I'll refrain from re-iterating the primary usage scenarios for each environment (I touched upon that in my last blog post [5]), but rather refer you to respective content and move on.

So, those who want to learn more about "Cloud Foundry and Kubernetes – Where do they differ? How do they fit together?" please refer to this comprehensive blog post [6] by my colleague Sanjay Patil. Or, if you prefer a short, crisp presentation on the topic, please check out the recording of my respective lightning talk from SAP TechEd Las Vegas: Cloud Native Development: Consider Your Options [7].

In summary, SAP is closely involved in the discussions about future technology trends and innovations in the cloud space and actively contributing to strategic open-source projects to make sure that our requirements derived from running large-scale enterprise loads are reflected in the roadmaps. As Björn Goerke wrote in a recent blog post in light of Google Cloud Next [8]:

"SAP has been at the forefront of promoting a joint future for Cloud Foundry and Kubernetes. In fact, for almost two years, we have started making the case for such a joint future and to discuss with similar minded companies on how-to bring the two technologies closer together."

Being represented in the boards of open-source foundations such as Cloud Foundry and CNCF, ensures that SAP is at the pulse of things and able to spot major trends early on. These governance entities are also the right place to be opinionated and openly discuss options for future directions as SAP did in regards of how Cloud Foundry and Kubernetes should come together. Of course, some of the major considerations to apply in such conversations are how-to reduce complexity, how-to shield developers and operators from continuous disruptions and provide a future-proof platform that is a stable foundation for smart business solutions and value-adding services and capabilities.

Closing the loop

And this brings us back to the opening question: open or opinionated? By now, you have probably guessed it, our take is: why not both?!?

We leverage open standards and open-source for our multi-cloud foundation and for other, more technical capabilities to ensure a state-of-the-art "engine room" and platform service portfolio. As said, though, openness can be a two-sided sword and the options and possibilities may be overwhelming or perceived as complexity. This is where guidance is needed and where a more opinionated approach may help those less-technically versed to find the "golden path" for them.

Application Programming Model for SAP Cloud Platform

This is where the Application Programming Model for SAP Cloud Platform [9] comes into play! It's a modular programming model that uses common building blocks such as core data services, a RESTful programming model and SAP's recommended UX technologies and paradigms such as SAP Fiori and SAPUI5. It comes with best practices and guidance and is tightly integrated into the development and life-cycle management tools offered as part of SAP Cloud Platform. This programming model aims to facilitate and accelerate the rapid development of cloud applications and services by addressing this need for guidance and best practices. As stated, the model was build in a modular fashion, hence individual building blocks or components can be mixed & matched with your preferred open-source components.

(Note: The RESTful ABAP programming model (RAP) of SAP Cloud Platform ABAP environment uses thesimilar building blocks and design principles, hence there really is this notion of an overarching, common development paradigm that unites the entire SAP developer ecosystem!)

Wrap-up

With that I'd like to conclude this blog post. I hope I was able to articulate SAP's approach and show that we are constantly trying to find the right balance between openness and opinionated guidance. What's your take - does that approach make sense? I'd love to hear your opinion and I'm looking forward to an open dialogue!

PS:

Those in Barcelona for SAP TechEd - have a great time and please engage with the SAP Cloud Platform team on this topic. Last, but not least - make sure to add sessions about the Application Programming Model and RESTful ABAP to your agenda. You can thank me later 😉