Cloud Foundry is meanwhile available as a new environment in SAP Cloud Platform for over 18 months. If you are a developer who is actively using the Neo environment, now is a good time to evaluate if Cloud Foundry brings advantages to your applications.
Such advantages might be operations aspects like easier up- and down scaling or a full-fledged platform API. The uniform way of consuming services and the availability of services like RabbitMQ and Redis might also present an opportunity from a development perspective.
Once you decide that Cloud Foundry is a viable target for your existing application, the question arises, how to proceed and get your application ported. The Neo environment supports many types of runtimes ranging from Java and HTML5 to HANA XS classic. Migrating XS classic applications to XS advanced has been described
in a blog earlier this year. For Java and simple HTML5 applications there was no such guide yet. Until today.
We are happy to announce the availability of an in-depth investigation detailing the concrete steps it takes to make an existing Neo application run on Cloud Foundry by going full-circle:
- Local development experience
- Authentication
- Service consumption
- Connectivity
- Deployment
- Operations
- And more…
There are multiple migration strategies. You can take the chance of rearchitecting and splitting the app into multiple microservices. This will lead to a code fork and it will most likely cause high efforts to maintain the existing Neo version in parallel until the new version is ready. It can be a very viable approach though, and a
separate blog by our reference app team investigates exactly this.
Another approach is modifying the application to run as-is and stick to one code line so that the Neo and Cloud Foundry version can be supported in parallel. This means that only the parts that are different in the respective environments need to be taken care of. Of course, this also opens the option to gradually split the application into microservices later over time and can be easier than doing a big bang change.
The latter approach is the one taken in the guide. To illustrate the potential pitfalls a sample app is being used and gradually adapted. The app consists of a Java backend exposing a REST API being consumed by a UI5 app. Both parts reside in the same repository but allow multiple deployment scenarios:
Neo
- Java and UI deployed as one app, UI served from backend
- UI deployed to HTML5 runtime using a destination to forward to separately deployed Java backend
Cloud Foundry
- Java and UI deployed as one app, with an AppRouter simply forwarding all requests
- AppRouter serving static UI directly and forwarding all other calls to Java backend
- AppRouter forwarding calls to UI to HTML5 repository service and all other calls to Java backend
All combinations can be tried out and the build will produce all artifacts needed. We are actually releasing two example apps:
- ESPM multi-environment version: The sample app you might already be familiar with, adapted to the concepts illustrated in the guide, some deployment scenarios will be released a bit later.
- PrimeTime: A more complex example (the technical baseline for ESPM above) of a productively used SAP in-house app.
Open the Guide
We are aware that only a small subset of scenarios can really be described in a single guide to keep the focus. It would be great to get your feedback on approaches you have taken so far or additional scenarios that you think should be covered. Happy reading!
