Experience in migrating ESPM and SHINE Applications from SAP Cloud Platform Neo to Cloud Foundry Environment

This blog outline our experience of migrating monolithic application like Enterprise Sales and Procurement Model(ESPM) and SAP HANA Interactive Education (SHINE) running on SAP Cloud Platform, Neo environment (Neo) to a microservice-based application running on SAP Cloud Platform, Cloud Foundry environment (Cloud Foundry) and highlights a few lessons we learned along the way.

For a general overview and recommendations for refactoring monolithic applications to microservices, take a look at the Best Practices for Adapting SAP Cloud Platform Application to the Cloud Foundry Environment guide.

Transforming a monolithic application into microservices is a form of application refactoring, wherein application functionality is expected to remain the same but brings in the advantages of microservices.

Our team refactored two applications, using a different approach for each. I’ll show you what we did with these applications and share what we learned from the experience.

Enterprise Sales and Procurement Model (ESPM)

The ESPM application is a reference application that demonstrates how to build applications in the Neo environment of SAP Cloud Platform and deploy them to a Java runtime.

                                                    ESPM Monolith Architecture

Migration Strategy: Common Codebase

To rapidly convert this application to a microservice-based application, we chose to apply a common codebase approach. We decided to split the front end and the back end code. This approach isn’t new, as the Neo environment already supports deploying the front end independently in an HTML5 container and the back end in a Java Runtime container.

The application, which was packaged as Java web archive (war), had the Java back end implementation and static web pages in the same Java web project. Our first step was splitting this into two parts:

1. The front end, which provided the static web content
2. The back end, containing the business logic written in Java

In addition to splitting the application, two new important parts of the overall architecture include the application router (AppRouter) component and User Account and Authentication service (UAA).

The application wasn’t using any native SAP HANA capabilities, so we moved to PostgreSQL, which is an open source relational database that’s available, by default, on Cloud Foundry. Because the Java Persistence API (JPA) was used for persistence it was easier to move from SAP HANA in Neo to PostgreSQL database in Cloud Foundry as there were changes in only database configuration and drivers.

                                                      ESPM Microservice Architecture

Steps for refactoring ESPM

1. Split static web content and Java back end code into two separate modules.
2. Integrate the application router (AppRouter) into the web module and configure it.

The AppRouter constitutes a singular entry point into a microservice-based architecture. The common advice from XS advanced programming model is to package the static web content into the AppRouter itself. This results in AppRouter and web module running as a single microservice, that constitutes the front end. In addition to routing, you must also configure the AppRouter to delegate authentication and authorization to UAA, so that the individual microservices do not have to deal with this aspect.

3. Create the application router configuration file (xs-app.json).

Th xs-app.json file contains routing information for requests from the web module to the java back end. This file is used by the AppRouter to dispatch requests to the back end, authenticate users, and so on.

4. Enable database binding in the Java back end.

The Neo environment uses Java Naming and Directory Interface (JNDI) binding, while Cloud Foundry uses service binding; the code must therefore be adapted accordingly. Various open source libraries like Spring Cloud Connectors can help.

5. Configure authentication and authorization.

Use the integrated container authentication provided with the SAP Java buildpack or the Spring security library.

6. Create the application security descriptor (xs-security.json) and define all the scopes for authorization here.
7. Create the application manifest.yml

Among other things application manifests tell Cloud Foundry how many instances to create and how much memory to allocate to the services that the applications should use.

The migrated ESPM application can be found in Github

Learnings

• A minimal set of steps are required to migrate a simple application from Neo to Cloud Foundry.
• We couldn’t migrate the complete application due to missing services, like Document Services, in the Cloud Foundry environment. We used a proxy application running on Neo to consume Document Services from Neo in Cloud Foundry.

SAP HANA Interactive Education (SHINE)

SAP HANA Interactive Education, or SHINE, is a demo application that makes it easy to learn how to build applications on the advanced model of the SAP HANA extended application services. The first version of SHINE, which first became available with SAP HANA 1.0 SPS05 in 2012 was a monolithic application developed using XS JavaScript. When the advanced model became available, the original application was refactored to run on it and Cloud Foundry

Migration Strategy: Refactoring to Microservices

We chose this approach because we wanted to reuse parts of the XS JavaScript code and to be free to choose the best fitting programming language for each microservice. We migrated the application iteratively: It took four iterations to reach feature parity with the original monolithic SHINE application.

Steps for refactoring SHINE

1. We extracted the modules and split them into multiple services.

We split the modules so we could group similar business functionality together and choose the best fit programming language for each microservice. For example we implemented the data generator module, which is used for generating transactional data (purchase orders and sales orders), in Node.js to leverage the asynchronous nature of the programming language.

2. We used multiple technologies used within same application (for example, Java, XS JavaScript, and Node.js)
3. We reused some of the existing SAP HANA server-side JavaScript code (xsjs) and all xsodata services without making any changes.
4. Following the domain-driven data model approach we split database artifacts into two database containers.

Existing database design time artifacts were mostly reused with minor changes and required removal of schema references from all artifacts.

                                                      SHINE Monolith Architecture

                                           SHINE Microservices Architecture

The migrated SHINE application can be found in Github

Learnings

• An iterative approach to migration from monolith to microservices provides an opportunity to gain experience and improve.
• There is opportunity for code reuse.

Guidance for Migration from Neo to Cloud Foundry

Refactoring from monolith to microservice is a change in the architecture paradigm as well as a mental shift. You should carefully consider the cost and risk involved. Even though microservices provide better fault tolerance, and the ability to scale parts of the application independently, they also introduce complexity, which is discussed in “Microservices Premium” by Martin Fowler. The premium increases a project’s cost and risk.

 We recommend that you use a combination of the common codebase and the refactor to microservices approaches to move from the SAP Cloud Platform Neo environment to the SAP Cloud Platform Cloud Foundry environment. You can start a gradual journey from monolith to microservice with minimal refactoring of code.

1. Review all the SAP Cloud Platform Neo environment service dependencies and their availability in SAP Cloud Platform Cloud Foundry environment.
2. Split the front and back ends. Front end code includes static HTML and Javascript files. This can run in Cloud Foundry as one microservice. Create another microservice for your back end code. This enables your team to quickly move to Cloud Foundry environment and gain some experience in building a microservices application. As this approach takes the minimal effort, your application can soon be productive.
3. Implement new back end feature or rewrite one of the most important existing back end module as a separate microservice.
4. Evaluate the microservices architecture paradigm and gain experience.
5. After careful consideration of the need (elasticity, resilience, and so on), cost, and risk involved, gradually refactor the complete application to microservices.

This approach enables you to gradually leverage on the advantages of microservice architecture:

• Scalability – the front and back end can be independently scaled.
• Develop and deploy the front end and the back end independently.
• Fault Isolation – each microservice you add can provide fault isolation.

 Are you still wondering why you should leave the monolith behind and all the resources you invested, too?

Martin Fowler says in “MonolithFirst”:

As I hear stories about teams using a microservices architecture, I’ve noticed a common pattern.

• Almost all the successful microservice stories have started with a monolith that got too big and was broken up.
• Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

The experience gained in building, deploying, and operating a monolith can help you decide whether to migrate it to a microservices-based application. According to Fowler, it seems to be better to migrate an app from monolith to microservice rather than starting from scratch.

Your investment in building a Neo app has not gone waste after all. It was simply the start of your journey to a microservice architecture.

You might also want to read:

A blog from @Robert Wetzold: https://blogs.sap.com/2018/12/07/best-practices-for-adapting-sap-cloud-platform-applications-to-the-cloud-foundry-environment/