From Monoliths to Pragmatic Microservices with Java EE

Photo of Ondro Mihályi by Ondro Mihályi

It seems like Microservices architecture is almost everywhere these days. For a long time, I used to have a feeling that many people talked about it but very few use it. So I decided to find out how to get the most out of Microservices. I've studied this architecture a lot, experimented with the technology created specifically for Microservices and talked to other people who knew more than me. This how I've met some incredible people. And it's also a reason why I've joined forces with Reza Rahman and Ivar Grimstad to create a Hands-on Lab about our findings, which we'll present at Oracle Code One this year.

 

All three of us have experienced good use cases for Microservices. But we've also witnessed some bad ways of using Microservices! The "bad ways" came mostly because it was the new, cool thing and it was fun to experiment with, but the end result of some of these experiments weren't so shiny. I've found out that for most enterprise projects, it's better to stick to standard approaches and only introduce new technology and patterns if they're needed. Java EE already provides a lot of useful and easy-to-use functionality for building Microservices. But it soon became evident that an additional layer of less standard technologies is beneficial to keep pace with the modern, fast-moving world and the flexibility enabled by the Microservices architecture. That's why I've joined the Eclipse MicroProfile project on behalf of Payara Services. This project provides an additional set of standards and APIs to use very fast Microservices development and to simplify their maintenance, especially in the cloud.

 

Each of us who have prepared the lab session for Oracle Code One, has his own experience with using Java EE and MicroProfile for building Microservices. But we've all learned that although Java EE isn't the first thing we think of when talking about Microservices, it's invaluable for building maintainable and long living applications based on the Microservices architecture. In the long run, using Java EE pays off with a much simpler code base, more flexibility in deployment and reduction of maintenance costs. Meanwhile, MicroProfile has emerged and now it complements Java EE with a lot of features that make working with Microservices even simpler and more productive. Java EE has been moved under the Eclipse Foundation and renamed to Jakarta EE to allow better collaboration, stability and more openness in the future.

 

We've decided to combine our knowledge and teach others how to use Java EE, Jakarta EE and related technologies like MicroProfile when building modern applications based on Microservices. And not only that: We realize there are many existing applications developed as monolithic solutions which could benefit from the Microservices architecture. It's often much easier to gradually migrate them to Microservices than to rewrite them from scratch. We know with Java EE this is not only possible, but very often - it's simple to do. It's just important to know how Java EE has evolved in recent years. In this lab, we hope to explain how to use the modern Java EE ecosystem most effectively. Not only to build new Microservices applications from scratch but also to apply this architecture to older monolithic applications so that they also can benefit from its flexibility and modern deployment options using containers and cloud.

 

To learn more, join us at Oracle Code One at the session called From Monoliths to Pragmatic Microservices with Java EE on Thursday, Oct 25, 9:00 a.m. And be ready to get your hands dirty with your laptop and some code!

 

If you won't be at Oracle Code One, I recommend watching an older session about being pragmatic with Microservices with Java EE by Reza Rahman:

 

 

 

or check out resources for my workshop about transforming a Java EE monolith to reactive Microservices.

 

You might also be interested Reza Rahman's expectations from the Oracle Code One conference and about his sessions in his article: Does the Spirit of JavaOne Live on Inside Oracle Code One?

 

 

Comments