{{announcement.body}}
{{announcement.title}}

Thoughts on Microservices, Part 2: Evolution of MicroProfile.io

DZone 's Guide to

Thoughts on Microservices, Part 2: Evolution of MicroProfile.io

Get one architect's thoughts on why MicroProfile is becoming such a popular way to build out Java-based microservices.

· Microservices Zone ·
Free Resource

Looks like public transport is a good place to blog. For several hours I just have a time on my own. I may stay focused on the topic.

So, I’m now on my flight from Novosibirsk to Moscow after wonderful CodeFest conference! I’ve got four free hours, an A/C plug, and no free internet (yes, there is payed WiFi), and only the views of the immense Siberian plains from my window.

I had an amazing time in Siberia! I had a lot of really exciting moments there! I met a lot of truly interesting people and had the pleasure to talk to them! A trip report on CodeFest will be published soon!

But this time on the plane I have I want to dedicate to some other thoughts I recently had on my mind, and they are about the evolution of MicroProfile.io.

I had the privilege to be invited to CodeFest to give my talk about MicroProfile.io in Russian. I was very happy that the audience was so excited about this project. I had a lot of questions that kept me in the discussion zone for more than one hour after my talk. The interest was great!

The MicroProfile.io project is an amazing example of a community at work! It is very young, but it evolves extremely fast! I was the eyewitness of the birth of the project, when it started with just three specs inside CDI, JSON-P, and JAX-RS. It was kind of a brave move to start with just these specs, but at the same time it was very wise. This ignited a lot of discussion and community work. Shortly after that a brand-new Config spec was created, allowing us to create not only portable code, but portable configurations as well.

The community worked hard to establish something really useful in the microservices world and created fault tolerance, health checks, metrics, and JWT propagation. The specs like OpenAPI, RestClient, and OpenTracing made the picture complete. And then JSON-B was the cherry on top. Every new version of MicroProfile.io came with some new specs and evolutions of the already available ones, definitely great! Let us not forget that all this happened in only two years.

Every time I've got together with Ivan Ivanov to give our workshop on MicroProfile or give our talks about it, we've seen some really huge enthusiasm in the eyes of our attendees. Finally, there is a lightweight absolutely standardized and portable way to write microservices in the Java world.

The platform vendors, from their side, made some really tremendous efforts to implement all of those specs. Some of the servers were rewritten from scratch, and completely new projects like Helidon and Quarkus emerged.

Starting from MicroProfile version 1.2 (which I believe is mature enough) I’ve started using it in my projects. Although it is a bit hard with the testing, I’m quite happy about it. I just love standard code, I like the portability. I have even used it twice, when we had to switch servers from different vendors. It really went seamlessly. In one of my previous posts, I’ve described how easy it was for us to migrate one of our services to Quarkus. Almost copy/paste! The power of standards!

There are some things that bother me, nevertheless. I’m always carefully reading the discussions in the MicroProfile.io mailing list and I’m not sure if, for example, adding a persistence spec to the project will be a good idea. I know, a lot of services are stateful and persist a lot… but is it really relevant to microservices? Everything can persist and this is not something specific to microservices. Why then should we put it in the MicroProfile.io project? There are a lot of stateless services. They don’t need any persistence.

I had the pleasure to share these thoughts with Emily Jiang at Voxxed Bucharest. I have proposed to start thinking a little bit differently – why don’t we make separate profiles relevant only to specific problems we are solving? Should we have a special “Persistence profile”? Or, if we want to make something reactively, should we establish a “Reactive profile”? And if we need more than one profile, we just combine them.

This may sound absurd, but I believe that the current set of specs is just enough for MicroProfile.io. There are already 12 of them. Most of them are really microservices-specific, like fault tolerance, etc., and others, like CDI, are the foundation of the platform. Should the JPA spec be one of the foundation specs? I really don’t think so. If CDI is really a glue to put it all together, JPA can sometimes just be totally ignored, if the service is stateless.

I’m still not sure if I’m right in my thoughts. I sincerely wait for critiques. But I believe that staying focused on microservices-relevant specs is a better evolutionary path. There are more microservices-specific things to be discussed, like better servicemesh integration, or perhaps a common set of server flags?

Currently these 12 specs in MicroProfile 2.2 solve all of my microservices-specific tasks. It’s only the JSON-P spec that I’m not using anymore, I do it all through JSON-B 

Okay, our plane is approaching Moscow, I already see the Ostankino tower and the Moscow skyscrapers. Time to switch off the laptop.

Topics:
microservices ,microprofile ,microservices java ,microservices architecture ,open source microservices

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}