Microservices? What?
This project is entirely influenced by microservice architecture. It's crucially important to grasp its meaning and its goals. In this section a brief introduction of this architecture is given.
[for sake of simplicity microservice will be referred to ms/MS from now on]
The basis of MS is based as on being against monolithic application. That is to say, an application is to be divided into different modules, preferably small modules, each doing a small subset of processes. Sounds simple, doesn't it?
What you probably already do is very encouraging and admirable, but, the thing about MS is that it is not only concerned about an application's file/module structure. If fact, it also suggest a Distributed deployment scheme for these tiny modules. Why is this useful, you might ask:
-
It eliminates the problems of large-scale monolithic applications. We all know how frustrating and nasty it could go. A big team working on a single (even bigger) code base is a time-bomb. Soon or late, something is going to go horribly wrong.
-
On the Other hand, we can split our one tiny module, into sub-services (aka microservices). by sub-service, we mean truly independent modules that only communicate with each other over a messaging protocol (HTTP etc.). This by itself is a great benefit for big organizations maintaining large scale applications. Henceforth, each module can be developed independently, tested and deployed independently.
-
Most importantly, it enables us to scale independently. That is to say, we can deploy and scale each MS on a separate cluster of machines (or a single machine), whit task-specific hardware, without having any impact on other parts of our system. Consequently, this will make the system more resilient. In other words, if one part of the system, entirely or partially crashes, there is a good chance that the rest of the system can keep working, regardless of the failure. This can only cause a section of our data/system to be wrong/inconsistent.