{"id":82379,"date":"2018-10-03T19:00:17","date_gmt":"2018-10-03T16:00:17","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=82379"},"modified":"2023-12-11T14:38:03","modified_gmt":"2023-12-11T12:38:03","slug":"microservices-java-developers-monoglot-polyglot","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2018\/10\/microservices-java-developers-monoglot-polyglot.html","title":{"rendered":"Microservices for Java Developers: Monoglot or Polyglot?"},"content":{"rendered":"

<\/a>1. Introduction<\/h2>\n

Along the previous parts of the tutorial we have talked quite a lot about the benefits of the microservice architecture<\/a>. It is essentially a loosely coupled distributed system which provides a particularly important ability to pick the right tool for the job. It could mean not just a different framework, protocol or library but a completely different programming language.<\/p>\n

\n

Table Of Contents<\/h3>\n
\n
1. Introduction<\/a><\/dt>\n
2. There is Only One<\/a><\/dt>\n
3. Polyglot on the JVM<\/a><\/dt>\n
4. The Language Zoo<\/a><\/dt>\n
5. Reference Application<\/a><\/dt>\n
\n
\n
5.1. Customer Service<\/a><\/dt>\n
5.2. Inventory Service<\/a><\/dt>\n
5.3. Payment Service<\/a><\/dt>\n
5.4. Reservation Service<\/a><\/dt>\n
5.5. API Gateway<\/a><\/dt>\n
5.6. BFF<\/a><\/dt>\n
5.7. Admin Web Portal<\/a><\/dt>\n
5.8. Customer Web Portal<\/a><\/dt>\n<\/dl>\n<\/dd>\n
6. Conclusions<\/a><\/dt>\n
7. What\u2019s next<\/a><\/dt>\n<\/dl>\n<\/div>\n

In this part we are going to discuss the monoglot and polyglot microservices<\/a>, the value each choice brings to the table and hopefully come up with the rational conclusions to help you make the decisions. Also, we will present the architecture of the reference application we are about to start developing. Its main purpose is to serve as the playground for numerous further topics we are going to look at.<\/p>\n

<\/a>2. There is Only One<\/h2>\n

Over the years many organizations have accumulated tremendous expertise around one particular programming language and its ecosystem, like for example Java, the subject of our tutorial. They have skilled developers, proven record of successful projects, in-depth knowledge of certain libraries and frameworks including the deep understanding of their quirks and peculiarities. Should all of that be thrown away in order to adopt the microservice architecture<\/a>? Is this knowledge even relevant or useful?<\/p>\n

Those are very hard questions to answer since many organizations get stuck with very old software stacks. Making such legacy systems fit the microservice architecture<\/a> may sound quite impractical. However, if you have been lucky enough to bet on the frameworks and libraries we have discussed in the previous part of the tutorial<\/a>, you are pretty much well positioned. You may certainly look around for better, modern options but starting with something you already know and familiar with is a safe bet. And frankly speaking, things do evolve over time, you may never feel the need to get off the Java train or your favorite set of frameworks and libraries.<\/p>\n

There is nothing wrong with staying monoglot and building your microservices<\/a> all the way on Java. But there is a trap where many adopters may fall into: very tight coupling between different services which eventually ends up with a birth of the distributed monolith<\/a>. It stems from the decisions to take a shortcuts and share Java-specific artifacts (known as JAR<\/a>s) instead of relying on more generic, language-agnostic contracts and schemas.<\/p>\n

Even if you prefer to stay monoglot, please think polyglot!<\/p>\n

<\/a>3. Polyglot on the JVM<\/h2>\n

Beside just Java, there are many other languages which natively run on JVM, like for example Scala<\/a>, Kotlin<\/a>, Clojure<\/a>, Groovy<\/a>, Ceylon<\/a> to mention a few. Most of them have an excellent level of the interoperability with the code written in the plain old Java so it is really easy to take the polyglot microservices<\/a> route staying entirely on JVM platform. Nonetheless, since everything is still packaged and distributed in JAR<\/a>s, the danger to build the distributed monolith<\/a> remains very real.<\/p>\n

While touching upon development of the polyglot applications on the JVM, it is unforgivable not to mention the cutting edge technology which came out of Oracle Labs<\/a> and is bearing the name GraalVM<\/a>.<\/p>\n

\n

GraalVM<\/em><\/a> is a universal virtual machine for running applications written in JavaScript, Python 3, Ruby, R, JVM-based languages like Java, <\/em>Scala<\/em><\/a>, <\/em>Kotlin<\/em><\/a>, and LLVM-based languages such as C and C++. <\/em>GraalVM<\/em><\/a> removes the isolation between programming languages and enables interoperability in a shared runtime. It can run either standalone or in the context of <\/em>OpenJDK<\/em><\/a>, <\/em>Node.js<\/em><\/a>, Oracle Database, or MySQL. – <\/em>https:\/\/www.graalvm.org\/<\/em><\/a><\/p>\n<\/blockquote>\n

In the spirit of the true innovation, the GraalVM<\/a> opens whole new horizons for the JVM platform. It is not ready for production use yet (still in the release candidate phase as of today) but it has all the potential to revolutionize the way we are building the applications on the JVM, especially the polyglot ones.

<\/div> <\/div><\/p>\n

<\/a>4. The Language Zoo<\/h2>\n

In the industry driven by hype and unrealistic promises, the new shiny things appear all the time and the developers are eager to use them right away in production. And indeed, the microservice architecture<\/a> enables us to make such choices regarding the best language or\/and framework to solve the business (or even technical) problems in a most efficient manner (but certainly does not mandate doing that).<\/p>\n

In the same vein of promoting responsibility and ownership it looks logical to let the individual teams make the technological decisions. The truth is though in reality it is quite expensive to deal with the zoo of different languages and frameworks. That is why if you look around, you will see that most of the industry leaders bet on 2-3 primary programming languages, an important observation to keep in mind while evolving your microservices<\/a> implementations.<\/p>\n

<\/a>5. Reference Application<\/h2>\n

To shift our discussions from the theory to practice, we are going to introduce the reference project we are about to start working on. Unsurprisingly, it is going to be built following the guiding principles of the microservice architecture<\/a>. Since our tutorial is Java-oriented, most of our components will be written in this language but it is very important to see the big picture and realize that Java is not the only one. So let us roll up the sleeves and start building the polyglot microservices<\/a>!<\/p>\n

Our reference project is called JCG Car Rentals<\/strong>: a simplistic (but realistic!) application to provide car rental services to the various customers. There are several goals and objectives it pursues:<\/p>\n