DevOps as a concept is not new
DevOps describes a set of processes, tools and operational objectives for delivering changes to software or applications in an established running environment so as to increase an organization’s ability to deliver new or improved applications and services at speed.
The advantages of a DevOps approach are many, such as: increased agility, the separation of concerns, and better overall management. Just as important, this approach results in a solution that is more inclusive to a wider range of contributors.
For many years now, a DevOps approach has been touted as the ideal for the deployment and operation of SAP environments. The idea is to take advantage of modern delivery and operating approaches to release additional value from the investment that customers have made in their SAP estate and licenses.
DevOps for SAP
For many years, SAP systems had a reputation of being difficult and complicated to change — the result of which is less value for the customer. The DevOps movement and its application to SAP is an approach or a set of ideas designed to remove some of the traditional barriers so customers can release that value.
There are many things that stand in the way of fully releasing additional value from an SAP environment through DevOps practices. Some of these relate to the fact that the current versions of SAP are not particularly natively DevOps compatible. As an example, think about the transport routes between development systems and production systems. These are often designed around an older more mature waterfall-based gated delivery mechanism into the live or running environment.
These pipelines from a DevOps standpoint would be described as single track, meaning any changes or code that is being created and tested effectively blocks other code from moving through the system. Many customers try to alleviate this by using combinations of what DevOps would describe as branching strategies. For example, parallel tracks for large wave-based releases alongside a rapid BAU support track that is used to address critical live system defects.
The issues with this approach are: 1. the complexity that arises when you need to bring all the changes back together and 2. the challenge of running large and often expensive test and development stacks for weeks or months at a time– sometimes on limited hardware. A traditional non-Cloud-based hosting environment is one example of this.
The Advantages of Hyperscale Public Cloud
The DevOps movement is synonymous with the recent expansion of public Cloud computing. This is particularly evident in modern services that have been architected from the ground up to take advantage of the agility and cost-saving provided by a hyperscale Cloud. One of the solutions, or a part of the solution to DevOps for SAP, can be the public Cloud and the near-infinite capacity of computer hardware.
Not only is there an effective infinite capacity of available compute, it’s also relatively cheap and usually paid for on a metered basis. What this means in practice is that with a correctly orchestrated SAP environment, it is possible to do things like launch systems with very short test windows. The cost of those systems is only levied to the customer when they’re actually running. There are two advantages to this approach. The first is that you are able to can create as many test systems as you need to support parallel delivery pipelines to your production or live environment. The second is, if you realize the functionality that is being developed or delivered through those test environments is of little or no value, you simply delete them and remove the cost. This approach is much more agile than a traditional data center re-based testing regime that often requires external service providers to invest many hours copying back systems already in test environments for what could amount to a very short test cycle.
Because the cost of performing the tests is directly proportional to how long the tests take to execute, it’s very easy to allow parallel build teams to form and deliver functionality independently of each other. The issue this creates, of course, is how you consolidate everything into the final SAP production environment. SAP themselves have tools for this, as do several third-party vendors, who have worked for years on transport management technologies. Combining the management of transports with a meaningful and ideally computer-based testing regimen truly unlocks the DevOps vision for SAP customers.
Assuming the chosen path is to move SAP to the Cloud and the desire is to release agility and minimize cost (and therefore maximize value) all that remains is finding an effective way of managing the resources that will be provisioned into the public Cloud. A practical example of this is the creation of a temporary test system.
Temporary Test Systems
The traditional approach would entail having a service request raised which would then need to be approved. Resource allocation would take place, a plan would be made and a test client would be created inside the available hardware of the hosting environment for the SAP landscape. Not only is this approach resource-heavy from a technical standpoint, but there are also several overheads involved in managing the request, doing the capacity and resource planning, and whatever other activities are needed to turn the desire for a test system into a working reality.
The ideal approach is that the service or development team that came up with an idea they would like to test would be able to by themselves using a self-service portal, request that a test environment be built without involving long meetings or delays based on available hardware. Because the cost would be minimal, approvals are often no longer required and, because the building of the system is automated, there’s usually no resource plan required either.
The result of this is that the service development team is fully able to perform small agile tests and, once they determine that the new functionality adds value and isn’t going to break anything that’s already in the live environment, they can simply release it to live. This allows the users to immediately take advantage of new developments and release additional value for the owner of the SAP licenses. As soon as the test environment is no longer needed, it can simply be decommissioned using automation once again.
With the combination of a modern Cloud management SAP-aware solution (on the scale and flexibility of what is currently available through hyperscale Cloud offerings) mixed with a transport management and testing approach, SAP customers can finally move towards a world in which they can fully realize the advantages of the DevOps movement.
