Why we use IaC for SAP S/4HANA
During our most recent Experts’ Forum, our Head of Engineering, Dr Ben Moss, walked us through a customer project where Centiq delivered an automation framework to enable the build of S/4HANA on Azure. We all agreed in the value of automation of the Azure infrastructure (stuff that you would otherwise configure in the Azure portal), the OS and cluster configuration (RedHat in this example), but were struggling to see the value in deploying the S/4HANA and Netweaver platform on top. The perception is that in an SAP product lifecycle, the SAP product “Install” process, typically happens only once every five years – so why would you bother automating it? Hold that question while we talk about CMDB and IaC.
According to wikipedia a Configuration Management Database (CMDB) is
“an ITIL database used by an organization to store information about hardware and software assets (commonly referred to as Configuration Items [CI]). This database acts as a data warehouse for the organization and also stores information regarding the relationships among its assets. The CMDB provides a means of understanding the organization’s critical assets and their relationships, such as information systems, upstream sources or dependencies of assets, and the downstream targets of assets”.
This concept is a valiant attempt to bring some structure into IT documentation, to help with the ongoing support of IT systems. But in my experience, it is often an ambition that never quite delivers. Always incomplete and often out of date, the CMDB creates bottlenecks in the release cycle as changes go through a slow Change Advisory Board (CAB) process in order to validate against and update the CMDB. Any CMDB is better than no CMDB, but I think it is time to improve on this idea with something a bit more dynamic (and I don’t mean a discovery tool!).
Introducing Infrastructure as Code (IaC)
Define, build and run your IT systems with code, then every configuration item (CI) every tunable, every configurable, every design decision is captured in code. Or you can find some form of configuration file, version controlled and audited in a tool like git and backed with a service like GitHub. If there's a problem associated with configuration, can you see when it last changed, as well as differences between versions? Can you rebuild from code and get the same result over and over? And what about the CAB? Can you run through the change and backout multiple times using IaC automation before the production release, implement automated tests to check the before state and the expected end state of ALL known dependent systems as the change is processed? Can you share the results with the CAB, and does that improve the success of changes? Should the CAB spot dependencies of a change? Should they not be built into the system as tests?
The better we get at IaC and the more testing we build into the system means less work for the CAB, and less need for a CMDB.
Why automate deploying the S/4HANA and Netweaver platform?
Well, think about the configuration that is captured as part of that process. Much of the complexity associated with clustering or application to database tier relationships starts at the point at which you do the installation. It is often the basic stuff that trips you up later in the life cycle – e.g. DNS names in use, service addresses, file system locations. We estimate that when an S/4HANA system is built manually, you make in the region of 2,000 different decisions and interactions – many of them relate to hundreds of configuration items. When you build out the entire landscape, that number of steps looks more like 50,000, which might equate to a thousand different configuration items.
Assisted by automation, we capture them all in code. Do you store all that configuration and information on dependencies in the CMDB? I doubt it. Does it keep a history of previous settings? Does it cope with a dynamic scale out of your on-demand cloud-based app tier? Does your discovery tool capture the relationship between cluster nodes and the app and DB servers? (If it does, then it’s almost certainly to be manually entered data, prone to human error!).
So if we hardly ever “Install from SAP media” again, when does this pay off?
Think about a few key operational processes that cause you pain and might benefit from runbook automation:
- Recovering from High Availability (HA) cluster failover
- Invoking Disaster Recovery (DR)
- Recovering from a DR invocation
If you already have the key information that defines a clustered HA pair with tests that understand the cluster state in code, it will be easy to code the process to recover from an HA fail over. Again, DR process automation becomes an easy addition when you already have the build and tests defined in code. The need for CMDB “discovery” tools only exists because the information was not captured at source.
With all of that troublesome SAP system configuration defined in code in a version control system, we can regularly test that what has been installed reflects what we have in the codebase. This will ensure changes to the configuration are noticed and either rolled back or adjusted.
IaC is keeping the CMDB alive
With this level of governance, who needs a CMDB? Well, I have to admit that having a friendly view of the IT estate is going to be useful for many of today’s operational challenges. So I concede that the CMDB is not quite dead, but only because the IaC automated workflows will keep it breathing for a few more years.
Read more about IaC, SAP and IT in our blog.