
<div className="feature-list shadow-xl">
    <div>
        <p>
            $ ./create_vm_instance.sh vm-1217 <br />
            $ docker-compose up
        </p>
    </div>
</div>

The first time I installed SAP, I failed at it. I had been trying for about three months before giving up. It seemed impossible.

A few years later, a more tenacious team member got as far as starting the installation via SWPM, but it failed due to system requirements. He shared everything he had learned with me, and I set out to try again.

I worked on my next attempt for about one month before seeing that wonderful screen load.

<img src="/images/blog/devops/sap.png" alt="SAP GUI login screen" />

After that, I kept running through the installation process and iterating on it, learning a ton along the way, including that SAP offers a method to perform an unattended installation. I got to the point where I could install SAP ERP in about one day.

<br />
<b>One day was not fast enough.</b>

Modern DevOps relies on spinning up a server in minutes to run automated tests and ensure the code is safe to move to production. We needed a better way.

<br />
<i>This article is a follow-up to [A Practical Guide to DevOps for SAP ERP](/blog/practical-guide-to-devops-for-sap)</i>

One of the advantages of working on a cross-disciplinary team is that you’re not bound by the old way of doing things and instead can share better ways of accomplishing a task. Our team includes non-SAP developers who had no idea of the existing limitations and underestimated the task’s difficulty. This turned out to be a great thing.

## Infrastructure as Code (IaC)
Today we can prepare a machine to run SAP in about 2 minutes by running one command.

<div className="feature-list shadow-xl">
    <div>
        <p>
            $ ./create_vm_instance.sh vm-1217 <br />
        </p>
    </div>
</div>
A lot is happening here. This command makes a call to a hyperscaler to create a virtual machine with the proper system requirements to run SAP ECC in a container. Once the VM is provisioned, it installs all dependencies required, including Docker, docker-compose, npm, VPN, nano, configures hostnames, and more.

<div className="feature-list shadow-xl">
    <div>
        <p>
            $ docker-compose up
        </p>
    </div>
</div>

The second command is also dense. If you’re not familiar with Docker, it uses images as a type of snapshot to run nearly any application. In our case, it downloads an image of an SAP system that runs on Docker. It contains production-quality data and points to virtualized or non-production interfaces. Creating the image is no easy task, and it requires a significant understanding of containers and SAP to complete an installation that works in a container environment. Once the container is created, it can be reused as many times as you want from that point on. For example, you can load it with three years or one month of data from a production environment. The command above triggers the image’s initial download and extraction, which is the slowest part of the process to provision a new VM with SAP. The process takes around 30 minutes (depending on the system size). The next step is to start a container from this image, and this takes about 3 minutes which is the time for SAP to start.

The VM’s we found work for our system are 4 vCPU, 32768 RAM (MiB), and 500 GB SSD. We use technologies compatible with any hyperscaler, such as AWS, GCP, or Azure.

## Automate Everything
Now that your infrastructure can be deployed with code, the possibilities are endless.

You can integrate IaC with a nice frontend. The frontend allows employees or contractors to access a self-service portal to provision VM’s and start, stop, and delete containers. You can set limits on their access (e.g., number of VMs, what images they can download, etc. ) through configuration and create a dashboard to manage resources. Development of this self-service portal goes through a CI/CD pipeline, of course!

<br />
<img src="/images/blog/devops/iac_neo.png" alt="Neo: I can deploy a system with twho lines of code?" />

Another possibility is to manage your IaC in your CI/CD pipeline. Since it’s code, you can test like you usually do with your pipelines. Part of this is possible because of the use of artifacts. In the context of IaC, artifacts are your Docker images or VM images. If you make code changes to your infrastructure, such as reducing your VM’s disk space and RAM, you can test your artifacts deploy correctly after the changes. Even though the test process is long, it’s scalable and automated, so it’s worthwhile to do.

<br /><b><u>Practical Example</u></b><br />
I want to test 5 different variations of the RAM and disk space. I create five branches and assign the different test values to each, then run automated testing. I can check back later that day to see which variations had errors. If any of them were successful, I conclude that SAP runs without issues on a more affordable machine. I can then submit a PR for the branch that worked. The next time the command to provision a VM is executed, it uses the latest code (i.e., with the more affordable machine). This test took about 15 minutes of my time and a few hours of machine test time. If you use infrastructure as code, you can test that infrastructure as code!

<br /><br />
<img src="/images/blog/devops/whoa.png" alt="Neo: Whoa" />

## Change Management
For most people using a solution like this, the changes are reasonably transparent. They still connect to SAP in the same way as before and only need to learn how to click a few buttons to manage their SAP system.

Developers have a bit more upskilling to do but nothing unreasonable. They need to learn the basics of GitHub or whatever git tool you use. They also need to become more familiar with unit tests and implement an adequate test suite.

## Security
Access control is still restricted, and traffic goes through a VPN. Production data can be sensitive, so the copy should include synthetic data or data obfuscation. These tools maintain the integrity of the data while creating completely fake records.

## Looking to the Future
<img src="/images/blog/devops/future.png" alt="Looking to the future" />

There are still some unknowns with this approach, but one thing is for sure, enterprise technology has fallen behind. I understand that some challenges are more nuanced, but software development is decades ahead of where we currently are with ERP systems.

Projects should not take years.

Code freezes belong with floppy disks.

Repetitive tasks are best left to the machines.

Deploying code to production should take hours and be nearly risk-free.

Enterprise IT modernization isn’t happening overnight, but companies need to get serious about it or risk becoming obsolete. I hope sharing our experience provides some value to others and helps move us forward.

If you enjoyed this post sign up for our newsletter where we'll continue sharing our journey with DevOps.

## Credits
> Photo by [Drew Beamer](https://unsplash.com/photos/xU5Mqq0Chck) on [Unsplash](https://unsplash.com/)

Originally posted on the SAP Community Blog
[Infrastructure as Code, DevOps, and the Future of Enterprise](https://blogs.sap.com/2021/12/17/infrastructure-as-code-devops-and-the-future-of-enterprise/)<br />


Applying modern development methods to legacy ERP

Modern DevOps relies on spinning up a server in minutes to run automated tests and ensure the code is safe to move to production.

Infrastructure as code, DevOps, and the future of enterprise

Related posts

Agile: Where we started

Infrastructure as code, DevOps, and the future of enterprise

A practical guide to DevOps for SAP ERP