Devops With BTP
Devops With BTP
DevOps?
3 10 1,831
Introduction
In today’s rapidly evolving technology landscape, where agility and efficiency are paramount, DevOps has emerged as a
game-changer. But what exactly is DevOps, and how does it relate to SAP Business Technology Platform (BTP)? If you’re
new to these terms or seeking to understand how they work together, you’ve come to the right place.
Welcome to this blog series to Demystify DevOps with SAP BTP, where we’ll unravel the mysteries of DevOps in simple
terms and show you how it can supercharge your SAP BTP experience.
Whether you’re a seasoned IT professional or just dipping your toes into the world of technology, this blog is your first step
toward mastering the essentials of DevOps and its powerful synergy with SAP BTP.
So, let’s embark on this journey of discovery, where we’ll break down complex concepts into simple, digestible pieces and
explore how DevOps can transform the way you manage your SAP BTP projects.
For ease of reading, I have split the content into two blogs, which are:
1. Demystifying DevOps with SAP BTP: Part 1 – What is DevOps? [Current Blog]
2. Demystifying DevOps with SAP BTP: Part 2 – Navigating SAP BTP DevOps Portfolio
Targeted Readers
This blog series is targeted for people who are completely new to DevOps and need a guidance on how to start their journey
on DevOps with SAP BTP.
What is DevOps?
Why DevOps is so important for all IT organizations, be it small or big.
What are some of the important concepts around DevOps – e.g. DevOps Lifecycle Model, CI/CD etc.
What are the services, tools and frameworks SAP BTP offers to implement DevOps.
How to implement DevOps in SAP BTP along with best practices and guidelines.
Prerequisite
Before understanding DevOps with SAP BTP, you should have a basic idea what SAP BTP is. If you are new to SAP BTP,
please spend 5 minutes reading this blog – Explaining SAP Business Technology Platform (SAP BTP) to a Beginner
Let’s start!
What is DevOps?
Imagine world’s best musicians are playing an orchestra together. Best guitarist, best pianist, best flute player etc. Would you
like to see their performance? I am sure most of you would say, YES.
Now, let’s imagine there is one problem in this orchestra. There is no Conductor. Due to that, every musician is only
focused on his/her performance. There is no synchronization among them. Everyone thinks that only his/her performance is
important and does not care much about others.
Will you still like to see the performance? Of course NOT, because without proper synchronization, the orchestra will be a
mess.
IT organizations had similar problem. Multiple teams working in silos and focused only on their own goal. No proper
collaboration and communication. Everyone thinking that their job is most important and not caring what others are working.
It resulted into lengthy release cycle, quality issues, operational issues etc.
Some will emphasize on automation tools, some will talk about best practices, some may focus on CI/CD pipelines. All the
points are correct up to some extents. DevOps is something a mix of all of this. However, more than anything, DevOps is
about culture of bringing the teams together and taking down the wall of separation. This change in culture leads to efficient
development and delivery cycle.
Out of several definitions of DevOps, this one I find quite simple yet effective.
DevOps is:
— Ken Mugrage
In any IT organization be it small or large, there are mainly two types of teams – Development and Operation. In a non-
DevOps environment, although both the teams work for same organization, their goals are very different from each other,
they work in isolation and many a times they see each other with disbelief and disagreement.
As shown in image above, development and operation teams often have conflicting goals. While development is too focused
on developing the solution and releasing new features quickly, they tend to ignore how the application will run in real life for
end users. On the other hand, operation team is focused on keeping the application running and stable. Their primary job is to
make sure that end-users don’t face any problem.
In non-DevOps environment, we often see a situation such as an application is throwing error while being deployed to
production environment. The team’s response is like:
Development Team: “It’s not my code that’s causing issues. It’s your machine/system.”
Operation Team: “It’s not my machine/system that’s causing issues. It’s your code.”
Here we have taken example of only two teams – development and operations teams. In reality, there could be more teams
working together such as quality assurance, documentation teams, infrastructure support team, user experience experts
(UX), and product managers (PM).
This results into higher communication costs and create silos that prefers not to see anything beyond their atomic works.
Further if the teams are located at different locations this add into more chaos.
In DevOps culture, we don’t have separate teams working in silos. All the teams are merged in one single team and it’s
everyone’s responsibility to work throughout the application lifecycle from development to test to release to operation.
In DevOps everyone works together which creates a positive environment and everyone’s goal is aligned with each other.
DevOps enables the teams to handle the issues more effectively without wasting enormous amount of time in creating
tickets or waiting for individual’s hand-off documents from a colleague sitting right next to you.
Develop Phase
Develop phase, also known as Code phase, is where development teams do their magic and build the solution. Source code
repository plays a very important role in this phase where all the developers collaborate and finally have a single source of
truth.
Build Phase
Once developers push their code Build phase starts where code is built into artifacts to deploy on various
server/environments.
Test
After the build phase is done, we have the solution deployed to test systems where several types of testing for example
functional testing, performance testing, security testing, user acceptance testing etc. happens.
Release
After the test phase is done, we have the solution ready to be deployed to production server/environments. In this phase we
release the new solution or a new version of an existing solution into productive environment.
Deploy
In this phase, the solution is deployed into one or more production environment.
Operate
After the deploy phase, solution goes live and get started being used by customers. The operate phase is all about managing
the running solution along with the underlying infrastructure and make sure end-users don’t face any issue.
Monitor
This is one of the most important phases of DevOps. In this phase, DevOps teams have all the monitoring and alerting in
place. It’s important to get the alerts not only there is an issue but also when there is a chance to get issue in future. For
example, high CPU usage, bottlenecks scenarios, disk usage should be properly monitored for proactive maintenance. The
aim at this phase is to achieve system reliability, high availability and zero downtime.
The DevOps infinity loop is not a fixed set of steps. Every organization plans their own DevOps infinity loop to suit their
requirement and culture.
Developers merge their code changes to a central repository whenever they finish a logical task.
The merged code is automatically built and tested to make sure that it’s ready for production.
Continuous Delivery (CD) starts at the end of Continuous Integration (CI). In continuous delivery the code changes are
automatically built, tested, and released to production.
The below image shows the CI/CD in conjunction with DevOps lifecycle.
In simple words:
Continuous Integration and Delivery (CI/CD) Continuous Integration and Delivery (CI/CD)is a set of tools, guidelines and
best practices that enable development teams to deliver solutions more frequently and reliably.
By now, you should have got a clear idea on what DevOps is. In the next blog, we will learn about the services, tools and
frameworks SAP BTP offers to implement DevOps.
Demystifying DevOps with SAP BTP: Part 2 –
Navigating SAP BTP DevOps Portfolio
4 10 3,070
Introduction
This blog is part of the series Demystifying DevOps with SAP BTP.
This blog series aims to Demystify DevOps with SAP BTP for beginners, where we’ll unravel the mysteries of DevOps in
simple terms and show you how it can supercharge your SAP BTP experience.
Whether you’re a seasoned IT professional or just dipping your toes into the world of technology, this blog is your first step
toward mastering the essentials of DevOps and its powerful synergy with SAP BTP.
For ease of reading, I have split the content into two blogs, which are:
2. Demystifying DevOps with SAP BTP: Part 2 – Navigating SAP BTP DevOps Portfolio [Current Blog]
In the previous blog, we learnt about DevOps and some of the important concepts around DevOps – e.g. DevOps Lifecycle
Model, CI/CD etc. Now, let’s explore various services, tools and frameworks SAP BTP offers to implement DevOps. We will
also get a holistic overview on how to implement DevOps in SAP BTP.
Let’s start!
Let’s first have a quick look on what services and tools are offered by SAP BTP in each phase of DevOps lifecycle.
SAP BTP also provides a very powerful command line tools called “SAP BTP Command Line Interface (btp CLI)” to
manage accounts and perform other administrative tasks.
It contains best practices and recommendations for planning development projects – from setting up the correct
organizational structure to creating an account and security model, to developing and operating applications.
SAP Continuous Integration and Delivery – An SAP BTP Service, mainly suited for SAP-centric use case, does not
require lots of skills to build a pipeline.
Project “Piper” – An open-source project and libraries that provides templates for pipelines, best suited when you want to
use predefined template and have some flexibility.
Continuous Integration and Delivery Best Practices Guide – Best practices guide if you want to completely own CI/CD
pipeline with full flexibility.
The main difference between these 3 options is in terms of skills required and level of flexibility as shown below.
Let’s have a close look into each of these 3 options.
It comes with interactive user interface and helps us configure and run an out-of-the-box CI/CD pipeline without much
hassle.
SAP Continuous Integration and Delivery is mainly suited for SAP-centric use cases and supports SAP Fiori, SAP Cloud
Application Programming Model, SAP Integration Suite artifacts and container-based applications. Below image shows a
high-level view of SAP Continuous Integration and Delivery.
Project “Piper”
Project “Piper” is an open-source project which provides a more flexible option than SAP Continuous Integration and
Delivery and yet is not too difficult.
The vision behind Project “Piper” is to enable SAP customers and partners to ease up CI/CD implementation and help them
choose best SAP and non-SAP solutions for it along with predefined templates and libraries. Piper is based on Jenkins.
Unlike SAP Continuous Integration and Delivery or Project “Piper”, we don’t get any ready-made pipelines in this case
rather we get best practices, guidelines, and steps on how to apply principles of CI/CD on SAP specific technologies.
Below image shows a high-level view of CI/CD Best Practices in SAP BTP.
SAP BTP DevOps Portfolio – Develop & Test
Once the planning phase is completed, the blueprint of the development is ready, SAP BTP accounts is configured, landscape
is setup, approach to configure a CI/CD pipeline has been chosen and an initial pipeline has been configured.
Now is the time to Develop the solution. SAP BTP provides a rich set of tools, frameworks and services for this phase, some
of them are:
SAP Business Application Studio comes integrated with a command line tool, an optimized editor and all the major plugins
we need for SAP BTP development.
How does SAP Business Application Studio play a major role in Develop, Build and Test
Phase
SAP Business Application provides an excellent experience for developing a solution for SAP ecosystem. It extremely
simplifies the developer experience, improves development as well as DevOps operations, and offers better time to market.
Below image illustrates a high-level overview of different components and features of it. Dev Space is like an isolated
development environment containing tailor-made tools and extensions and pre-installed runtimes as per the development
scenario, for example, SAP Fiori, SAP Cloud Application Programming Model, SAP HANA etc.
As shown in image below, SAP Cloud Application Programming Model includes a mix of SAP and open-source
technologies.
SAP CAP empowers developers to minimize the overall development effort by helping them to focus on their business logic
and relieving them from tedious repetitive tasks which are common across application e.g., user and security management.
Multitarget Application
A cloud solution usually composed of multiple software modules representing database entities, business logic, backend
services, UI layer etc. For example, a typical solution on SAP BTP usually have a HANA module which contains database
related artifacts (e.g., calculation views), a backend service (e.g., a CAP or Java or Node.js module), an SAP Fiori
Launchpad module and an SAPUI5 module as shown in image below.
There are couple of challenges that we face with such applications having multiple modules.
One of the main challenges we face with such application is deployment. If all the modules are built separately and have
their corresponding deployment archive file, then we will have to make sure that the dependency is properly maintained
during deployment. For example, if Java module is deployed before SAP HANA module, then it will fail because
dependencies will not be found.
Another challenge is related to the SAP BTP configurations and service instance creation. For example, if the application is
using any SAP BTP services (e.g., Destination service or XSUAA service), then we need to make sure that the service
instances are created before deploying the application. Even if service instances are created, the deployment might fail if the
service instances are not properly mapped to the application.
Lifecycle maintenance
Lifecycle maintenance of individual modules separately is another big issue. If a module has been upgraded, we need to
make sure that in all deployment other modules are using the updated version of each other.
A HANA module where we use HANA dependent language to create calculation views
A backend module implemented using SAP Cloud Programming Model
Business logics implemented in Java or Node.js or other language
SAPUI5 module to implement the UI
These modules can be deployed to different target platforms. For example, HANA module of MTA project may be deployed
to SAP HANA Cloud while the other modules are deployed to SAP BTP, Cloud Foundry.
An MTA project has a file called MTA Descriptor (mta.yaml) that contains a list of all the modules and resources (e.g., SAP
BTP Services or Environment Variables) and their dependency details. The complete metadata of all the modules and
resources are maintained in this mta.yaml file. At the time of deployment, this file is used to automatically create the SAP
BTP service instances, and interdependencies of all the modules and resources are maintained without any manual effort.
As shown in image above, an MTA project contains multiple modules and an MTA descriptor. MTA provides a tool
called Cloud MTA Build Tool which can be used to build the MTA project and generate an MTA archive file called MTAR
(similar to JAR file in case of Java). This MTAR file all the modules, MTA descriptor, resource binaries and configuration
files and can be used to deploy everything in one go.
Based on CI/CD approach you have taken (discussed earlier), you can add the configuration to deploy code to production
once all previous stages are successfully executed.
For example, in case of SAP Continuous Integration and Delivery service, you can add a release stage for SAP Fiori pipeline
or SAP Cloud Application programming Model pipeline and provide the SAP BTP account details for deployment as shown
below.
SAP Cloud Transport Management is one stop solution for all deployment and transport related requirement.
SAP Cloud Transport Management service adds transparency to the audit trail of changes so that you get information about
who performed which changes in your production environment, and when they did it.
At the same time, the service enables a separation of concerns: For example, a developer of an application or of SAP Cloud
content artifacts can trigger the transport of changes from within the development environment, while the resulting import
into the test, and production environment is handled by a central operations team.
Further, we create something called Transport Nodes which represents source and target subaccounts for deployment.
Transport occurs between these transport nodes. Next, we need a Transport Route to connect transport nodes.
SAP Cloud Transport Management service is also integrated into change and deployment management capabilities of SAP
Cloud ALM.
Have a development landscape, based on CI/CD pipeline which is used to verify, build and deploy the solution during
development phase.
Have another delivery landscape, using SAP Cloud Transport Management and use to verify release candidate versions
and deploy to productive environment.
For example, if you are using SAP Continuous Integration and Delivery service, you can let the pipeline directly trigger an
automated upload of your qualified changes to SAP Cloud Transport Management service, as part of the Release stage.
With this combined approach, development teams can start easily, by using an automated pipeline, and come up with results
quickly. However, as soon as they come up with a release candidate, you can regain control of the changes especially
towards the production environment with the then set up hand-over into transport and potentially also change management.
However, in any cloud infrastructure, there are many components which may cause a downtime for the solution, be it the
platform itself where solution is running, or the database server of the solution, or the underlying technology stack or the
solution itself.
In Operate and Monitor phase, we make sure that we properly monitor the entire landscape and solution stack and get
notification when things go wrong or are about to go wrong. For example, get a notification when solution crashed, get
notification when memory is 80% full because it may crash soon etc.
Let’s check the BTP services and tools which helps us in this phase.
For example, in the Cloud Foundry environment, you can either use SAP BTP Cockpit to access the logs. Alternatively, you
can also use the SAP Application Logging service to access logs from your applications. This service allows to access and
analyze log files stored in the Elastic stack, such as via predefined Kibana dashboards. You may also run the Cloud Foundry
CLI command cf logs to show the recent logs for an application.
To have a full-stack monitoring of BTP apps, you may also use third-party application performance monitoring solutions,
such as Dynatrace.
After deploying the solution in a live environment, it’s crucial to monitor all the modules and services closely. Various types
of problems can arise that impact the experience of the end-users. For example:
We must establish a reliable alert system for all situations. This is where the SAP Alert Notification Service becomes
important. It enables us to set up and customize alerts for both the solution itself and the services it relies on, ensuring a
standardized approach. We can configure the SAP Alert Notification service for any of these SAP BTP services or
applications and get the notification to various target system as shown in above image.
SAP Alert Notification service also can be easily integrated with other SAP BTP services. For example, while create a CI/CD
pipeline in SAP Continuous Integration and Delivery, we can configure to get all pipeline notification using SAP Alert
Notification Service.
SAP Automation Pilot service can be configured with other SAP BTP services to automate the DevOps tasks. Let’s take an
example scenario. Say, we need to monitor SAP HANA Cloud service. In case the database server is down, DevOps team
needs to restart the database and send the log for further analysis.
To automate this, we may integrate SAP Automation Pilot with SAP Alert Notification Service as shown below.
In case SAP HANA Cloud has an issue, it sends the alert via SAP Alert Notification Service. Upon receiving an alert from
SAP Alert Notification Service, a set of tasks or commands configured in SAP Automation Pilot gets automatically executed.
In this case, a set of commands can be configured to restart the database and send the logs.
Across its complete ecosystem, SAP offers several strategic operations platforms. As many customers have invested in
corresponding processes on these platforms, it’s important that also the SAP BTP tools and cloud services that drive DevOps
can smoothly integrate there, so that you can stick to existing, known processes.
This also allows us to handle hybrid solutions that span beyond SAP BTP.
It’s intended for customers who use solutions provided by SAP, and who do not want to use their own ALM on-premise
platform to manage those solutions.
This ALM product addresses customers with advanced needs in system management, user and integration monitoring, and
configuration and security analytics.
With this highly integrated solution you can implement, maintain, run, and adopt all enterprise solutions – SAP and non-SAP
software – while supporting business innovation, business continuity, and efficient operations.
For example, in SAP Cloud ALM, we can receive alerts sent by SAP Alert Notification.
Or SAP Automation Pilot can be integrated with SAP Cloud ALM to trigger customized or predefined commands on SAP
BTP via SAP Cloud ALM Operation Flows.
SAP Alert Notification service also allows an out-of-the-box integration into SAP Solution Manager and SAP Focused Run.
By now, you should have got a clear idea on DevOps with SAP BTP. If you have any queries, let me know in comment or get
in touch with me at LinkedIn!
To know more about applying DevOps principles efficiently on SAP BTP, you may also refer to:
You may also have a look into my book “DevOps with SAP”