Architectures and Design Patterns · Cloud Comptuing · Distributed Computing

From Monolithic Three-tiers Architectures to SOA Vs Microservices

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
In perspective, the Moore’s Law states that the electronics grow at a very fast pace and with them the technology as well as the technological services. A good example of this conjecture is the today’s Internet and the myriad of services offered through it:  for example, the IoT (Internet of Things) is enabled by the connectivity provided by the Internet and mainly consists in connecting Things, very different from each other, into a mesh of added value services.
Architectural Paradigm Shifts. The growth of the Internet Services has imposed paradigm shifts over the last decades: from the Tiered architectures to SOA, and in turn from SOA to Microservices.
Briefly, a Tiered Architecture separates the Frontend from the Backend, and the Backend from the Data Sources: the layers are as many silos accomplishing a certain job (Frontend has to present data and enable the interactions, Backend mediates between Frontend and Data Sources, and Data Sources provide persistent storage).  A SOA confines into Components similar business logic and integrates distributed components with different integration patterns (components are loosely coupled but singularly accomplishing a defined unit of work, together they can implement the overall functionalities of a complex system). Finally, Microservices are an extreme declination of the SOA Architectural Paradigm in which each Service is an atomic unit of work (to accomplish a piece of work done by a SOA components, normally several services are needed).
SOA_Vs_Microservices
Tiered Vs SOA Vs Microservices

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.

Companies like Netflix and Spotify have a Microservices Architecture serving their resource– and requests-intensive business services that, in the average case, have to scale at the scale.

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.

 

Pre-SOA_Vs_SOA_Vs_Microservices

 

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:

  • Independent,
    • autonomous in implementing a minimal unit of work,
    • autonomous in persisting its data,
    • autonomous in its implementing programming language,
    • autonomous in its deploy.
  • Integrated,
    • communicate with other services exchanging messages over the network,
    • its work (and so implemented functionality) may depend on one or more other services.
  • Lightweight,
    • its process has not a relatively big footprint.
  • Minimal,
    • normally a single service does not provide a considerable complex functionality, to get that various services have to be orchestrated.
  • Pipeline-ready,
    • naturally a Microservice is designed to be plugged into a processing Pipeline.
  • Stateless,
    • its request processing does not depend for the history of the previous requests.

Recapping from above, the key differentiators of a Microservices Architecture:

  • Scalability,
    • lightweight services can be combined very easily and can be replicated with almost 0-effort to scale horizontally according to the demand.
  • Decoupling,
    • no dependencies, no common execution environment, no interrelated interfaces means that a Microservice is a very loose coupled unit of execution.
  • Agility,
    • 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).
  • Cost-effectiveness,
    • 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

Conclusion

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s