SAP Deployment Automation

Project Goals

This project aimed to take an existing SAP deployment and migrate it to a fresh environment to remove some of the ongoing issues. The previous installation had the following issues:

• Any maintenance or minor failures would require downtime of the entire system.
• Recovery from backups was a complex process that could only be accomplished ny one person.
• There was no way to test things on a non-production system.

Project Deliverables

To remedy this, I worked with another cloud engineer to:

• Break out parts of the workload into smaller VMs
• Setup separate environments with sufficient networking support to be able to test SAP/HANA with an alternate Active Driectory infrastructure so that we could test new configurations from the ground up.
• Create all installations via Terraform.
• Configure all Windows instances to automatically load and configure required software on creation.
• Configure Linux instances to use cloud-init to configure themselves, and load the latest backup for initialization.
• Script the creation and restore of the main HANA database.

My team created a full Terraform deployment that met all the above goals and could deploy a new system in about an hour.

Chalenges Encountered

The main challenges for this were that, like most most Windows applications, it is expected that these would be deployed manually. As such, there was very limited information on how to automate the deployment from the vendor, or the vendor’s consultants. As such, we had to do everything using only the normal processes for automating MSI installs, and occasionally doing registry imports to complete an installation.

Since some of the applications were on the older side, we ran into a variety of issues with compatibility. As an example, the version of Suse that was required was very much out of support, requiring some hardening to protect against some potential security issues, and a fairly large amount of effort to get some utilities installed. For example, jq, which was used to decode JSON data from AWS’s Secrets Manager, was not available for that version of Suse. This required back-porting jq from a newer edition’s packages. This was not difficult, but did consume more time than anticipated.

Project Outcomes

The project worked as expected with all the deployments working. The system was handed off to the incumbant IT team for management through documentation and several knowledge transfer meetings.

Key Takeaways

• “Everything is the product of its environment” - SAP is designed to have bespoke (perhaps artisanal, even) installations and automation is not their focus on the installers. However, installing software is a repeatable process for the vast majority of cases and most issues can be overcome with time and understanding the processes used in performing the installs.
• Legacy software has many challenges that may impact schedules, or the threat model, and these require a fair amoutn of up-front research to factor preperly into the project plan.