It can be hard to try new things in SAP, and one reason for that is that teams often work in shared development and QA environments with a common code base.

Sometimes there’s a sandbox. Sometimes there might be an N+1 or N+2 path available for project work. But generally everyone has to operate in the same place, at the same time, taking care to make sure they don’t smash other people’s work in the process. In a time when customer responsiveness and business agility are hot topics, that’s not a very flexible approach.

There are a couple of main reasons behind it. First, each ‘box’ was traditionally exactly that – physical hardware which could not be replicated quickly, easily or cheaply. Second, connecting those disparate systems wasn’t straightforward even if you did have the resources to run them.

Tools like ActiveControl have taken care of the latter point with functions like overtake and regression analysis, automated movement of transports, automatic code merge, customisable transport paths, and so on. But the former problem remains: if you want to run agile teams for SAP development, how can you provide appropriate environments that allow them to work autonomously without constant conflict?

Some organisations already see agile development as a significant enough step to have ‘brute forced’ the problem by providing multiple ‘old-fashioned’ dev boxes to their teams (one Basis Technologies customer did this for an N+10 setup!). That’s not practical for most though.

Admittedly this is an area where cloud hosting has helped a lot. Platforms like AWS provide a far greater degree of scalability and elasticity than has been the case in the past, but a reasonably significant amount of effort is still required to provision a new system. It certainly can’t be done by a developer at the push of a button, as is often the case outside of SAP. But now a (relatively) new technology is available that can make things even easier: containers.

What is a container?

In short, a container is designed as a way to ensure that software can be migrated between different hardware or environments – or even virtual machines – without worrying about whether the differences between them will prevent the software from working correctly – or more precisely, from working consistently. 

To that end a container contains everything that a software application needs in order to run, like libraries, binaries and config files. Docker, one of the companies that helped to pioneer container technology, puts it like this: ‘A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.’

The analogy often made is that software containers are like the standard shipping containers used to move goods all over the world. It doesn’t matter what is in them – they fit on the same boat, can be picked up by the same crane and transferred to the same truck or train without any ‘compatibility’ issues.

Why use containers?

For many, the infrastructure-independent nature of containers is a good enough reason for them to be used. But aside from consistent performance and the ability to run anywhere easily (including on different operating systems, on VMs, on bare metal servers, on premise, in the cloud…), containers also offer other benefits.

Standardized: containers themselves are standardized (though many different container management tools exist) thanks in large part to the Open Container Initiative, which provides a governance structure for creation of open container standards and is backed by many of the tech world’s big hitters. What’s more, each container can be created from a templated ‘image’, so it’s easy to make sure every one is configured in the same way.

Isolated: Applications running in containers are isolated from one another and don’t run directly on the host operating system (OS), providing an extra layer of security and allowing you to manage resources more effectively by setting explicit limits for each.

Lightweight: Since containers don’t need their own OS, instead sharing the host machine OS system kernel, they are typically small in size and consume a commensurately limited amount of system resources. That means you can either run more applications in the same hardware, or reduce your server and licensing costs. 

Support modern development: The portability, lightweight design and templated nature of containers means that they can be ‘spun up’ and disposed of extremely quickly and easily – ideal for modern development approaches like agile and DevOps where distributed teams may be working on unconnected developments that are deployed frequently, in small increments. 

Modular and efficient: The ability to run a single application of just about any size in a single container makes them ideal for a modular approach to software development that enables more efficient use of physical system resources. Better still, they’re ideally suited to a microservices architecture, where a monolithic application is broken down into a suite of many small services. 

Containers vs Virtual Machines

If containers are the new kid on the ‘don’t need dedicated hardware’ block, virtual machines (VMs) have been around it a few times. And while containers do have many benefits, it is fair to say that both they and VMs have some pros and cons. So what’s the difference between the two?

Well, fundamentally it’s that each VM needs its own OS, whereas a container doesn’t. So VMs can use a lot more system resources and are certainly more unwieldy to configure. Google uses this diagram to explain:

SAP in containers

That’s all very interesting, but how does this apply to the world of SAP? Why should we be interested in containers?

It’s true to say that running containerized SAP applications is a pretty new idea for most people. After all, if we’re talking about ECC or S/4 it’s unlikely to be a small system, and the nature of SAP means that it can’t easily be broken down.

But from the investigation we’ve done internally at Basis Technologies and conversations we’ve had with our more advanced customers, it’s clear that containers already have the potential to provide advantages to development of even the most monolithic of SAP applications.

Size and speed of deployment: OK, so you’re not going to be able to reduce the size of your SAP database but running in a container means you don’t need to bring much else with you. Since there’s no OS in the containers, each system is much smaller and easier to create. At Basis Technologies we are able to spin up in a matter of minutes an operational containerized dev system which only uses about 40GB of disk space.

Agile development: As mentioned above, containers are ideal for agile development, which is an approach that more and more SAP teams are adopting. They accommodate dynamic sizing of dev teams across multiple sprints by ensuring that new systems can easily be created or decommissioned according to the size, volume and interrelatedness of the user stories in work.

Flexible QA: Perhaps you don’t need multiple dev systems. Or you’ve got enough, and the ability to quickly add more isn’t going to help you much. There’s still every chance that a more flexible QA process would add value. SAP teams we speak to commonly complain that the inability to test quickly in a QA system is a real bottleneck for developers. But what if a new QA system – based on an ‘ideal’ image – could simply be spun up on-demand to augment your standard QA box? One of our customers is doing just that in an agile environment to accelerate testing and increase software quality. 

Distributed development: Even more radical than agile – which, let’s be honest, isn’t all that new – is the idea of distributed development using abapGit. It would take too long to explain in detail here – check out this blog if you’re interested – but the basic idea is that every developer works independently on their own version of the SAP source code, and is able to access any previous version, at any time. But that means they each need their own SAP environment to work in. Containers provide an ideal way to provision those systems quickly and easily. 

Shiny new things

At Basis Technologies we work with SAP users around the world to help them transform and manage SAP systems. That means we’re always on the lookout for new technology – like containers – that can increase SAP agility, speed and efficiency. If you’d like to know more about how our DevOps and test automation software can help to change the way you run SAP, get in touch.