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.

[ChrisPaine]

"If aPaaS (sic) is the same code base as ABAP on-prem then why shouldn’t I be able to do that?"

But we know that Steampunk isn't a subset of on-Prem ABAP! it supports things like the restful programming model that hasn't been back-ported to onPrem. And because it's cloud based, it's going to iterate and get ahead on onPrem constantly, if you want the cool stuff - that's cloud based. Sorry Graham, get with the times! The inability to deliver supportable innovation in self patched development and runtime environments is what has lead to cloud based development. If you want the latest greatest and always updated solution, you go for a cloud delivery. (Possibly with containerisation, private cloud can also be done, but it's definitely an overhead - latest/greatest not guaranteed!)

In the future when the run-time and design-time of ABAP are split, then perhaps you can think about an easier way to enable a choice of tools. But Steampunk isn't there yet - it was a big push to get what we have now, but there will be iteration.

As Marcello Urbani is strongly hinting, there is the possibility to use tooling other than Eclipse - it will just take work - perhaps help out with that rather interesting open source project.

In the meantime - look at the cost (and it will have to be expense given the resources consumed! that can't really come down much more unless SAP can find a way to reduce the resources - again that split from deployed codebase, runtime and design-time) as I said to Fred Verheul as a function of what it would cost for an FTE. Because that's easily what you'd be paying to retrain all your ABAP team to new technology and migrate code into completely different languages.

Cloud is inevitable! If SAP had to choose where to invest to make Steampunk more accessible/useable then I'd probably want to prioritise getting the footprint down (reducing deployed content so that only required libraries are deployed in environment) rather that implementing code in onPrem to make it pretend to be Steampunk.

My thoughts....

Cheers,

Chris

[abdul_hakim]

Hi Graham,

Very good insight . The current offering of SCP ABAP needs to evolve in order to compete with cloud native programming languages. As this is just a beginning let us hope SAP will make SCP ABAP a cloud friendly development environment and also reduce the cost. More importantly free trail edition needs to be provided to the development community so that they gain knowledge and get their onprem investment into cloud.

Thanks

Hakim

 

[MikeDoyle]

ABAPExpress anyone?

I agree with the sentiments, Graham, but I think there are a few roadblocks.

First of all, lets say I run my local 7.60(?) system and I can check the “aPaaS Compatible” checkbox.  I stick within the whitelist.  After 3 months the whitelist on the Cloud Platform ABAP Environment is updated and now I can do a few more things there.  Yet my local stack is behind.  It has to be upgraded every 3 months to stay in sync.

Second, there is no way I would run prod ABAP code in the cloud if the dev and test boxes were on-prem.  It’s not a good enough test. Those environments are too different.

Third, and related, the ABAP environment has been designed to run on Cloud Platform, and uses those associated services (like destinations from the connectivity service).  It doesn’t make much sense to me to run without those services.  You would have to somehow link your on-prem system to a particular Cloud Platform account. 

Better I think to devote effort to shrinking the resource requirements of the ABAP environment a la HANA Express.  Give us a true CP ABAP Env. in mini-form, or give us a tenancy on a shared instance.

With regard to tooling, hopefully someone is working on providing alternatives for the Cloud Platform ABAP Env. already…..

[GrahamRobbo]

Settle. Not sure how you interpreted this post as some sort of anti-cloud push. From my point of view it was quite the opposite. ?

 

[GrahamRobbo]

Thanks for your contribution Mike.

A few quick thoughts in response.

There is no reason the whitelist has to be a static artifact inside the ABAP system. Perhaps it might be a service provided by ..... SAP Cloud Platform? ?

Software logistics, qa processes, etc. are different for every customer and every situation. That was sort of the point I was trying to make. Nothing is off the table.

Finally as a cloud convert (see previous response to @wombling) I absolutely think any ABAP system should be able to consume any service - including infrastructure services like destinations, identity management, etc.

Cheers

Graham Robbo

 

[ChrisPaine]

Having worked for many years with the local, "on-prem" if you like, version of Neo for local development - the Java Apache Tomcat based SDK that offers many of the functions of Neo, I'd agree with Mike, local development needs testing in the cloud - even with destinations available locally, they don't work the same way as the cloud.

Given that something as light weight as the Neo sdk which can be pushed onto individual developer machines can't really mimic a cloud deploy, I think it will be hard for on prem ABAP systems to be able to do same.

However, I do like the idea! certainly destinations is a much nicer way to manage connectivity than the current way we do it in SAP...

But I think for the moment, if I could point the Steampunk team in a direction, it would be on reducing the footprint of the solution rather than back-porting functionality.

Sorry Graham - didn't mean to be so grumpy 😉

 

 

 

 

[ChrisPaine]

no worries! Anything which encourages movement to the cloud is a good thing! 😄

 

[mmcisme1]

To comment or not to comment?  That is the question for today.  So of course, I'll comment. db8ac33b71d34a778adf273b064c4883 had a nice discussion on my blog.

Is it that we are moving to the cloud or are we moving to data transformation?  Could we in fact have the best of both worlds?  Put everything that we do routinely on the cloud and then our development on premise?  So have an on-prem and then cloud connector.

I have also read an interesting blog that sarhan.polatates3  wrote.  What if the speed of change is too fast for the changes in the business?  Can our business processes and users keep up.

Now on to the real comment about this blog.  Choosing your own tool. In a perfect world, I would get to choose my own language to program changes.  But even in the cloud if you make changes, then the developers at the business will have to make changes or <gasp> fixes.  I think you will still be limited by what can be supported.

I really like that ABAP is moving to the cloud.  It will be interesting to see if they are just calling it ABAP even though there are major changes to the syntax.  🙂

Note that the interesting tool I want to use is WEBIDE.  That is only available on the cloud.  To use it on-prem you have to have a cloud connector.  It does seem like all the new development is going towards on the cloud.

Color me doubtful at the moment as to is ABAP really ABAP.  I am also one of those on-premise people.  Dark thought. I think I may go hide in a dark hole with all the on-cloud information and not much on-prem info going on.

BTW - if we could support it there are quite a few languages I can use.  We are on-premise.  We do use Fiori.

Thank you for a blog that makes me think.  Thinking is good.

[MarcelloUrbani]

Thanks for the advertising!

It's still far from usable though

[hardyp180]

Dear Michelle,

You raise a very good point in your comment above ... can the business users keep up?

Now a lot of the push to the Cloud and virtually all of what i write about (Unit Testing / abapgit etc...) is dedicated to speeding up the process of change. The matra is we do not want quartely releases, we want daily releases, or a release every 3 minutes like you get with Amazon.

In my company in Australia we (IT department) do not use anything modern at all (agile, unit testing, anything cloudy) just bog standard SE80. Nonetheless for the last 18 years we have managed to push at a truly breathtaking number of changes every year  - improvements, new functonaliy and so on.

We were so produ of ourselves. And then one of the IT managers did a public relations exercise where he interviewed all the top managers and a random sample of end usesr to see what the business really want from IT.

The result came back and it was unambigious. It went along the lines of "it is OK for you to make MY change that I asked for, but not all the others. You are putting in far too many changes every week. The business just cannot keep up".

We did indeed have a weekly release cycle. And it seemed the end users could not absorb the sheer rate of change, and we were causing far more harm than good by making them confused all the time, and rather than adopting all these agile methods to speed up even further we should step back, chill out, and SLOW DOWN, the exact opposite of what me (and everyone in the internet talking about IT) was advocating.

How could I square this circle? Had I been wrong all along?

The answer came in 2013 when I was on a plant visit and an end user said the system was better in 2000 (when we went live) than it was now. Once again, had all those 13 years of frantic development made things worse?

The actual state of affairs was of course the system was a lot better than in 2000, but the key difference was that in the year 2000 we had hordes of trainers crawling all over the place, and now there are none. In fact us from IT visiting the plants was about the only training the users ever got ... in a system that changed every week....

So the conclusion I have come to is that rapid change is indeed desirable (because the backlog of requests is so huge, and each one is valid, we are good at weeding out friviolus ones) but unless you can ensure the end users actually are trained in how to use the system after the change then you are driving backwards, and the more you acclerate the worse the problem gets.

The problem is that many management types truly do not see an ROI on spending dollars on training. I believe the somewhat trite adage that every dollar you spend on training saves you two dollars, up to a point of course.

Cheersy Cheers

Paul

[mmcisme1]

Interesting.  Training.  Yes I see the need to.  I even release something I consider small and it could impact many people.   There will be people that I made the change for that understand it.  However, many that don't and still use the tile.

I sometimes write a nice training document.  Sometimes I think it's obvious.  Of course I made the change. So I would think that.

[jwood_bowdark]

Hi Graham,

Good stuff as always. My two cents on this is that you're hitting on a notable limitation of the current architecture of the ABAP PaaS. While I'm sure the VMesque approach was necessary for a variety of reasons, I think SAP's ultimate goal here should be to introduce a more lightweight environment that can more easily be containerized. Besides reducing costs and enabling ABAP to fit more comfortably into Cloud Foundry and SAP CP, this shift would also make it easier for developers to run local tests like you're describing. For example, we use tools like Docker for Windows and PCFDev to run local tests on our other Cloud Native apps all the time. Short of that, lighter weight environments will at least normally support a local SDK with a test environment that has decent feature parity.

I personally love CF and think the logical play is to create a more lightweight environment and introduce an ABAP build pack. An elephant in the room there though IMO is the strict reliance on HANA. While I'm not knocking HANA, it is expensive and probably overkill for a lot of extension apps. I certainly see the reasoning behind S/4, but I hope SAP will keep an open mind about letting this ABAP PaaS grow organically to compete with other cloud programming environments that are far cheaper to run and much more mature.

Thanks,

James

[julieplummer20]

Hi Graham,

First of all, I need to stress all thoughts are my own, and not necessarily… etc etc. Standard disclaimer applies.

OK, the tools first:

„practitioner tool choice helps to drive better outcomes.” Yes, I can believe that. But generally, I think that tends to be different vendors offering different tools or dev. environments for, eg, the same language – or offering a GUI and CLI.

What we would have is one vendor supporting both an Eclipse-based IDE, AND simultaneously maintaining another tool set. How much of the SAP GUI love is habit? I’ve just played with the new Table Editor in ADT versus the old SE11. To me, the new one is much easier (certainly easier to explain to a beginner): https://developers.sap.com/tutorials/abap-dev-create-table.html

SAP GUI isn’t dead, but I can’t see us offering the new editors for it (eg for Behavior Definition, or Communication Scenario). (Here’s Thomas Fiedler on this: What’s new and coming with ADT  ).

Second, the Cloud: “a switch to indicate “ABAPPaaS-compatible”

I can see why it would be good if we enhanced the ADT so that you could develop stuff locally, but Auto-complete was whitelisted items only, for example.

However, I think Chris has hit on the problem with what you’ve described (if I understood you): ABAPPaaS is not a subset with onPrem ABAP – it’s a Venn diagram with a (big) overlap. Also, the on-prem will never be in sync with ABAPPaaS – for long, anyway, because of update frequency in the Cloud.

We want to offer an affordable trial as soon as feasible. FWIW, we already offer a check variant for Cloud-readiness : Check Your Custom ABAP Code for ABAPPaaS (and are hoping to offer this if we offer a future AS ABAP developer edition #ABAP_Trial ). So, as far as helping on-prem ABAP devs transition to the Cloud, that seems to be the more boring, but more likely, path for the nearish future. Just my 0.02.

Anyway, I really liked reading this; I love that the Mentors are getting involved, kicking tyres etc. So, I don’t want to be Debbie Downer. However, those are my thoughts – yours are poetry, mine are prose, I suppose. Happy holidays.