ABAP Development in a Cloudy World

[GrahamRobbo]

TLDR; Developers want to choose their own tools.

Interest and enthusiasm for the SAP Cloud Platform ABAP Environment (aPaaS) is building as we move through the SAP TechEd season.



aPaaS was announced at SAP TechEd last year. It became Generally Available (GA) in early September this year. GA was formally announced by bernd.leukert at SAP TechEd Las Vegas. SAP Mentor yojibee  provided the big finish to bjoern.goerke's Barcelona keynote with a demo of ABAP development on aPaaS.



And at both SAP TechEd's aPaaS tutorials topped the leaderboard in the Developers' Garage.



*Source: https://twitter.com/ThFiedler/status/1055546782007115776

It is very early days. aPaaS is starting with just a small "whitelist" of language elements and features available to the aPaaS developer. This list will be built out and extended over time - in great part by listening to feedback from developers themselves.

SAP will also need to convince customers that the Total Cost of Ownership (TCO) of aPaaS can stack up against other offerings. At the moment an aPaaS instance is pretty big. If you consider you would need a development instance and a production instance (and maybe others as well) it's a significant cost just to provision and run your landscape. SAP are aware of this and are working on it. I hope and expect we will see them shrink the system requirements for an aPaaS instance as they "cloudify" it more.

However this desire to cut back on aPaaS requirements dovetails in nicely with another bias I have as a developer - namely to choose my own developer tools and techniques. And there is plenty of research to suggest this bias can deliver real benefits. Just to pick up one quote from the 2017 State of DevOps Report ...

“We discovered that teams that can decide which tools they use do better at continuous delivery. This is in contrast to teams that can use only those tools that are mandated by a central group. Teams that can choose their own tools are able to make these choices based on how they work, and the tasks they need to perform. No one knows better than practitioners what they need to be effective, so it’s not surprising that practitioner tool choice helps to drive better outcomes.”

Let's think for a second about how this aPaaS thing is related to the on-premise ABAP stack we know so well. aPaaS has been described as a subset of on-prem ABAP. It is the same codebase but with a "whitelist" concept to ensure both the design and runtime can only make use of a fixed subset of language features and SAP-delivered artefacts.

So, as a developer who wants to choose my own tools, I would like to be able to download my developer edition of the ABAP stack (as I do now), build and test my ABAP code here, then deploy it to either an on-prem ABAP landscape or to an aPaaS instance. If aPaaS is the same code base as ABAP on-prem then why shouldn't I be able to do that?

I envisage a switch that could be set on an ABAP package to indicate "aPaaS Compatible". Artifacts in a package with this switch enabled would have to conform to the aPaaS whitelist and language rules.

I would then be free to choose what tools I wanted to use. I could use the ABAP workbench if I prefered that to the Eclipse-based ABAP Developer Tools. Or I could build my own if I wanted to. It wouldn't matter because aPaaS just becomes another deployment option for my code.



*Source: https://github.com/marcellourbani/vscode_abap_remote_fs

It could also mean I no longer needed to provision an aPaaS development instance, or any other aPaaS instances except for my production instance. I could incorporate my aPaaS instance into my on-premise transport path(s) for software logistics, or I could use something like abapGit, or maybe a combination of both.

The obvious benefit is that the TCO story for aPaaS becomes much more palatable. It also makes that pesky aPaaS trial system available for all ABAP developers right now. I get to choose the tools and techniques that suit me during the development and testing processes. I deploy where I want to.

And finally, SAP customers can start building side-by-side extensions to their on-prem ECC or S/4 systems using the latest ABAP stack and techniques - such as RAP - right now safe in the knowledge they can easily move them to aPaaS when they are ready to do so.

I like it.