For a few weeks, I’ve been researching various non-SAP development tools environments; especially those that are cloud based or cloud oriented. I’ve been looking at how non-traditional SAP development might use their existing tooling for development in the SAP business application development space. I’ve also been focused on how traditional SAP application developers might broaden their boundaries and benefit from tooling outside what they already know.
I began with a focus on HANA Deployment Infrastructure and how modern HANA development can be done without XSA, Cloud Foundry or the SAP Web IDE. This blog utilized command line tooling combined with Microsoft Visual Studio Code.
From there I expanded my experiments by trying out the Google Cloud Shell. The Cloud Shell is a free, small Linux system which a developer can spin up on demand. This environment is pre-installed with many common developer tools – Maven, Node.js, Google Cloud SDK, etc. This gives developers a quick start, low touch development environment that is very cloud native.
Now I’ve decided to try out Amazon’s cloud IDE offering – Cloud9 as well. If there is one common theme here is that Shell is King. The central idea is that we use the easy and low cost option to spin up cloud based server environments quickly and expose a browser based shell environment to access it. The tooling experience revolves around this remote shell and any tooling or api that can be accessed via command line can work without needing some special integration. This is where the SAP direction with SAPUI5, CAPM, etc for command line based tooling is so nice for integration into these other environments as well.
We will begin by looking at the process to get starting using AWS Cloud9. I already have an AWS account, so I’m not going to cover the basics of signing up. That’s been covered well elsewhere. Instead I’ll login into my account.
And then I will navigate to the launch page for the AWS Cloud9 product. From there you can start a simple wizard to launch a new environment.
Right away we see a little different approach compared to Google Cloud Shell. With the Google service you press a single button to Activate the Cloud Shell as a largely pre-configured image with few options to control sizing. Amazon however seems to lean harder into the options to either start a new EC2 instance or even connect to an existing server. This gives you a bit more options. You can follow the Google approach of just spinning up a very small, private server instance for temporary development or you could instead custom size a development server suitable for larger scale testing or centralized team development. This view of team based development comes into play later as well as Cloud9 has some interesting collaborative features built in.
I choose to start with a private developer shell kind of approach and opted for a t2.micro instance. If your account still qualifies for the free-tier, this size fits within the free option. My account is too old to fall within the free option any longer, but still I’m only looking at paying about 0.01 USD an hour for this size.
At the end of the wizard, you get this very interesting best practices information:
There is some really key information here that’s central to all of these cloud based development approaches. First the idea that the development environment is ephemeral. The whole dev server might go away or change at any time. Therefore when you save in any of these environments, its not necessarily permanently persisted. A central Git repository should be your only true persistence. This way we don’t tie our development process to any one cloud or vendor tool or environment. I took a project I started on my local laptop in VS Code, edited via SAP Web IDE full-stack on SAP Cloud Platform, edited it further in Google Cloud Shell and then brought it into Cloud9 for even more work and running it all with no environment specific configuration.
The other important point is about updates of software. This was one of the main appeals of these environments is that many common development tools are already installed and configured. Cloud9 is no different in that regard. But note the item #2 that AWS Cloud9 doesn’t perform automatic updates. But this is where I think the idea of treating your development environment as ephemeral was interesting. Personally I deleted my environment when I was done working for the day. The next day I’ll recreate the entire environment. That way my tooling software is up to date as the core image. Its a different way of thinking – that you development server and environment is disposable but one that increasingly makes sense in a cloud world.
Now I want to start by doing some SAP Cloud Application Programming Model development. To get a good test and comparison, I want to follow the same tutorial for Node.js Local Development found in the SAP online help that I used in the Google Cloud Shell evaluation. https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/d7bb5eee7e0f44a48854a6e831c9c767.html
Once again this is where having a pre-installed and configured environment is so handy. The development server and IDE already have Node.js, NPM, and so many other things installed and perfectly ready to use. I can further configure these tools by opening a terminal shell directly within the Cloud9 development tooling. For instance I want to add the sap registry (https://npm.sap.com) to my NPM configuration.
I’m now able to use NPM to install the @sap/cds module which functions as the command line development tool for SAP Cloud Application Programming Model.
From there I begin in earnest with the tutorial. I can use the cds module we installed previously to initialize this empty project for Cloud Application Programming Model development. The command shell creates the project structure but then we can further edit using the graphical folder structure and other editors. Its a graceful combination of the power of the command line but the time savings of more guided developer tooling.
So after following along with the first few steps of the tutorial, I’m ready to test my OData service. From the shell window within Cloud9, I can start the OData server using the cds run command.
And much like the Google Cloud Shell environment, there is an easy application preview that will launch testing access via a web browser. No long deploy, startup or complicated testing configuration needed. Its simply save, run and you are seeing your changes within seconds.
And once again we see the power of combining shell, command utilities and a development IDE. I continue with the tutorial and deploy my DB model to sqlite3 (which in turn I installed into this environment using NPM).
I can also use CURL from a second shell command instance to test non GET operations on the OData service. So I had no problems following the entire tutorial from this development environment.
So now we’ve seen two very different cloud providers but with similar approaches to how they treat the cloud based development environment. I find the more I work in this approach with disposable development servers, portable projects, and command shell centric tooling and running; the more I like it. The flexibility and power are quite appealing.
I did do a little bit of playing around with the Cloud9 environment that went beyond just trying to run through the SAP Cloud Application Programming Model tutorial. For one I was really impressed by the breadth of programming languages that were supported in Cloud9 I found way more than expected. In fact I was pleasantly surprised to even find ABAP supported out of the gate. So naturally I had to clone an ABAP based project and at least give it a spin:
I also found on Twitter the other day a tutorial for running VS Code via a web server – which was designed to run on Google Cloud Shell.
I was curious if the same would work on AWS Cloud9. I did have to increase the size of my ec2 instance to t2.small, but then VS Code ran fine from it. I was even able to load the SAP CDS Extension (which installs via local vsix file).