Microservices mishaps: 1 query, multiple DBs

I want to share my experience with the latest trend in software engineering - microservices.

In particular, I want to explain a case I recently stumbled upon which made us hate the strategy we've got of splitting the big monolithic application to microservices.

The use case is relatively simple - one wants to make a query concerning multiple entities. They have relations between them nevertheless, the data ideally should be owned by separate microservices in an autonomous way.

The example:

Let's say that the product is a ERP-like and naturally we would have entities like company and invoices. Naturally, we'd went for microservice for the company - let's name it company-srv and one for invoices - invoice-srv. Both of these should own the APIs and DB

Now what happens when we want to make a query that is something like:

Get all companies with more than 1000 invoices

or slightly more complex example:

Get all invoices that haven't sent email-report last month for the companies that have this feature enabled.

How do you handle such responsibility - is it in invoice-srv's ownership and it should have a dependency on the other services? How do you keep the performance high with increased row count?

Even if you handle this with additional relations between the 2 DBs between the autonomous services, let's add another more interesting factor to the situations.

The more complex (and quite common) example:

Let's try to intertwine permissions - let's say that the user who is trying to see the results of the above queries, doesn't have permissions for some of the companies? Or even more intriguing - for some of the branches of the companies...

Whose responsibility is it to orchestrate the query? Does it become a multi-query operation? Is there going to be a permissions-srv ? What about performance?  Pagination?

...

All these are questions we ask when we pick microservices. Otherwise, it would have been a simple JOIN in the monolithic approach....

Are we going backwards? :)

PS:
more on the topic this cool post: https://www.javacodegeeks.com/2016/07/hardest-part-microservices-data.html 

Gradle Daemon - boost your build performance

You use Gradle and want to speed up a bit your build time? Nobody wants to wait for compilation, assembly etc. Let's try this easy to setup performance boost:

If you enable Gradle Daemons, you can actually reuse the Gradle context that you've just created for your subsequent builds! It basically doesn't completely kill the process when a Gradle build finishes, but reuses the common framework classes and thus improving build time.

I've tried it on my projects and the improvement was from a 40s build down to 20s on subsequent builds !

Here's what you need to do and know:

touch ~/.gradle/gradle.properties && echo "org.gradle.daemon=true" >> ~/.gradle/gradle.properties

• enables Gradle daemon for all your projects by default (don't worry you can turn it off for individual projects as well)
  
• if you use multiple Gradle versions, a different daemon is created for each one! This is a potential deal-breaker for some developers, but a good reason to align all your projects to a single version of Gradle.

• in case you want to recreate the daemon, you can stop them all using:

./gradlew --stop

And that's it!

For more info check the dedicated page:
https://docs.gradle.org/current/userguide/gradle_daemon.html 

JDK 7 new features (part 1)

Hi there,

We all know Java. Many love it, some dislike it, other actually hate it... and if they knew its weaknesses and flaws as I know some of them, well, they'd pity all the Java developers for choosing such a fragile platform and language...

 So basically , before you thought I hate Java, the thruth is just the opposite - check this blog's name :) - but I admit that Java has some veeeery bad treats and design flaws.

But why am I talking about Java flaws in a posting called "Java 7 new features" -- well , because they(the guys behind Java) try to address some of these problems , I'm also going to point some of them to you..

 
This list is not ordered by me - everywhere I look these features are presented in this order. I'll keep it that way for consistency.

Feature: 64/32 bit pointers support 
-- why store 32bit pointers in 64bit space, when you don't need it. The JVM will be more agile and not create empty spaces in the pointers, so less space will be required, which will help the traffic more than a local system with gigabytes of RAM. Performance boost.

Feature: Garbage-first Garbage Collection
- kills the young fast-dying generation first. and preserves objects that have survived the wipe a few times.
Result: more GC options and strategies -- performance boost.


Feature: dynamic languages in JVM
-- All can agree that Dynamic languages have big future ahead of them and that's a good reason that Java should try to adopt them and try to run them natively on a JVM. Thus making the JVM something like a universal VM for different kinds of languages. Imagine the freedom to combine different languages and techniques easily with native support and not some simulators.... no performance problems ... no interoperability problems... I really hope this is going to be implemented very professionally.

Added support for lambda functions, which could revolutionize some known patterns in the Java world - creation of an anonymous class for an interface like MouseListener and so on - now you can create a lambda implementation, pass it as an argument and inside it can be executed. This will make our Java a more interesting place. The anonymous-class design that was being forced because of the lack of such a feature and it's not intuitive at all. Let's see where this will get us.

Feature: Java modularity - Project Jigsaw
This project, in my opinion, will be an improvement, which will improve our Java experience. But what exactly is the problem? What do you mean with "Java modularity" ? Java is already modular, some will say... Well, it isn't.

Just check your local JRE installation and see in the \lib\  directory the rt.jar (rt = runtime). Notice the size - using latest JDK 1.6 Update 21, the rt.jar is around 47 MB.

Yeah, 47 MB and that's a module... yeah right. Nice design, guys! Many classes must be written with lots of lines to fill those 47 MB and believe me - these 47MB in rt.jar are all classes. Who wants to say how many millions of code...

But why when I only use java.net and java.lang should my JVM also load SWING and java.beans and javax.xml ... The sad reason is that all of them are all TIGHTLY coupled...

Somehow, somebody let it all loose control and everybody started pushing shit in this .jar file... well it works, so who cares? It's not modular... again, who cares? You can't easily extract a piece of it and place it elsewhere. You can't manage your JVM RAM requirements because of required modules being all stick together and you can't separate them.

Image that you can modify your JVM depending on your business case !
Well, project JIGSAW is trying to solve exactly this problem - separating all swing, applet etc modules into separate sub-projects and decomponentizing the  rt.jar into several (hundred?) jar files.

I imagine something like a ( JVM + OSGi ) ... yeah :)

I wish the developers good luck, because of the issues that could arise, and I think it's not a trivial job.
Remember they also have to maintain the backwards operability somehow...

...
I see that this post has become very long, so I'm going to continue it later.

Feel free to comment, because my view on a topic could be very wrong, but I'd love if you start a discussion. Especially when the topic is Java :)

Leni Kirilov