Demystifying DevOps with SAP BTP: Part 1 – What is DevOps?
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]
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.
In this blog series, we will learn:
- 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.
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
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.
This led to the birth of DevOps.
So, what exactly is DevOps?
There are several definitions of DevOps available in Internet and different perspective to explain it. If you ask what DevOps is to people from different organizations and different teams, you will be surprised by the variation in the responses.
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.
“A culture where people, regardless of title or background,
work together to imagine, develop, deploy, and operate a system”.
— Ken Mugrage
The Problems in a Non-DevOps Environment
To clearly understand DevOps, it’s important to understand how IT organizations used to work before DevOps and what problems it used to face which DevOps solved.
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.
How Does DevOps Solve This Problem?
To solve the problem discussed above, we need to throw over the wall behavior and bring both the team together as shown in image below.
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.
How Does DevOps Work?
DevOps is not a product which we can buy from some vendor. It’s a methodology, a shift in culture, a collection of tools. DevOps implementation can be visualized as an infinite loop consists of different phases as shown below.
In the planning phase, all the teams work together to have a crystal-clear understanding of business requirements and decide how the solution should be built with what features. In this phase, we also decide criteria for completion of each phase. DevOps tools and frameworks and services are explored, and right options are chosen.
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.
Once developers push their code Build phase starts where code is built into artifacts to deploy on various server/environments.
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.
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.
In this phase, the solution is deployed into one or more production environment.
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.
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.
Continuous Integration and Continuous Delivery (CI/CD) – Backbone of a DevOps Methodology
Continuous Integration and Delivery (CI/CD) is part of DevOps which helps us to automate manual intervention required to move code from development to production.
Continuous Integration (CI) is the practice where:
- 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.
The main goal of Continuous Integration is:
- Find and fix the bugs quicker.
- Improve software quality.
- Reduce the overall time taken to release the solution or a feature.
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.
Next blog in the series:
If you have reached so far, please let me know your feedback on this blog in the comment section!
To know more about applying DevOps principles efficiently on SAP BTP, you may also refer to: