Evolving Hyperscalers and SAP BTP: A Guide to Cloud Native Innovation

Traditional development with SAP has evolved from Classical ABAP to ABAP RAP, SAP CAP (Cloud Application Programming Model). Its analogous to moving on from doing Stop Motion animation to immersive CGI to virtual reality that we experience today. The need to evolve and innovate has never stalled for SAP rather has accelerated and multiplied in last decade. With an imperative to keep the core clean and lean in the new SAP world, the side-by-side concept has pushed the extensions towards the cloud to orchestrate the data and processes with cloud native capabilities in Hybrid cloud environments.

Evolving Hyperscalers

Hyperscalers tend to have higher churn rates on innovative platform services and are sharing the side-by-side extensibility space with SAP BTP. Whether you go with SAP BTP as your primary extension platform and create plethora of cloud native applications on the periphery utilising the native platform services on hyperscaler’s, or you go pure Hyperscaler based extension is based on the hyperscaler startegy your organisations are adopting for now or in future. It can influence the choice of application services, development services or data services that will have direct influence on how quickly you can turn around an innovative idea to a product or service. That is dependent on the vision the organisation or business has about its products and services in the near and long term.

The extension and innovation platform choice is further influenced by SAP footprint on the landscape, where you are in the S/4 HANA adoption journey, how open is your organisation for open source innovation, the development culture, cloud native skillsets are a few other facets to consider. Its an architectural choice, again influenced by platform services that will help drive your innovation agenda.

What if you want to abstract yourself from all these choices and changes that may overturn, the decisions your organisations take today in the future as hyperscalers evolve i.e. continue accelerating your digital transformation agenda. Red Hat OpenShift creates that abstraction layer and provides the scalability, interoperability and control that the organisation desires. Its like a hovercraft which glides across the changing turf. Its about getting from point A to B with the least number of changes in direction. The good part is all SAP BTP extensions work in harmony and unison along sides the Red Hat® OpenShift® cloud native applications / extensions i.e. you can opt to choose best of both worlds.

The open innovation built behind Red Hat® Openshift® and its products is critical to achieving digital transformation objectives. This open innovation and embracing open source has driven tooling that enables us to do the following:

• Innovate anywhere, at pace and agility on any cloud


• Consumption based models with wider ecosystem platform services


• Reduce the turn around times with streamlined deployment cycles.


• Improve team productivity Dev + Sec + Ops


• Optimise costs and efficiencies, share resources, accelerate with repositories of reusable assets and components.


• Moving away from VM’s with operating system footprint to application footprints, which enables hosting and running multiple applications and functions consuming the same amount of compute.


• The docker image or the golden image of the application can reproduce the same results with same behaviour and consistency in any environment. The immutability results in interoperability.

As organisation comes to realise that "Cloud Adoption" is not just modernisation of applications with lift and shift to the cloud but the true value is realised by change in the organisation culture, the development and delivery practices, with Continuous Integration and Deployment practice, the Architectural and Integration Patterns.

Modular Architectures

Modern Architectures and Agile Integrations (source : IBM + Red Hat)

From enterprise architecture point of view, it’s how do we move away from traditional integration like enterprise service buses towards more of an agile integration which is decentralised. For e.g. we don’t want applications hogging system resources 24*7 to serve couple of requests. When we talk about event driven architectures, we can have a serverless function, being invoked by event or a web-hook call, spins up for the moment serves the request Just-In-Time and then spins down.

With headless architectures, we are more microservices driven for any front end framework as far as it adheres to the API Contracts for the capabilities being delivered by underlying platform. When we look at Edge devices, we are using machine learning on edge , sifting out the most criticak data points for further insights from what is being sensed. Pub-Sub mechanisms allow application to listen for events / messages, to react only if they are relevant for any action. Istio Mesh based distributed Microservices deployment leads to failsafe, resilient, secure and observable mesh network.

So we can almost end up distributed architectural components with a RACI matrix of all things, applications and digital entities that are part of that ecosystems which drive the enterprise systems and processes. This is where we start seeing the way we design applications become more modular, agile, scalable across different clouds to be iterated more quickly and more efficiently.

Delivering Outcomes at Speed, Scale and Control

Shift in the way we deliver outcomes (source : IBM + Red Hat)

Adopting dev-sec-ops takes a lot of different steps moving away from traditional methods and practices to hybrid cloud platform approach. Moving from siloed teams using waterfall delivery methods, to Agile practices with CI/CD adoption. Deploying in hybrid, public / private cloud with enterprise grade container platforms, is preferred over VMs with co-located workloads in data centers. From an application perspective we’re still building these monolithic applications and we need to start to move towards more