adam bien's blog

Grzegorz, please introduce yourself

My name is Grzegorz Huber and I'm a software developer at www.consdata.com. There are other titles that change depending on my current role in different projects, but I prefer the down-to-earth description instead.

What are you currently building?

We're building a mailbox application for one of the banks here in Poland. The idea is to give clients a better tooling for their needs to contact the bank whether it's a support question or a complaint. Obviously this also means integrating with internal bank mechanisms and now clients are receiving their bank statements in a much more convenient way. It probably sounds boring because we've all been using emails for years. However, designing your own messaging application turns out to be quite a challenge especially when everyone just keeps on saying just do it like Google does ;-). The domain is simple, yes, but the scale of the system make things much more challenging. Plus it's not only for messaging. We're currently integrating our mailbox application with some of our other products that add more functionalities like internet forms and automated workflow. Most of the features have already been implemented and I'm still in awe that our whole backend is under 20k lines of code. And people say Java makes your systems big.

After the Java EE Microservices workshop at MUC Airport in January you decided to refactor your current application towards pure Java EE Microservices. What is the progress?

Actually, It was a brand new application and we started in late February so the timing was perfect for us. The current progress is 10 microservices. I guess that's one way to describe our "advancement". Using other metrics we're currently in performance testing and getting closer to the production stage. That's for my current project. The side effect is a very small change within our organization that's about to take it's ripple effect to a whole new level.

How many microservices comprise your application / system?

Currently ten, but it was our first time and there were some disbelievers, who were skeptical at first, plus the learning curve so we definitely see there could be more closer to 15.

Which application servers, tools or IDEs are you using?

The most interesting is probably the Java EE part of the whole architecture where we decided to use Payara, Payara Micro, Embedded Payara for testing. Obviously is many ways inspired by the training in Munich. On top of that we developed our own installation platform based on Docker, which help us manage different parts of our application.

How big is your WAR?

It's between 3 and 8 MB. We're not super light, but we're very happy with the final result. Some compromises had to be made. For example we decided to use lombok, which adds almost 2MB to each war. Logback and its dependencies add another 700KB. Plus our db backends use mybatis, which adds almost 2MB as well. We like this strategy anyway... we try to keep these values in check and we consciously select what should be provided by the Jave EE container and what should be included with our application. I would like to be able to go with the javaee-api alone, but that's not possible ;-).

Here's the full report ;-)

3,7M lip 18 15:15 statics.war
7,0M lip 18 15:15 messages.war
8,0M lip 18 15:15 integration.war
7,0M lip 18 15:15 messages-sendmass.war
5,7M lip 18 15:15 users.war
3,4M lip 18 15:15 facade.war
5,5M lip 18 15:15 templates.war
3,8M lip 18 15:15 ecm.war
3,9M lip 18 15:15 crypto.war
3,6M lip 18 15:15 accounts.war

How fast is the build?

The whole microservice backend without tests is like 20-30 seconds. I normally don't divide build time with and without tests, but we did something here that should be mentioned. We write basic JUnit test cases in 3 layers... sort of. Layer one are basic junit tests based on mockito for simple business logic tests. Layer two includes real bean tests using CDI injection and everything that's possible within one microservice and using specialization beans that serve as mocks to other microservices. Layer three is the most expensive, but I think the pros are much more important than the disadvantage of extra added time. Our layer 3 test use the embedded Payara Micro, which takes the target wars and tests the real application stuff and including communication between microservices. We have Junit tests that use up to 6 microservice modules depending on the user story. I think that's one of the bigger challenges awaiting those who adopt this architecture so it was really handy to have Payara ready for that. The whole build, the one we use to build upon every commit for pull requests, takes up to 5 minutes at the moment.

Does "stock" Java EE fit well with the microservices idea?

Yep! It seems that it was designed this way and it's asking to be used this way. I really don't know why this approach wasn't picked up faster by developers around the world :).

You are using the porcupine as Bulkhead. Which problem does it solve?

Well, even though Glassfish (and Payara) have built-in monitoring it wasn't what we wanted it to be. Instead with a proper application design and splitting code across different microservices and different executors we were able to get our own dedicated monitoring service via REST plus other small things like named threads for each module. Additionally there's this feeling that you're in complete control over how different modules have different configurations for their own executor services. The added benefit of using Porcupine right away is that when you think about stuff like thread pools at the beginning of your application it's much easier to scale your system in the future.

Are you still happy with Boundary Control Entity?

I don't think we use that in the direct way. We definitely don't use technical names for organizing the core within our microservices and our approach is still based on the business responsibilities of the classes.

Any major challenges so far?

Apart from different approach to testing, which I think we tackled head on, the biggest challenge is probably some sort of microservice registry that's we're still missing in our project. Using Docker helps here a little bit, but when you get 10+ microservices and you really want to use them independently it's good to have something this figured out. One of the main reason why I came across your training was an idea to replace OSGi with something lighter. Microservices are indeed lighter, but you still have to manage them on your own. There are many solution that help with that, but I feel we need to be careful here, cause adding a registry is a good idea, but it can't become a single point of failure for us.

Any closing thoughts on Java EE and microservices?

It's nice to be able to design modules in such way that the main application operation is designed to work 24hrs per day and other heavy operation, which may bring instability to the system are in separate modules on different servers with different boundaries.

That's nearly impossible with a monolith and usually it's too late. In our case we had 9 microservices at one point and the 10th was brought to life when we realized that our core business logic is so fast and small that it runs smoothly on 1GB of RAM and the other module is doing this big batch operations and needs additional 6-8GB of RAM. It would be ill-advised to run them both together on a 8GB RAM system.

Business-wise both modules send messages. The microservice way of thinking let's you split code not only using domains but ever further when there are other benefits like performance and stability.

Is you company hiring Java (EE) developers?

Yes, checkout: kariera.consdata.pl/

Can you share any resources with us?

Here you can learn more about our software www.consdata.com. Feel free to contact me at ghuber@consdata.pl if you have any questions.