Innovations of computations for the java.pptx

innovation

1. Innovations

2. 4.1 Introduction Along the previous parts of the tutorial we have talked quite a lot about the benefits of the microservice architecture . 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. In this part we are going to discuss the monoglot and polyglot microservices , 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.

3. There is Only One 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 ? Is this knowledge even relevant or useful? 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 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 , 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. There is nothing wrong with staying monoglot and building your microservices 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 . It stems from the decisions to take a shortcuts and share Java-specific artifacts (known as JAR s) instead of relying on more generic, language-agnostic contracts and schemas

4. The Language Zoo 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 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). 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 implementations.

5. Reference Application 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 . 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 ! Our reference project is called JCG Car Rentals : a simplistic (but realistic!) application to provide car rental services to the various customers.