Leveraging Pivotal Cloud Foundry in Migrating a Legacy Application to Microservices
More than ever before, business needs to be nimble and able to respond rapidly to the market with its ever-growing complexities and demands. And with the advent of cloud services and other modern tools that help automate the test and deployment process, companies are constantly looking for ways to modernize their architecture.

Crosslake recently completed a project with Pivotal on a project to begin this process of modernization for a large financial institution.

Situation and Business Challenge
The company, which will remain anonymous for these purposes, had a SaaS application that provided its customers the ability to manage their various financial accounts and services. The application simplified the many back-end services and databases that had grown over the years.

While providing needed functionality to customers, the application was and is a monolith. It was a sizeable application that had classes for a consumer financial environment. And while only a couple of years old, the software had already grown significantly in complexity to the point that the internal coupling limited the team's ability to implement much-needed change.

The company had already begun modernizing its architecture and moving to Pivotal Cloud Foundry (PCF), so there was an existing knowledge base of cloud migration within the organization. The engineering team, charged with this application, were finding themselves increasingly focused on tactical issues, and wanted to take a strategic approach to modernization.
Following a two-day inception session, our team spent six weeks beginning the process of modernizing the application. The project scope included carving out 1-2 modules while moving them from the existing Java Spring Web application into Spring Boot microservices. All of the application and microservices would be deployed in a stable, reliable and resilient PCF environment.

An underlying objective in all of our work was to ensure that the client and the Pivotal/Crosslake teams all worked seamlessly together to ensure that not only was the architecture evolving, but so was the organization and its processes. We documented all repeatable processes in a sort of "cookbook", building out the recipes as work progressed. This was a critical measure of success of the project.
The project was conducted in two phases:

  1. Moving the application as-is into Pivotal Cloud Foundry ("Lift-and-Shift")
  2. Then carving out the first microservices ("Re-Platforming")
The Lift-and-Shift phase focused on deploying the application to PCF. Deployment, monitoring and logging would be done using standard PCF tools. The team prepared the application for a cloud environment deployment. Configuration parameters were extracted into YML files and delivered via Spring Cloud Services; this kept the needs of the environment separate from the needs of the application. A deployment pipeline was built using Jenkins to deploy the application to a test environment, run the automated tests, and then deploy to a staging environment. Both environments were sites in the PCF space. Direct dependencies (JAR files) were replaced with delegate classes (using an Apache CXF) that would subsume SOAP XML calls to the underlying services.

The Re-Platforming phase focused on identifying candidates for carve-out, setting patterns and practices around the development of microservices, and deploying the first instance of the hybrid solution.

When figuring out which functionalities to carve out, the best approach was to identify existing coarse-grained boundaries. These functionalities were easier to separate and put into a service, as they had a clearly defined seam that could be replaced with REST calls to an external service.

Two new microservices (account and customer, both existing modules) subsumed existing SOAP XML calls to underlying services (using delegate classes and Apache CXF), while exposing a REST API to be consumed by the application. The API and data models were kept simple, providing only the needed functionality. This was a key refactoring opportunity; the complexity of the underlying system could not simply be re-built in a different implementation.
The goal was to start with a simple service and buildout the CI/CD pipelines, tests, API design and integration into the existing monolith. This then became a repeatable process, with the goal of becoming easier with each iteration, which allowed the engineering team to tackle more complex services. Time can then be spent focusing on the problem domain, not just the mechanics of deployment or learning new approaches to design and testing.

Each extracted functionality was and is a new service that can be designed, developed, deployed and scaled independently. As long as the external contract (the API) is honored, the service can be refactored, even rewritten from scratch with no effect on dependent clients.

With the refactoring efforts, the company has already noticed reductions in the time required to develop and deploy changes, as well as time needed to resolve post-deployment issues. With PCF and the ability to easily provide centralized logging and monitoring, time spent troubleshooting and in root cause analysis has been significantly reduced.

Modernization will help our client retire some of its outdated back-end systems as well as eliminate the many point-to-point integrations and dependencies. The company will continue on their modernization efforts, allowing the teams to be more strategic and proactive going forward.

In the end, ONLY COMPANIES THAT MODERNIZE, SURVIVE. Companies must be best-in-class to meet today's market demands. And that means having best-in-class, fully modernized systems, from quality assurance to engineering effectiveness to sales measurement.