1. So, what exactly is Docker? Is it different than a container?
If you've heard of containers, chances are it's a Docker container. Docker is a company that offers an open-source platform that allows you to package (i.e., containerize) applications by including everything needed to run them. The containers use the OCI Standard that is supported by other companies. Containerizing applications enables development teams to benefit from portability, agility, and control of those applications. In our case, we package SAP to run in a container.
2. I still don't get it. Isn't this just a VM?
While there are some functional similarities between containerization (Docker) and virtualization (VMs), they're different technologies. Containers do not have an OS within them. Instead, they share the kernel of the host OS. This architecture makes containers more lightweight than a VM, allowing multiple containers to run on the same host. Containerization also provides isolation, so applications are entirely separated from each other. Isolation is a good thing, and I'll explain why in the next section.
Containers make it possible to give individual developers, or product teams access to their own SAP system. You can think of them as sandbox systems that only need to run when required.
3. Is this really necessary? What are the business and technology benefits to containers?
I'll start this section with a question to save us all time. Do you view technology as a competitive advantage in the market? If not, thanks for reading, carry on with the status quo. Alternatively, containers are necessary if you think technology plays a vital role in staying ahead of the competition.
I believe in the idea that "every company is a tech company." And competition is more ambitious than ever. Your competitive position in the market depends on your speed, so you have to code AND ship faster. For complex, monolithic systems, it's common for code (think SAP transports) to take weeks or months to make it to production. At its core, this is what the DevOps movement has tried to address for nearly a decade now!
Containers offer a new path to "DevOps" by leveraging an increased speed of monolithic deployment to ship code faster. For example, most development systems have little to no data. If you're coding a tightly integrated SAP object such as a user exit or an enhancement, you'll likely need to move the code to your SAP Test system to validate your change. A developer would probably have to do this multiple times in a real-world scenario, significantly slowing down the development cycle. This scenario also assumes your SAP Test system has high-quality data. Many companies use the SAP Test system for testing, training, and (indirectly) development! If you have more than a few developers/users doing this, your SAP Test system is not accurately representing production (SAP Prod). You'll likely run into situations where the code "works" in SAP Test but not SAP Prod. Instead of shipping, you spend time debugging to find the differences or creating data to reflect production accurately. Time well-spent (sarcasm)! 😞
On the other hand, if you're using containers, you have an up-to-date system with recent data that allows your developers to code and test in the same system. Containers avoid the need for wasting time pushing transports and polluting your SAP Test system. If something doesn't work, you can "refresh" the container (the process takes a few minutes) and start over instead of having to back out the code that you had implemented and transported to SAP Test. (You back out unused code, right?) This isolation keeps your central landscape (i.e., Dev, Test, Prod) clean.
Also, if you're using CI/CD when your test automation workflow kicks in, it can spin up a new container to test the code. Again, without disrupting your central landscape.
4. This sounds too good to be true. Is it practical and cost-effective to implement?
It wasn't an easy task, but our results have been remarkable. We can start and stop containers on-demand. Our developers have their own SAP container system with data, and we have implemented actual CI/CD. Because containers are less resource-intense, they are far more affordable to run than traditional systems. So yes, it's practical and affordable.
5. How do I get started?
The interest in this topic seems to continue growing, and the SAP DevOps community is a great place to learn more.
Below are some excellent resources related to this topic.
