Reasons for the Evolution: Tiered to SOA, SOA to Microservices
There is a law governing the electronics evolution and the needs to accommodate such evolution, the Moore’s Law.
The complexity for minimum component costs has increased at a rate of roughly a factor of two per year. Certainly over the short term this rate can be expected to continue, if not to increase. Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly constant for at least 10 years.G. Moore, 1965
Microservices are not only a trending Architectural-style, but more. Whenever business services need to serve a plethora of diversified and numerous clients, this is the winning paradigm: i. extreme scalability, ii. extreme decoupling and iii. extreme agility (developers pick the best programming language to develop their own service) are the key points and what a typical service achieves.
Key Features and Differentiators
Let’s discuss the key features and the differentiators that Microservices Architectures propose, and let’s start from a definition of Microservice.
A Microservice is an independent entity that executes a minimal amount of work upon each service call; it is independent because normally it does not have to share neither the persistence support with other Microservices, and communication happens among the boundaries through interfaces and messages passing.
A hierarchy of Microservices normally implement a moderately complex system.
According to the above statements, a Microservice can be seen as a very minimal SOA Component, so minimal to be not constrained by any business rule: a SOA is a Microservices Architecture at a bigger level of granularity, and so Microservices Architectures are SOA at a lower level of granularity (with reference to the responsibility of each component/micro-component). To get the point, let’s consider an example. Normally a SOA component links library to accomplish its own unit of work; libraries resides in the same memory space of the SOA component itself. As opposed, a Microservice can be assimilated to a library detached in an independent process, communicating over the network (for its integration).
It is clear that a Monolith of a 3-Tier Architecture is, in turn, a SOA at a higher granularity: the composed business logic spread over several components lives in the monolith, the same process, the same unit of deploy. Below, from Moving away from the Monolith an interesting Pre-SOA (Monolithic and Tiered Architectures) Vs SOA Vs Microservices view on the timeline that makes sense of the above discussion on the intrinsic property of each singular paradigm.
Tiered and SOA Architectures have been around for a while now, so for the sake of brevity hereafter only the Microservices capabilities are analyzed.
A Microservice is:
- autonomous in implementing a minimal unit of work,
- autonomous in persisting its data,
- autonomous in its implementing programming language,
- autonomous in its deploy.
- communicate with other services exchanging messages over the network,
- its work (and so implemented functionality) may depend on one or more other services.
- its process has not a relatively big footprint.
- normally a single service does not provide a considerable complex functionality, to get that various services have to be orchestrated.
- naturally a Microservice is designed to be plugged into a processing Pipeline.
- its request processing does not depend for the history of the previous requests.
Recapping from above, the key differentiators of a Microservices Architecture:
- lightweight services can be combined very easily and can be replicated with almost 0-effort to scale horizontally according to the demand.
- no dependencies, no common execution environment, no interrelated interfaces means that a Microservice is a very loose coupled unit of execution.
- services’ autonomy (above described) imply degree of freedom for developer to develop and maintain their own Microservices, and in turn freedom is a key incentive of overall agility (intended as ability to react quickly to changing scenarios).
- again, the autonomy above discussed allows to have developers concentrated in developing their own functionalities with very few constraints and/or inter-dependencies, this aspect translates in a much higher velocity.
Worth Watching by Adrian Cockcroft
In this blog post, the Microservices Architecture is compared to the SOA and traditional Tiered one with the aim to provide the reader with a very quick and immediate introduction to an emerging architectural style in developing high scalable distributed systems.