Microservice Architecture

In the continuation of the Microservice 101, this page will discuss about the various aspects of Microservices, including SOA vs Microservice, patterns of microservice architecture.
The three golden rules of Microservices are (3Cs of Microservice):

  • Componentize
  • Collaborate
  • Connect

Componentization of single application into multiple serviceable components is the most important activity. Best would be to start by defining a RESTful API to access this service, then plan and create an implementation using comfortable development language and platform.  (A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. Source: https://searchmicroservices.techtarget.com/definition/RESTful-API )

Communication among bigger teams becomes complex, which results in numerous mistakes and curbing the speed of development. Collaboration among teams focuses around API contracts and Technology standardization.

Connecting various APIs requires more than the development of the constituent components. These components must be connected, presentation layer and additional services must be layered in, then the completed application must be delivered to users, given that microservices must communicate using APIs.

Microservice VS Service-Oriented Architecture 

Main difference between SOA vs Microservice is the size, and scope. Microservice can be considered as a subset of SOA (Service-Oriented Architecture).

SOA (Service Oriented Architecture) MSA (Microservice Architecture)
Built on the idea of “share-as-much-as-possible” architecture approach Built on the idea of “share-as-little-as-possible” architecture approach
More importance on business functionality reuse More importance on the concept of “bounded context”
Common governance and standards Relaxed governance, with more focus on people collaboration and freedom of choice
Uses enterprise service bus (ESB) for communication Uses less elaborate and simple messaging system
Supports multiple message protocols Uses lightweight protocols such as HTTP/REST & AMQP
Common platform for all services deployed to it Application Servers not really used. Platforms such as Node.JS could be used
Multi-threaded with more overheads to handle I/O Single-threaded usually with use of Event Loop features for non-locking I/O handling
Use of containers (Dockers, Linux Containers) less popular Containers work very well in MSA
Maximizes application service reusability More focused on decoupling
Uses traditional relational databases more often Uses modern, non-relational databases
A systematic change requires modifying the monolith A systematic change is to create a new service
DevOps / Continuous Delivery is becoming popular, but not yet mainstream Strong focus on DevOps / Continuous Delivery


Keywords: #DevOps, #decoupling, #microservices #SOA #ContinousDelivery #Scalability #Agility #Applications #ServiceOrientedArchitecture