I often hear from traditional SAP developers that want to grow into the larger world of cloud based development but face the challenge of the barrier to entry. They might be looking at exploring Cloud Application Programming Model or maybe Fiori/UI5 development; but the various tooling required isn't always easy to assemble. For people with years of experience working with some of these tools, installing Node.js, Maven, or other industry common development tools would be common place. But for many of the SAP developer base, this might seem foreign or even completely restricted on their developer machine.
Yes even today I still speak with developers where their companies control their development client machines to the extent that they can't install any software or can only choose from a very small list of corporate approved software. Even if you do have access to install these tools, keeping them up to date can be a daunting task. Particularly if you only work occasionally with these tools, it can feel like every time you sit down to use them your work is interrupted because everything needs an update first.
This is where recently we have seen the role of browser based development environments like the SAP Web IDE Fullstack. A browser based complete development environment can solve some of these problems by providing a zero installation development experience; however the downside of this approach is that it can be slower to innovate. You might have to wait for new tools features to be surfaced into the browser UI. You also lose a measure of control and access to the environment in which you are working. That's why so many developers still prefer working in a local environment and shells. There's nothing quite like being able to crack own a command shell and have complete control over your execution environment.
This is where I've been recently exploring the Google Cloud Platform - Cloud Shell. Its an interesting mixture of the two different approaches I've described above. 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. The tooling is part of a provided Docker Image and kept up to date automatically. Yet each developer also gets 5Gb of private persistence in their home directory. This way you can configure the shell to your liking, install additional software and even temporarily store you development projects here and persist them across sessions. Yet this entire environment is available via simply a web browser. No local installation, no SDK, no tooling beyond a basic web browser is needed.
Of course Google doesn't just provide this free developer environment out of the goodness of their heart. They do this because it makes it easy to get started with development on the Google Cloud Platform. They pre-install the Google Cloud SDK, kubctl, docker, and several other tools that are complementary to development on Google Cloud Platform. But because of the openness of most of these tools, this also makes this a great development environment for SAP developers working with Cloud Application Programming Model, SAPUI5, or SAP Cloud Platform Cloud Foundry. That's what I would like to share in this rest of this blog: my experience using Cloud Shell specifically for development of SAP Cloud Application Programming Model based applications.
The hardest part here is probably just getting started with Google Cloud Platform in general. You need to on board an account, setup billing (although once again the Cloud Shell is no charge). I personally have just one project created in Google Cloud Platform and no other engines or services running. My bill is currently $0 as I'm truly only using the Cloud Shell.
Once you are logged in to Google Cloud Platform, its easy enough to access the Cloud Shell as there is a an icon in the title bar regardless of where you are in the platform navigation. Just click this Activate Cloud Shell icon and wait 2-3 seconds (in my experience) while they provision a Linux system for you.
After the few startup seconds you get a browser based command shell connected to your running Linux environment. You'll notice that it automatically sets parameters for your session like connecting you to your current Google Cloud Platform project. You have to give Google credit for really making start up easy for developers. But not just the startup experience, but also getting your first application running as well. For now I'll ignore a lot of these aspects and simply focus on using this as a general development environment.
Now I want to start by doing some SAP Cloud Application Programming Model development. Ideally I want to use the tutorial for Node.js Local Development found in the SAP online help but adapted to this environment. https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/d7bb5eee7e0f44a48854a6e831c...
This is where the pre-installed software is so handy. I already have git, Node.js runtime, and NPM installed in this environment for me. The only thing I need to do is customize some of my settings. For instance I want to add the sap registry (https://npm.sap.com) to my NPM configuration. I only need to do this once as the NPM configuration is stored in my home directory which is persisted permanently.
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.
I'm ready to start in with development following the tutorial now. The only major deviation I want to make is to use Git as well. I won't just start with an empty folder but instead I'll go to my github.com account and create an empty repository. Then I can use git clone from the Cloud Shell to bring this empty project into my environment.
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.
Now I could start editing files according to the tutorial, but this is where things get extra interesting. While a command shell based editing experience might be some people's preference, I also like a little IDE support as well. It turns out that the Cloud Shell also has a basic graphic editor. To me this is the perfect mixture of the power of both a command shell and GUI features and the ability to seamlessly work in either (or both) based upon personal preference.
So after following along with the first few steps of the tutorial, I'm ready to test my OData service. From the Cloud Shell I can start the OData server using the cds run command.
But notice the server runs on localhost. You might be thinking then that testing this service will be difficult. However this too has been made pretty easy. There is a little Web Preview button in the corner of the Cloud Shell window. It will ask you what HTTP port you want to preview.
A new browser tab then opens which routes to the server/port running in your private Cloud Shell instance.
You get all the benefits of quick, local testing. I make a change to my development files and re-run the CDS command and within a second or two I'm already testing the new version in the browser.
Now things get really fancy in this tutorial. I start writing some JavaScript code and get to experience the graphical IDE of the Cloud Shell to its fullest. It's really got pretty good language support with code completion, syntax highlighting, outline, refactoring, etc. I could definitely see myself doing more than just "hello world" coding in this environment.
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.
There such interesting potential with this kind of hybrid local development (but remotely in the Cloud) kind of approach. I was able to perform the complete CAP local development tutorial using this approach with zero cost and zero local installation.
In fact I continued to see where I could go beyond the initial tutorial.
Using the pre-installed Git client I also committed and pushed my development content back to github.
Although not included in the standard image of Cloud Shell, I was able to install the Cloud Foundry command utility and connect over to my SAP Cloud Platform Cloud Foundry account as well. From here I could easily push my development content and run it from the SAP Cloud Platform as well. As you can see here we are definitely blurring the lines of what is Cloud. Openness on both sides here mean that the tools from Google can also be used to develop and deploy with the capabilities from SAP as well. Its a win/win for developers.
I consider this experiment to be quite successful. It makes me wonder just how small I could go with a development device and still be able to work with an environment like this. Sure enough I was able to use this Cloud Shell even from my old iPad.
Ergonomically speaking, I'm not sure if I'm ready to work from an iPad virtual keyboard for day to day coding, but this has me thinking that for the next work event maybe I should try digging out that old Chromebook.
Yes even today I still speak with developers where their companies control their development client machines to the extent that they can't install any software or can only choose from a very small list of corporate approved software. Even if you do have access to install these tools, keeping them up to date can be a daunting task. Particularly if you only work occasionally with these tools, it can feel like every time you sit down to use them your work is interrupted because everything needs an update first.
This is where recently we have seen the role of browser based development environments like the SAP Web IDE Fullstack. A browser based complete development environment can solve some of these problems by providing a zero installation development experience; however the downside of this approach is that it can be slower to innovate. You might have to wait for new tools features to be surfaced into the browser UI. You also lose a measure of control and access to the environment in which you are working. That's why so many developers still prefer working in a local environment and shells. There's nothing quite like being able to crack own a command shell and have complete control over your execution environment.
This is where I've been recently exploring the Google Cloud Platform - Cloud Shell. Its an interesting mixture of the two different approaches I've described above. 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. The tooling is part of a provided Docker Image and kept up to date automatically. Yet each developer also gets 5Gb of private persistence in their home directory. This way you can configure the shell to your liking, install additional software and even temporarily store you development projects here and persist them across sessions. Yet this entire environment is available via simply a web browser. No local installation, no SDK, no tooling beyond a basic web browser is needed.
Of course Google doesn't just provide this free developer environment out of the goodness of their heart. They do this because it makes it easy to get started with development on the Google Cloud Platform. They pre-install the Google Cloud SDK, kubctl, docker, and several other tools that are complementary to development on Google Cloud Platform. But because of the openness of most of these tools, this also makes this a great development environment for SAP developers working with Cloud Application Programming Model, SAPUI5, or SAP Cloud Platform Cloud Foundry. That's what I would like to share in this rest of this blog: my experience using Cloud Shell specifically for development of SAP Cloud Application Programming Model based applications.
Getting Started
The hardest part here is probably just getting started with Google Cloud Platform in general. You need to on board an account, setup billing (although once again the Cloud Shell is no charge). I personally have just one project created in Google Cloud Platform and no other engines or services running. My bill is currently $0 as I'm truly only using the Cloud Shell.
Once you are logged in to Google Cloud Platform, its easy enough to access the Cloud Shell as there is a an icon in the title bar regardless of where you are in the platform navigation. Just click this Activate Cloud Shell icon and wait 2-3 seconds (in my experience) while they provision a Linux system for you.
After the few startup seconds you get a browser based command shell connected to your running Linux environment. You'll notice that it automatically sets parameters for your session like connecting you to your current Google Cloud Platform project. You have to give Google credit for really making start up easy for developers. But not just the startup experience, but also getting your first application running as well. For now I'll ignore a lot of these aspects and simply focus on using this as a general development environment.
Now I want to start by doing some SAP Cloud Application Programming Model development. Ideally I want to use the tutorial for Node.js Local Development found in the SAP online help but adapted to this environment. https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/d7bb5eee7e0f44a48854a6e831c...
This is where the pre-installed software is so handy. I already have git, Node.js runtime, and NPM installed in this environment for me. The only thing I need to do is customize some of my settings. For instance I want to add the sap registry (https://npm.sap.com) to my NPM configuration. I only need to do this once as the NPM configuration is stored in my home directory which is persisted permanently.
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.
CAP Development
I'm ready to start in with development following the tutorial now. The only major deviation I want to make is to use Git as well. I won't just start with an empty folder but instead I'll go to my github.com account and create an empty repository. Then I can use git clone from the Cloud Shell to bring this empty project into my environment.
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.
Now I could start editing files according to the tutorial, but this is where things get extra interesting. While a command shell based editing experience might be some people's preference, I also like a little IDE support as well. It turns out that the Cloud Shell also has a basic graphic editor. To me this is the perfect mixture of the power of both a command shell and GUI features and the ability to seamlessly work in either (or both) based upon personal preference.
So after following along with the first few steps of the tutorial, I'm ready to test my OData service. From the Cloud Shell I can start the OData server using the cds run command.
But notice the server runs on localhost. You might be thinking then that testing this service will be difficult. However this too has been made pretty easy. There is a little Web Preview button in the corner of the Cloud Shell window. It will ask you what HTTP port you want to preview.
A new browser tab then opens which routes to the server/port running in your private Cloud Shell instance.
You get all the benefits of quick, local testing. I make a change to my development files and re-run the CDS command and within a second or two I'm already testing the new version in the browser.
Now things get really fancy in this tutorial. I start writing some JavaScript code and get to experience the graphical IDE of the Cloud Shell to its fullest. It's really got pretty good language support with code completion, syntax highlighting, outline, refactoring, etc. I could definitely see myself doing more than just "hello world" coding in this environment.
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.
Closing
There such interesting potential with this kind of hybrid local development (but remotely in the Cloud) kind of approach. I was able to perform the complete CAP local development tutorial using this approach with zero cost and zero local installation.
In fact I continued to see where I could go beyond the initial tutorial.
Using the pre-installed Git client I also committed and pushed my development content back to github.
Although not included in the standard image of Cloud Shell, I was able to install the Cloud Foundry command utility and connect over to my SAP Cloud Platform Cloud Foundry account as well. From here I could easily push my development content and run it from the SAP Cloud Platform as well. As you can see here we are definitely blurring the lines of what is Cloud. Openness on both sides here mean that the tools from Google can also be used to develop and deploy with the capabilities from SAP as well. Its a win/win for developers.
I consider this experiment to be quite successful. It makes me wonder just how small I could go with a development device and still be able to work with an environment like this. Sure enough I was able to use this Cloud Shell even from my old iPad.
Ergonomically speaking, I'm not sure if I'm ready to work from an iPad virtual keyboard for day to day coding, but this has me thinking that for the next work event maybe I should try digging out that old Chromebook.
- SAP Managed Tags:
8 Comments
