Safeguard your Investments with Red Hat OpenShift
What if…
As Enterprises underpinned by SAP are expecting more flexibility from their IT systems — more than ever before. As they emerge from the pandemic and lockdown, moving out of business survival mode, into business recovery, and finally into business growth, they expect their SAP solutions to empower people to execute lean and intelligent process on optimised, secure and scalable cloud platforms.
· What if your developers can innovate at the speed of business without hindrance or constraints of classic interdependencies within the SAP application layer?
· What if your business users were able to consume data in real time using rich user experience powered by cloud native services?
· What if you could lower TCO with modular, low-code/no-code and serverless applications that wrap around SAP core and maximise value from either ECC6 or S/4HANA?
Well — we can do that with SAP development with Red Hat OpenShift solutions. Here’s how:
Safeguard your Investments with Red Hat OpenShift
Traditional development with SAP has evolved from Classical ABAP to ABAP RAP, SAP CAP (Cloud Application Programming Model). Its analogous to moving from Steam Engine with requires a lot of energy for propulsion, with long journey times of many days to a innovative Hyperloop solution which propels passengers in a streamlined cabin through a vacuum tube cutting the same travel times to < 30 minutes.
The need to evolve and innovate has never constrained SAP. Rather, it has accelerated and multiplied in the last decade. Clients are looking to preserve and protect their SAP investments, so they are keen to keep the core clean while adopting Lean ERP into the new SAP world. This is where SAP’s side-by-side development concept has meant that new custom developments like extensions to core standard processes are developed using cloud native technologies, so that they orchestrate the data and processes across integrated 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 to create plethora of cloud native applications on the periphery utilising the native platform services on hyperscalers, or you choose to adopt a pure Hyperscaler based extension based on the hyperscaler strategy, the choice of application services, development services or data services has a direct influence on how quickly you can turn around an innovative idea to a product or service ready for business consumption. This choice is dependent on the vision that the organisation or business has about its products and services in the current, interim, and future modes of operations .
The choice on the extension and innovation platform is further influenced by the following factors:
· How pervasive are SAP applications within wider application estate,
· Where you are in the SAP S/4HANA adoption journey,
· How open is your organisation for open source innovation?
· The application development culture
· Availability of Cloud native skillsets within the Enterprise and ecosystem
These are a few other factors to consider. This leads to a set of architectural decisions, influenced by available platform services that drives your innovation agenda.
What if we were to simplify these decisions by decoupling people, process, data, tools and platform technology so that these choices and decisions can be made without impacting the other layers of the architecture? This way, as business needs evolve, we have reduced risks of regret costs when we enhance capabilities around SAP by embracing the best features/functionalities from both SAP and the hyperscalers platform services (as both of these evolve at pace).We can then better manage a continuum of accelerated innovations that power your digital transformation objectives.
Red Hat OpenShift creates that abstraction layer and provides the scalability, interoperability and control that the organisation desires. It’s like a hovercraft which glides across the changing turf. It is 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
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.
When we talk about 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.
All of this means that 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
Adopting DevSecOps 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 centres.
From an application perspective we’re still building these monolithic applications and we need to start to move towards more modular, decentralised architectures and agile integrations, delivering microservices or serverless functions as explained above.
When we talk about speed we’re really talking about time to market, Agility how quickly we can make new updates, new commits to specific processes or applications further how they can be simplified as far as the process more streamlined so that we have more freedom to experiment.
The personas within these different roles especially when you’re a developer you’re usually, much more bleeding edge, want a quick turn around. Build once and run everywhere is emerging trend amongst the developers to cater the business demands.
Though the questions like, how do we scale with resilience without sacrificing the stability and control of enterprise landscape, needs to be addressed. When you’re on the operations side or administration side you want a little more tried and trusted so you know how we enable both and then control how do we mitigate any kind of risks and security any kind of issues with bugs how do we approach them more quickly when they do come up.
Red Hat OpenShift — Smarter Kubernetes
This is where the containers are becoming a defacto standard in the cloud native application development. It is underpinning the adoption of Devops culture. Containers promise things like application portability across any cloud.
They allow developers to really just focus on building their apps instead of having to worry about the underlying infrastructure technologies. This is where you would require a policy based automated container orchestration mechanism and features to manage containers across your dev, test /staging and production environments.
Kubernetes as open source, has really emerged as the standard for container orchestration, management and scalability, Though just installing Kubernetes to have a production grade platform is not enough: you’ll need to add authentication, networking, security, monitoring, logs management. That means you will also have to pick your tools among everything available (see CNCF landscape to get an idea of the complexity of the ecosystem), and maintain the cohesion of all of them as a whole; but also do updates and regression tests whenever there is a new version of one of these components.
With OpenShift, Red Hat has decided to shield this complexity and deliver a comprehensive platform, including not only Kubernetes at its core, but also all the essential open source tools that make it an enterprise-ready solution to confidently run your production. Of course, in case you already have your own stacks, then you can opt-out and plug into your existing solutions.
Here are benefits of adopting OpenShift when containerising SAP extensions:
- OpenShift allows you to deploy traditional stateful applications, alongside cutting-edge cloud-native applications, by supporting modern architectures such as microservices or serverless.
- At IBM, we believe that open source technologies used for containers, Kubernetes and DevSecOps are the key ingredients that a modern application platform should be based on that allows you to transform your traditional apps, build cloud-native applications and also experiment with analytics, machine learning and serverless applications.
- This application platform needs to provide a consistent way for both developers and operations teams to collaborate across all deployment footprints, from Edge and air gapped environments to infrastructure you have in your own data centre and all the way to the hybrid cloud.
- OpenShift allows you now to even migrate your legacy virtual machines to OpenShift itself by using Container Native Virtualisation
I have been advocating the container-based extensibility with modern architectures at several of IBM’s SAP Clients using Red Hat Openshift Platform and portfolio of products.
I believe that the developers have the power and energy to create and architects help channelise that energy in right direction for business outcomes, while operational teams provide a level playing field for all participants of the Innovation Games.
Liberating these personas of the traditional shackles is the need of the hour and this is what I am talking about in my upcoming talk on SAP and Openshift : From classic ABAP development to cloud-native applications.
Please join us to know more , where we also cover a demo to show you how we deploy cloud native extensions with OpenShift. Our demo is based on modularising and separating the UI, Business Logic and the System functions using several Red Hat Openshift Products and Platform services to create a modern decentralised architecture. It is a Sales Order Approval Scenario which covers three Fiori apps :
· the Shopping Cart for Customer persona,
· the SO Approval App for the Approver persona
· the Back-office persona using the approved Sales Order app to complete order fulfilment.
All Fiori apps / SAP Ui5 apps deployed on Openshift Containers, invoking microservices and serverless functions, streaming events and reacting to them using Red Hat Openshift streams for Apache Kafka broker.
For more details on technical deployment with sample code on GitHUb refer to the blog here : https://blogs.sap.com/2021/06/23/make-sap-cloud-native-and-event-driven-in-4-days/
Hope you find this blog useful. Feel free to comment and get in touch.
