I hope you all survived the log4j Apocalypse and Christmas, hopefully you had a great ending of 2021 and an incredible beginning of 2022. It has been a complicated month and a half since I wrote my last entry:

• The log4j wasn’t that bad thanks to SAP for not having a newer log4j version in their OnPrem products. I guess hackers cannot attack you and exploit your infrastructure if the versions you use in your software are from thousand years ago. It only required a few workarounds and upgrading the HANA Cockpits.
• Coming back home from our Christmas trip was hell. The PNW suffered the worst snow storm in years and our flights were cancelled due to Coronavirus, Snow, etc.
• There are tons of projects and initiatives that started after vacation blackouts.
• Lot of things on the personal side, not sure if I said on my previous posts but I’m having a baby and I’m juggling between work, personal life and building the lair for the future goblin.

Anyway, I wanted to write this entry long time ago. I had the chance of working more on the code side during the past year and a half and a really good friend and coworker (you know who you are) introduced me to DevOps and Infrastructure as Code. It is a really exciting world and if you follow trends you’d probably saw that a lot of new position postings are related to DevOps/SRE. It allowed me exploring a different path than the one I have been doing for the past 10 years and I learnt some pretty cool things, unfortunately SAP is not the most flexible/agile company in the world and their products sometimes behave like ancient machinery but in the Basis side we can do some pretty cool stuff!

What is DevOps?

First thing we need to do is to defined DevOps and Infrastructure as Code (IAC):

DevOps is a cultural and professional movement, focused on how we build and operate high velocity organizations, born from the experiences of its practitioners.

DevOps Kungfu

If you prefer a different definition we can take the one that the GitHub guys gave us in their article What is DevOps? A guide to common methods and misconceptions:

The essential human element between Dev and Ops teams, when collaboration bridges the gap that allows teams to ship better software, faster.

For organizations, DevOps provides value by increasing software quality and stability, and shortening lead times to production. For developers, DevOps focuses on both automation and culture—it’s about how the work is done. But most importantly, DevOps is about enabling people to collaborate across roles to deliver value to end users quickly, safely, and reliably. Altogether, it’s a combination of focus, means, and expected results.

Jared Murrel / GitHub

So basically DevOps means breaking silos and walls so IT works as one on both Development and Operations sides. There is no more Developer Team and Operation Team since ownership is shared by both sides acting as one and focusing on delivering solutions with speed, stability and reliability. Cool right? It sounds like the Holy Grail. Some principles:

• The focus of DevOps is people.
• The means of implementing DevOps is process and tooling.
• The results of DevOps is a better product, delivered faster and more reliably.

I totally recommend watching the following keynote from 2015 about DevOps Kungfu since it kind of mark the start of the DevOps culture on the IT world:

Yeah you probably are thinking that this is not new and some companies have been doing the same since decades ago. Let me tell you something, you are probably right. I’m sure there were companies out there following the same principles in the past but the big expansion of DevOps happened in the last years. We are transitioning from a world that worked on a waterfall model with strict separation of teams and ‘discrimination’ between Development and Operation to a world that works on agile with full integration between teams and areas.

If you still don’t believe me I recommend that you read/listed to an awesome book named The Phoenix Project. It is difficult in the beginning since it totally reminds us about how we struggle on a daily basis with some of the most common problems we face but give it a try, I’m 100% sure it will change the way you think.

Alright now that we know about DevOps the next questions is how get there. The GitHub article I shared before gives us a few starting pointers:

• Shared ownership through collaboration, understanding and embracing that everyone is responsible and contributes to the work in some way. No more ‘your application broke my production system’, ‘you take too much time deploying new boxes’, ‘this is not secure and you guys have no ideas about hardening your solution’, etc.
• Rapid feedback achieved thank to the idea of automating repetitive tasks like reporting and testing.
• Using automation to help avoid the trap of institutional knowledge. It enables consistency, reliability and efficiency making it easier to troubleshoot and fix possible bugs.

This last point bring me to the next topic…

What is Infrastructure as Code?

There are a lot of definitions of Infrastructure as Code but let’s use the one provided by Red Hat:

Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes.

Some dude from Red Hat

It basically means… whatever, I think it is pretty explanatory. Instead of building infrastructure manually we code it and we use automation and tools to deploy that code. A really simple example of a JSON file used on Azure in order to create a storage account:

Another really simple JSON file used to deploy a VM:

You can basically use whatever you want to deploy your infrastructure. The following diagram shows the different part used for deploying infrastructure following IAC principles:

So we basically have a code repository where we upload the code that develop, then this code is read from the CI/CD tools such as Ansible, Jenkins, GitLab, etc. that would deploy my infrastructure OnPrem or in the Cloud provider that I choose. The cool thing is that any new VM, Storage Account, Database, container, etc. that I deploy will be done automatically using the code that I previously wrote and that Infrastructure will be maintain and aligned in the future to the code I created. Think about it as a factory and a way to standardize deployment and builds across my company.

There are some cool examples about IAC in the Google SRE Book like for example that time when they deleted part of their infrastructure and they redeployed everything automatically following IAC principles and automation.

On the SAP side this opens a whole new world of possibilities, you can deploy new systems, perform upgrades/updates, perform system refreshes, system copies, etc. following the same pattern and using code instead of the traditional way of building each system or performing the same operations manually. You can even automate code deployment between systems and perform the validations and test using these tools in order to verify that everything is working as expected without manual intervention. Sounds amazing, right? Well, I’m sorry to destroy your dreams but SAP is still not there…

Why SAP sucks (period)?

All this bring me to the big problem: SAP sucks when talking about DevOps and IaC. There are multiple reasons but first I’m going to recommend you the following presentation about DevOps in SAP that pretty much resume much of the issues we find on a daily basis:

Apart of what Chris Kernaghan commented in the video regarding the multiple technologies used, types of architecture, multiple vendors working in the same infrastructure, etc. I want to add some examples of my own:

• SAP refused for a long time to allow a DevOps approach for their whole software lifecycle and pushed their own agenda forcing you to adopt their own products. First example that comes to my mind is CTS+ and ChaRM for documenting and managing changes across the SAP landscape. Do you want to use your own software for doing the same tasks or use something as ServiceNow? Good luck with it because SAP gives zero help when coming to integrating external software with their own products.
• SAP ignores demands from their customers in order to make the SAP implementation more ‘agile’ oriented. Let’s be honest, SAP project still take an insane amount of effort and time making an agile project almost impossible or releasing a MVP a pain in the ***. Scrum you say? Well, technically you can make scrum work with the SAP software cycle but on certain areas it is nearly impossible. Also, their agile methodology is a joke.
• Code versioning and repositories are still from the 90s. Yes, there are efforts in order to use Git repositories with ABAP code such as abapGit but it still feels clunky.
• There are no built-in tool that you can use for creating easy test scenarios without loosing an insane amount of time, money and your mind in the process. Yes, there are some tools compatible in the market with SAP in order to perform some scripting but nothing already build in their products that you can easily use. Technically you can use Jenkins in ABAP for Continuous Integration and I said technically because I never saw it working.
• Similar to the last point, there is no way to automate certain process that require a lot of manual effort. Another example, I had to change the company address for 20 systems today and there is no way to automate it easily. Of course I can create a script on Ranorex that would do that but it will probably take me more time to build the script than to do the changes. I can also create a Python program that call a headless browser in order to introduce data via Web UI. The problem here is that there is no easy way and SAP doesn’t make things easier. There is also no way to automate other efforts because how they were designed.
• SAP is not compatible with certain technologies and God knows when they will make it compatible. Containers are everywhere now, do you know how many of their OnPrem products are compatible with container technologies as Docker or Kubernetes? By compatible I mean verified and allowed for production use… Let me give you an example, 2496083 – Support for Docker (Software Container Platform) SAP BusinessObjects Business Intelligence Platform describes SAP support for BOBJ on docker. Here is what they said:

SAP has no knowledge about Docker and regards it as virtualization.
SAP Support does not recommend this sort of deployment outside of test lab scenarios.

SAP, 21st century company

• Same for automated scalability on certain products. There is no way your system can automatically scale up or out without manual intervention on a lot of their products. Adding new app servers to your external facing portal automatically during a surge? No way.

I can keep going for days but I don’t have time, I think you already have an idea of the current picture of the SAP world when coming to DevOps or IaC. It is slowly changing and there are certain applications you can use such as Azure DevOps in order to integrate them with your SAP products and created pipelines for your process. The problem is that SAP is still lightyears away from other products in the market and they are not getting any closer. Their newer applications that work on PaaS and SaaS model have certain capabilities already build that allow to use pipelines and certain automation but there is nothing similar for the rest of their software, specially OnPrem software.

We are doomed!

Well fortunately there is still a lot of things we can do, it is not the end of the world. DevOps is just a movement or a methodology and we can still work on a similar way. It will be harder, it will take more time and more effort but it is still possible to follow a kind-of DevOps methodology for supporting SAP systems. As for Infrastructure as Code, luckily for the Basis folks there is still tons of things we can do with products as Ansible, Puppet, Jenkins, GitHub, Terraform, etc. that will make our life easier. Remember, the idea is to manage our systems as a factory instead of doing the same tasks over and over manually. Few examples I can give you:

• You can apply patches and perform O/S upgrades using Ansible for all your SAP boxes.
• You can upgrade the kernel of your SAP systems using Ansible.
• You can use Terraform in order to build your infrastructure, deploy new boxes, maintain the existing ones, decommission no longer used boxes, etc.
• You can perform HANA upgrades, installation, configuration, etc. with tools as Ansible, Bash/Python code, etc.
• You can start/stop/restart systems using LAMA, Ansible, scripting, etc.
• You can use tools such as Puppet and Ansible in order to enforce certain configurations on a O/S level.
• You can install and do basic configuration of (A)SCS and App Servers across your whole landscape with Ansible.
• You can keep changes and versioning of the scripts you develop in Git repositories. You can use Ansible in order to deploy those changes across the whole landscape. Or even use Puppet in order to enforce the same version across the whole landscape.
• You can use Jenkins for basic functionality testing after deploying certain changes. Or you can use scripting tools for basic functionality testing

Those are a few examples of what we can do following IaC principles in your SAP landscape. In the following months I will extend some of those ideas and provide more details with code and steps for implementation.