Workshop MicroProfile

Hi all, tell us who you are and what lead you into microservices?

Hi! My name is Ivan and I am one of the leaders of the Bulgarian JUG. I am into Java development since the dawn of the century and for the most part I’ve worked in a big enterprise (SAP Labs Bulgaria). Now I have my own company and am running various consulting projects. Since the beginning of 2018 I was honored to become part of the Java Champions team.

I’ve read about microservices even before they became hype. It was the famous article from Martin Fowler that drew my attention to them. Then I continued with some sporadic research on the topic to find out that they are fancy implementation of Domain Driven Design’s bounded contexts. At that time I was keen to try them, but my day job was in a different area.

What brought me back to the topic was the spawning of the MicroProfile project mid 2016. There was (and maybe there still is) a common understanding that you can only do microservices with frameworks like NodeJS, but not in Java and especially in Java EE. As I am a passionate fan of standard Java technologies (I would like to avoid the Enterprise Java term, as it brings a lot of bad and wrong associations), I embraced the initiative with a lot of enthusiasm. Had a few contributions to the sample conference app, that was used to showcase MicroProfile 1.0.

But as I don’t consider myself expert in any of the microservice paradigms, I was not actively involved in the development of the specifications, that were created in the next months and years. So I thought that a next logical step for me would be to start a step-by-step guide, which can be used to introduce those specification to the rest of the development world. I was joined in that effort by my Bulgarian JUG fellow and friend Dmitry. And here we are, presenting at Voxxed Days Microservices in Paris alongside all the experts and together with the MicroProfile rockstars Emily and Antoine.

During this one day workshop, what should the attendees expect? What would they learn?

The second thing that you hear after grasping the microservice paradigm are the different microservice terms and patterns: resilience, fault tolerance, circuit breaker, bulkhead, asynchronous communication, etc. You read about them, the next day you forget what you learned, read again, remember it for a couple more days, etc. until you really try it. So the goal of the workshop is to guide everyone in developing a distributed application consisting of five services (running on five different MicroProfile implementations). And thus helping the participants get a real experience in the area.

Of course, MicroProfile it is not only about resilience and fault tolerance. Being stateless is another common trait. That is great, but at the same time we want some kind of role based authentication. Both between the user and the system entry point and between the microservices that call each other. System monitoring (for liveness as well as for key indicators like consumed resources like CPU, memory, threads) is another important part of a microservice architecture. And last but not least things like easy externalized configuration, RESTful endpoint documentation, tracing calls that span multiple services and a lot more.

The great thing is that MicroProfile capable runtimes provide the above mentioned features just like that. So during the workshop we will see how they can be applied with standard Java technologies having WildFly Swarm, IBM Open Liberty, Payara Micro, Apache TomEE and Hammock operating together.

So people come to your workshop, design, code and deploy several microservices… but would they be able to end-to-end test their microservices? Testing microservices is hard, right?

Ah, testing, my favorite topic. Well, when it comes to testing microservices with MicroProfile, I would say that I don’t feel that comfortable.

Testing an isolated microservice might be relatively easy. You fire it up somehow (more about this in a bit) and with the help of libraries like Rest Assured you can fairly easy assert on calling their endpoints and getting back responses. Well, it would be easy if it was just testing a particular microservice in isolation. But it always has its collaborators, which are no longer part of the same deployment: they are running on servers of their own (if they are not serverless of course ;)).

Firing up the microservice under test is an issue of its own. In the standard Java world we have Arquillian, which is a great tool. But it is a bit hard to bootstrap the first time. I consider myself seasoned Arquillian user and it always takes me some time to set it up for a new project. And once it is set up, you have to pay the penalty of either waiting for your microservice runtime to boot for each test suite, or spend some more time for configuring a remote server.

And there are a lot of people among the MicroProfile users and developers that have gone through the same pain. There was a famous blog by Voxxed Day Microservice’s organizer Antonio Goncalves. The positive thing that the discussion within the community about simplifying the initial cost for running integration tests has already started. That is why I believe that at least this hurdle will soon be tackled.

So, will we do end-to-end testing in the workshop? Unfortunately not. It is a topic that desires its own workshop.

But who knows, maybe next year. 🙂

Sounds good, see you soon then

Thank you so much for having me at you great conference! See you all soon!

#microservices #MicroProfile #resilience

Twitter: @ivan_stefanov

Check the other workshops