How to Migrate a Spring app to the Cloud

Part 1: Current architecture

It’s time!
After getting our toes wet on a couple of cloud projects, we are now targeting a migration. And not just any migration.. this is a full-on, proud Java Spring stack, complete with DB and all!

In the past, whenever the topic of migrating monolithic Java apps into the Cloud came into question, people thought it would take too long to figure out, require too many upgrades. But it’s 2021 now, and things have changed drastically in the last few years. So, we did our research and are ready to present this migration’s journey onto a container architecture in the cloud.

The app we’re zoning in for migrating to the cloud is our Provider Management app (ProvMan), an application for managing the providers (i.e. farms) that provide the goods to be sold via our Magento retail application. The farmers(providers) use this application in order to register/unregister their farms, manage the farms, their stock and delivery windows.

Disclaimer
I Love My Local Farmer is a fictional company inspired by customer interactions with AWS Solutions Architects. Any stories told in this blog are not related to a specific customer. Similarities with any real companies, people, or situations are purely coincidental. Stories in this blog represent the views of the authors and are not endorsed by AWS.

How it all started

In 2010, ProvMan was implemented as one of the initial applications for our company. It used to be just a directory listing of farmers, where farmers could subscribe their farm and manage their listing online.
Come 2014, MyLocalFarmer wanted to implement a marketplace where payments go through MyLocalFarmer. Magento is introduced as the implementation because of time constraints and lack of resources/expertise. At first, our staff manually synchronized the data between ProvMan and Magento, but later we automated this process via batch jobs.

At some point in the late 2010’s, the company recognized the value proposition of migrating to the cloud and so ProvMan was marked over the last few years as a “legacy system” while our leadership figured out whether to buy a replacement on the cloud or migrate what we have. This entailed entering a state of ‘maintenance-only’, i.e. new development was curtailed and only security upgrades or emergency-changes are allowed. Figuring out a replacement required researching information about new products, waiting on resources to be free, documenting everything that was erroneously thought to be ‘self-explanatory’, meeting vendors, etc.

After two years of on and off researching, it was clear that accepting a SaaS solution would mean considerable customization and/or replacing our core logic to adapt it to a particular vendor, and so it was decided we would initiate efforts into migrating our software onto AWS instead.

The Application

The ProvMan application is pretty simple: the farmers login via their user/password, and then are served with the details of their farm. They can:

• update details, add pictures of their farm
• manage their stock
• setup delivery windows for user-pickup or delivery vans (link to delivery project)
• cancel orders
• retrieve reports on their analytics

ProvMan runs on a web browser, which is quite handy these days since farmers sometimes update their stock on the go. To improve their user experience, we introduced Bootstrap JSPs several years ago to make sure the app is responsive and nice looking in small screens.

The application also allows our staff to login with elevated privileges, in case the farmers run into trouble using the app, and can retrieve a ‘no-show’ report for customers that failed to pick up their orders.

OnPrem Infrastructure & Integrations

The ProvMan application utilizes Spring MVC as the framework, Hibernate for database access, JSP for serving webpages to the users, sits on a Tomcat application server and interfaces with a MySql 5.7 database server in primary/standby mode.

In our data center, there are 4 virtual servers serving as application servers which connect to the database server. We have an F5 doing round-robin load balancing with sticky sessions for diverting traffic to the app servers. We also use Nagios to do basic monitoring on the health of our application servers, applications, and database server. When errors happen, Nagios sends email alerts to our distros.

ProvMan interfaces with Magento via a 2-way batch processes running on regular schedule at night. Magento produces a CSV file about the stock that was sold each day which is digested via a stored procedure in the MySql database.

In turn, ProvMan’s database generates another CSV file with the updated stock and pricing information for each farm, which is consumed by Magento. Another CSV files will be generated for sharing product and delivery window information.

Since none of these integrations are real-time, there is obviously a lag as well as a chance for under/overselling. To circumvent updates being done while both systems synchronize, we have a daily 2hr maintenance outage.

ProvMan’s data is backed up incrementally every night and we also take full snapshots weekly going back 3 weeks, with the backups being stored in a different data center. There is no proper DR in place right now. So far, the database had to failover a few times, which produced outages of about 30 minutes. There was also a mishap a few times during production deployments which caused hour-long outages until we were able to fix the issue or rollback the deployment.

On-Prem Development + Deployment

Here’s where we missed the CI/CD boat entirely. Building was done initially old-school via Ant scripts and then upgraded to Maven after a few years. Deployments across dev and test environments are still done with the common practices from that time, i.e. via bash scripts triggered manually by the developers. Production rollouts are executed by a 3rd party vendor through a ticketing system, which developers use to enter a ticket and submit it for approval.

Oh, what fun! Especially if you needed an emergency bugfix… this is not a process meant for the impatient.

The OnPrem Server version of Scaling

We decide quarterly based on traffic patterns to the website, whether we should put in a new server or not. Even if the traffic drops for an entire quarter (such as in winter), we can’t afford to take back a server, since adding a server is too costly from an Operations standpoint. This is because unless we happen to have enough hardware lying around, we might need to order a server and doing so is not trivial. Besides the paperwork, sometimes it takes weeks of planning and waiting for the order to arrive. And even when it’s here, there’s the even more fun part of installing and configuring everything.

Since all of this doesn’t happen very often, our engineers only partially automated some of the steps, leaving the rest to be executed manually. Don’t forget the human factor, where mistakes are made which then need to be found and corrected, and thus require double-checking and testing.

The Decision to Migrate

Now that we covered what we currently have, let’s talk about where we want to go:

First of all, our application is simple and works quite well. The reality is that our users and staff have become used to its UI, and our staff are experts in figuring out and resolving issues quickly on the app itself as well as on any of its integrations.

Nonetheless, we did our due diligence and researched a few SaaS solutions. The first factor to take into consideration is the subscription cost, which would’ve put a dent in our budgets with no end in sight. We would have to replace our mature batch integrations with brand new ones (not only to import the data the data into the SaaS system, but also for interfacing with Magento), which made people very nervous. Since these solutions are usually generic enough to be applied to multiple kinds of systems, they can be complex to configure and issues can be hard and slow to resolve. We also realized that using such a solution meant that our interfaces could end up looking very similar to that of our competitors and our ability to streamline the workflows for our customers would be limited, which means we would not have a unique, tailored offering in the market anymore.

On top of that, add on the time it takes to really, REALLY research these solutions, draw up contracts, implement everything and test it all. It’s not something that can be done under a time constraint, and so we decided to investigate options for migrating the ProvMan codebase onto the cloud.

Here are our requirements for our cloud migration:

• Automate build and deployments, include an approval process for production
• Scaling responsive to traffic in order to cut down costs
• Setup our infrastructure as code (IaC) so that its repeatable
• Minimize outages during database failovers or maintenance
• Change integrations to be real-time, where possible
• More robust monitoring of our app and database server’s health
• Self-healing when issues happen (e.g. think JVM memory issues!)
• Historic metrics data on app and database server (e.g. scaling, http errors)
• Must follow cloud security best-practices
• Keep running costs to a minimum!

Next Steps

So there we have it, that’s the entire story of where we’ve been, and what we are aiming for.

Over the next weeks, we will cover how we managed to easily migrate our Java app onto ECS Fargate, a serverless containerized offering, and what our brand new infrastructure looks like! Stay tuned…!