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.
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:
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.
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.
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 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 solutions, how do we enable both the personas and then control how do we mitigate any kind of security, risks or any kind of issues with bugs, how do we approach them more quickly when they do come up.
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.
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.
The 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 architectures. Its a Sales Order Approval Scenario which covers three Fiori apps : the Shopping Cart for Customer persona, the SO Approval App for the Approver persona and 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. More details on technical deployment with sample code on GitHUb refer to the blog post here : https://blogs.sap.com/2021/06/23/make-sap-cloud-native-and-event-driven-in-4-days/
Hope you find this article useful. Feel free to comment and get in touch.
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 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 solutions, how do we enable both the personas and then control how do we mitigate any kind of security, risks or 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.
Red Hat Openshift run on "Anycloud" (source : IBM + Red Hat)
- 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 containers, Kubernetes and Devops 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 datacenter 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.
The 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 architectures. Its a Sales Order Approval Scenario which covers three Fiori apps : the Shopping Cart for Customer persona, the SO Approval App for the Approver persona and the Back-office persona using the approved Sales Order app to complete order fulfilment.
Demo Scenario : Sales Order Approval (source : IBM + Red Hat)
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. More details on technical deployment with sample code on GitHUb refer to the blog post here : https://blogs.sap.com/2021/06/23/make-sap-cloud-native-and-event-driven-in-4-days/
Hope you find this article useful. Feel free to comment and get in touch.
- SAP Managed Tags:
