The first thing you need to know about DevOps is that it is a portmanteau. A joining together of the two words—developers and operations—DevOps is also meant to signify a new coming together of these two workplace disciplines given that they are roles that are sometimes argued to be at odds with each other.
The second thing you need to know about DevOps is that it is not a discrete service or packaged product of any kind. Instead, DevOps might be more accurately described as an amalgamation of cultural philosophies, working practices, and the technology tools designed to make software application development a) more Agile and b) less painful.
DevOps Love Factor
As a movement in its own right, DevOps has arisen because of an age-old problem. Developers supposedly think the operations function is there merely to serve their needs and provide a living environment for the code they produce. Equally, the operations teams with its database administrators (DBAs), systems administrators (sysadmins), testing professionals, and other core support staff think that developers regard them as some lower order of human being.
This lack of love has given rise to the expression: throw the application over the wall. When the developers are done with the code as far as they are concerned, they throw it over to operations.
Continuous Development Has Happened, All Over
But that time of wall-throwing carelessness has now passed and this is largely because the Internet happened. Applications and data services are now continuously online, continuously updated, continuously integrated, and continuously deployed. There’s no point in throwing anything over the wall; both teams now have to live in one open DevOps space without the old silo mentality.
This stark reality leads us to a new DevOps toolchain where all teams look to plan, create, verify, and validate, pre-production test, configure, release, and continuously monitor the technology being created. As well as an increased use of automation, good DevOps is argued to be characterized by small but frequent updates (once again this is Agile with a capital A) where many applications are broken out into defined microservices. This way, DevOps tools can enjoy a more modular and granular level of care and everybody (including the users) cans start to feel the love.
A Practical Guide to DevOps for SAP
Despite a certain level of hype, DevOps has really made an impact and is widely argued to be here to stay. Small wonder then that SAP has now worked with Basis Technologies to produce "A practical guide to DevOps for SAP" as a 22-page whitepaper that is free to download here.
For those interested in a practical guide to the practical guide, ASUG has distilled and deconstructed the thought leadership in this white paper.
Probably the biggest admission SAP has made here is to say that without DevOps in place, deploying even small changes to increasingly complex SAP systems will take a huge amount of time. This is due to outdated development-and-test processes, long release cycles, and stability risks.
SAP is of course a business applications company. We also see the company willing to integrate business users into the process of DevOps itself. Without DevOps we experience messy realities such as the use of basic spreadsheets to manage SAP transports (a package used to transfer data from one SAP installation to another). We also experience manual regression testing and a general lack of understanding between application and code dependencies, all of which are ultimately linked to user requirements. It is, obviously, a bad place to be.
DevOps in SAP on the other hand seeks to get all teams (developers, operations, the business function, and all other related stakeholders) to perform what has been called a “Shift Left.” This suggests repositioning our whole stance when it comes to building software so that we can build quality into all applications from the very start.
A Continuous Software Lifecycle, With a Caveat
As this previously mentioned continuous model now governs our approach to software and DevOps drives the power behind the continuous software lifecycle, can we get to a point where things move almost too fast? No, says SAP, “It’s important to understand that continuous delivery doesn’t mean that every change is deployed to production as soon as possible. It means that every change is proven to be deployable at any time as needed.”
As DevOps now starts to affect the SAP development lifecycle, the company reminds us that DevOps will mean different things to different people. But whatever department a person sits within, they will inevitably start to feel the positive affect of the automation that drives much of DevOps.
But SAP warns while DevOps concepts are universal, common automation tools, they are not suitable for use in SAP environments because of its specific architecture. This is why the company has worked with the DevOps toolset from Basis Technologies.
There’s a lot to digest here, but in brief we can summarize some of the other aspects of DevOps covered in this offering. SAP spends a lot of time talking about how objects and code dependencies need to be locked down (or very carefully tracked), as complex SAP systems may be configured differently in separate world regions. A lot of DevOps concentrates on change activity and breaking down siloed barriers so that everybody knows what is happening. Peer reviews are fundamental to this process, together with planning and retrospective meetings.
An SAP Mantra: Stability Is King
SAP wants ASUG members to think about DevOps and start thinking about implementing some of all of the approach detailed here. But, at the same time, SAP does not want you to a) break your current systems or b) start to implement new DevOps-centric working practices and automation controls without first fully assessing their effects on production.
“Stability is king,” has long been an unofficial mantra in many SAP environments. “DevOps can maintain required system stability while providing the means to delivery change far more often,” the white paper states.
The end result of embracing SAP DevOps is intended to create a positive human impact. As flaky as this may sound, we do know that DevOps originated from two divisional silos and their inability to work with each other effectively. The concepts presented here are better for developers, better for operations, and better for all other people at every stage of the development lifecycle. In DevOps we see that everyone takes responsibility for their part of total IT system health, from the users backwards and upwards through the IT stack.
The end result of successful DevOps is less downtime, faster software delivery mechanisms, and a significant reduction in workload effort for everybody with process automation now doing the heavy lifting and repetitive task management where it can. As the waterfall method of development is drying up and the new era of continuous development is upon us, DevOps can steer us down this new channel.