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:
- The front end, which provided the static web content
- 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.
|Components of the original ESPM application||Components of the migrated ESPM application|
|Object-relational mapping(ORM) implementation using JPA||Object-relational mapping(ORM) implementation using JPA|
|SAP HANA as database layer||PostgreSQL as database layer|
|Web services implemented using Apache Olingo||Web services implemented using Apache Olingo|
|User interface implementation in SAPUI5||User interface implementation in SAPUI5|
|oAuth token-based authentication (based on XSA programming model)|
ESPM Microservice Architecture
Steps for refactoring ESPM
- Split static web content and Java back end code into two separate modules.
- 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.
- 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.
- 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.
- Configure authentication and authorization.
Use the integrated container authentication provided with the SAP Java buildpack or the Spring security library.
- Create the application security descriptor (xs-security.json) and define all the scopes for authorization here.
- 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.
|Minimal effort||Back-end code is still monolithic|
|Few code changes||Don’t get all benefits of microservices|
|Can develop, deploy, and scale front end and back end separately|
The migrated ESPM application can be found in Github
- 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)
Migration Strategy: Refactoring to Microservices
Steps for refactoring SHINE
- 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.
- 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
|Components of the original SHINE application||Components of the migrated SHINE application|
|SAP HANA as database layer||SAP HANA as database layer|
|User interface implementation in SAPUI5||User interface implementation in SAPUI5|
|oAuth token based authentication (based on the XSA programming model)|
SHINE Microservices Architecture
|Opportunity to refactor and improve code.||Considerable effort was spent in identifying the correct cut for each of the microservices.|
|Advantages of microservices||Bigger binary archive as each microservice needs to bundle its dependencies. This leads to duplicate libraries across microservices.|
The migrated SHINE application can be found in Github
- 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.
- Review all the SAP Cloud Platform Neo environment service dependencies and their availability in SAP Cloud Platform Cloud Foundry environment.
- Implement new back end feature or rewrite one of the most important existing back end module as a separate microservice.
- Evaluate the microservices architecture paradigm and gain experience.
- 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: