Migrating Java microservices app from Spring Boot to MicroProfile

So what do you do once you have a hypothesis and some time on your hands? You perform an experiment! And that’s just what our Solution Engineering team did.

In this blog series, you will see the work done by our team to convert the existing Spring-based implementation of our WebSphere Liberty-based BlueCompute application to using the latest and greatest of the generally available MicroProfile 1.3 project capabilities. Our BlueCompute application is a microservices-based reference architecture that provides a digital storefront experience to users while being built with containers and deployed on Kubernetes.

This series will provide insight into the well-worn and edge cases when implementing standard microservices projects in either framework. Spring or MicroProfile, which one should you pick for more interaction between backend microservices? Which one is more easily adaptable to different user interaction patterns? And, most of all, which one allows you to write less code, while still understanding the breadth of the application?

If you’re writing Java-based microservices today, you won’t want to miss this series. It will show you the details about what it’s like to build, deploy, and migrate Java microservices with Spring or MicroProfile, two of the most popular frameworks out there today.

If you would like more background on Java microservices architectures, please check out the following resources:

You can also explore the OpenLiberty guides to become a MicroProfile master.

The story behind our migration from Spring to MicroProfile

In recent years, Enterprise Java has been defined by two major benefactors — Spring on one end of the spectrum and Java Enterprise Edition on the other end. As with all competing, evolving, or somewhat overlapping functional areas, developers always argue which one is “better” or which one is “best.”

Is it better to future-proof yourself by following a widely accepted community development model, as defined by the Java Community Process and brought us all the Java EE specifications? Or is it better to adopt smaller components that are more applicable on a per-project basis but may wildly evolve in future releases as the market shifts? Can I adopt the latest and greatest architectural conventions, like microservices and containers, with a framework that is slow to move and adverse to picking winners? Or do I choose a framework that will adapt quickly, but cause me to rewrite much of my application code to stay current as the winners evolve? Good questions!

Lessons learned while writing our reference microservices-based app

At this point, it’s fair to ask: Why present this history lesson of MicroProfile?

Simply put, our Solution Engineering team was in this very situation and had to decide which way to go. Our Solution Engineering team builds reference applications and architectures for the entire spectrum of Enterprise Workloads, including microservices, cloud-native development, messaging and integration-based workloads, batch workloads, mainframe workloads, and so on.

Not shortly after the original release of the MicroProfile 1.0 specification, our team was tasked with building a reference application that would become our exemplar for the burgeoning microservices architectural space. What would soon become known as “BlueCompute” would have to be architected from scratch, on whiteboards and in conference rooms, making sure it hit all the right points necessary to truly represent a proper reference architecture. As mentioned above, MicroProfile had only recently been released to the general public (if not still in preview mode), so it wasn’t something the team felt strongly about adopting, as our team didn’t know how broadly we could implement a proper end-to-end, microservices-based, 12-factor-oriented application with “just MicroProfile.”

So, for lack of other options, the team decided to implement the initial version of our BlueCompute reference application utilizing the Spring Boot and Spring Cloud frameworks. Development was rather straightforward, with some minor hiccups due to supported features in specific versions of either the Spring Boot or Spring Cloud sub-projects, but our team was able to achieve exactly what we needed to for a full reference implementation on both a Cloud Foundry platform and a Docker-based container workload.

The next wrinkle was the success of Kubernetes in the container orchestration workspace. So, instead of managing many containers locally or through a series of scripts, our team now had the option to use one CLI to deploy and scale our reference application to (resource and budget notwithstanding) near-infinite technical bounds. However, the move to Kubernetes mostly obfuscated the need for Spring Cloud capabilities, as most of our microservice capabilities were supported out of the box by Kubernetes (with some minor exceptions like Hystrix fault tolerance support).

Reduce complexity and dependencies of Java microservices architectures

If you’re interested in reducing the amount of complexity and dependencies in your Java microservices architectures, then you’ll want to follow along with this multi-part series. It will cover specific details of the MicroProfile framework and how our team migrated from an original Spring Boot-based implementation to one built on top of the latest MicroProfile packaging.

Additionally, if you would like some hands-on experience, check out guides on openliberty.io. There are over a dozen MicroProfile-specific tutorials for deploying Java applications on the world’s most flexible, open-source application runtime, built for cloud native and microservices!

Originally published at www.ibm.com on September 24, 2018.