Jumping Back and Forth in a Microservices Environment - Part 1
So whats the best choice of language for writing Microservices.
Hmm..If you were a beginner in the mciroservices 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 choice of language
Well, thats what I was; a 10 year+ veteran programmer.
These were my arguments for convincing myself of choosing Java.
1.Java is mature
2.Java is cross platform.
3.Java is OOP.
4.Hell, Java 8 is even functional.
5.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 4 years older to me. Ted considered himself to be a language agnostic programmer and we frequently debate on various topics from time to time.
This was my conversation with Ted.
Ted: Man, node rocks. Node is built using the V8 runtime. So its going to be superfast for IO bound tasks.
Me: IO- Bound tasks. what are they?
Ted: Well, your application/microservice that you build is normall 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 retreiving data from dabases,other systems which use network calls or 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..
Well, 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 Node, 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: Whats that?
Ted: Well, with Node,you write your code in a reactive manner, to acheive the same with Java you would need to create callbacks and stuff which would make your code ugly like Homer Simpson.
Me: Well, not true..There are libraries like RxJava with which you can acheive the same result as Node.
Ted: True as a convinience 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 didnt have a retort here. Ted had a valid point. I went back to my desk to find if Java had something which could imporve 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 micro services all the way.
I though to myself - "So Java still has a place for CPU bound operations". Then I saw a new guy on my team with a logo on his shirt..- Go Rocks..
That's for the next post.