Is There a Right Language for Microservices Development?
Wondering what language is best for microservices? Don't start a fight, look at the facts. Let's compare Java to Node and other languages.
Join the DZone community and get the full member experience.Join For Free
So, what's the best choice of language for writing microservices?
If you were a beginner in the microservices world, but a seasoned professional or have a manager/senior developer/lead who has been in the industry for a long time, Java would be the language of choice.
That's what I was; a 10+ year veteran programmer.
These were my arguments for convincing myself to choose Java:
Java is mature.
Java is cross-platform.
Java is OOP.
Hell, Java 8 is even functional.
I have done some initial groundwork and the defacto standard framework for Microservices is Spring boot which runs on the JVM.
So there I was, typing away in Java. I was all smug and strutting as if I had made the best choice in town when I spotted Ted, who was four years older than me. Ted considered himself to be a language-agnostic programmer and we frequently argued on various topics.
This was my conversation with Ted:
Ted: Man, Node rocks. Node is built using the V8 runtime, so it's going to be super fast for IO-bound tasks.
Me: IO-bound tasks, what are they?
Ted: Well, your application/microservice that you build is normally either CPU- or IO-bound. CPU-bound means it does a lot of intensive calculations. IO-bound, on the other hand, means it does something simple like retrieving data from databases, other systems which use network calls, and such.
Java, by default, blocks a thread when it runs IO, so Java is going to be slow for IO-bound tasks. On the other hand, look at this beautiful Node, written all in a not-blocking way and all. What that means is that Node is single-threaded (single-threaded in terms of code that you write to be precise). Every time you execute an IO call, Node does not block the main thread but submits the IO tasks to be run by the Runtime's internal IO daemon threads.
So Node wins in terms of IO-bound tasks, and since your application is mostly IO-bound, you should be replicating everything with Node.
Me: Wait wait, not so fast...Java has support for non-blocking IO, and there are libraries for making async HTTP calls. Apache Async HTTP Client comes to mind, for one. Also, most DB drivers for Java support async HTTP. Plus, Java gives me type safety, and with Java 8, I also get functional programming using lambda. So, Java is both OOP and functional. It supports both paradigms.
Ted: Well, not so fast. what about callback hell and reactive paradigms of Node?
Me: What's that?
Ted: Well, with Node, you write your code in a reactive manner. To achieve the same with Java, you would need to create callbacks and stuff, which would make your code ugly like Homer Simpson.
Me: Not true - there are libraries like RxJava with which you can achieve the same result as Node.
Ted: That's true as a convenience mechanism, but you cant beat Node's performance, as IO was what it was born to do within the Chrome browser.
Me: Partly convinced...Ted, do you have anything else?
Ted: Umm, yes...Node's startup times are minimal as compared to Java's JVM, which makes it ideal to be used in a serverless paradigm, as you can reduce your AWS bill by a huge amount.
I didn't have a retort here. Ted had a valid point. I went back to my desk to find out if Java had something which could improve the startup times. I saw that with Java 9, Oracle had already started moving in that direction, using Ahead of Time compiling and modular Jars.
What that means is with Java 9, you have the option to compile your code ahead of time, which would improve startup time. Also, you could reduce your memory footprint by only including libraries that you use.
I went back to Ted. Ted grinned as he and I both knew the truth. This looked more like a last-ditch attempt by Java to reclaim ground lost to Node. Serverless, with its promise, has caused the Java behemoth to reinvent itself once more.
Whats my plan, you ask? Node for IO-bound services all the way.
I thought to myself, "So Java still has a place for CPU bound operations." Then I saw a kid on my team with a logo across his shirt..."Go Rocks."
Continued in the next post...Stay tuned.
Opinions expressed by DZone contributors are their own.