Dive into Microservices Architecture - Part I

Introduction

Internet of Things (IoT) is an emerging technology which requires a fully decentralized software architecture which can be developed (from the software point of view), deployed, discovered, and requested more reliably, and flexible. Since service orientation is a suitable software architecture for IoT, and Microservices Architecture (MSA) is a new paradigm in Service-Orientated Softwares, I found writing this article useful and hope it can bring you to a level of understanding that you can dive into the MSA more deeply.

This article is going to have serveral parts so I will put link to the next part at the end of text. Part I will discuss the Microservices Architecture (MSA) and will try to explain the basic concepts of MSA and its advantages and disadvantages. 

Background

Service Oriented Architecture (SOA) shifted distributed systems to a new paradigm. It made building a platform independent piece of software call it module easily achievable. What SOA did, its ancestors such as Remote Procedure Call (RPC), Distributed Computing Environment (DCE), Distributed Component Object Model (DCOM), Component Object Request Broker Architecture (CORBA), and Object-Oriented Architecture could not. However, SOA was built on top of OOA and tried to bring the OOA to one more upper level in Software Architecture by distributing the objects over a network of connected devices and transferring them between different machines and systems as a structured message such as Simple Oriented Access Protocol (SOAP).

Microservices Architecture

Microservices Architecture (MSA) is built on top of SOA and tried to strip away unnecessary levels of complexity in order to narrow down functionality and bring up more interoperability and flexibility to implemented services. Therefore, Microservices Architecture introduces a very narrowly functionalized, small, independent, bounded context, and individual services.

Granularity

Service Oriented Architecture does not define any granularity criteria to create a service except suggesting to make coarse-grained services, so each service can have as much as functions to share with other services. For example, imagine a Web Service that provides Credit business. For such service, often several functionalities are being implemented all in one service. On the other side, MSA has by nature fine-grained services. However, the definition for being a fine-grained or coarse-grained service in MSA is quite different than SOA. In SOA granularity has horizontal perspective while in MSA it has vertical perspective. This means, in MSA, a service can contain functions from all layers of an application without violating the fine-grained criteria.

Note: The term Granularity does not have any precise definition in SOA, most of the times related references either are not giving a very exact definition of this term except relying on vague words or they just refer to the number of functions and features exposed by the service. Anyway, it seems that this characteristic is a tradeoff between several other characteristics such as loss coupling, complexity, reliability and etc.

Size

Size of service in MSA is comparatively small versus service in SOA but there is no really solid measurement to find the best size. Some people argue that the size of the service development team can compose the size of the service. Some other suggests using the number of coding lines, features, and similar characteristics. Finding the right size for each service is so important because a very small size can drop down the overall system reliability.

Bounded Context

SOA tries to share as much as possible, for example for the same Credit business service, is reasonable to let service to have a notion of Account, Customer, Credit Policies, Authentication, and Authorization, etc. Thus, there will be several infrastructure services and application services shared with the Credit business service in order to elaborate for handling a received request by accessing to database, network, and other shared resources and functionalities. Whereas, MSA tried to share as less as possible by not letting services know about their internal functionalities and isolating them via the use of interfaces and messages oriented scenarios. Thus, for the same example, MSA may define independent services. Domain Driven Design (DDD) may boost your service bounded context characteristic.

Independence/Self-containment

A microservice is individually deployable and operationally independent from the other services. This means a microservice contains everything that it needs to fulfill its tasks on its own. This includes not also the business logic but also all the required libraries. The only way to communicate with a microservice is through its published interfaces and proxies.

Service Composition

While providing elaborated functionalities by services in SOA needs service orchestration (figure on right) or choreography (figure on left), MSA is being benefited only from service choreography which does the same responsibility in more freedom. Service orchestration is a centralized approach which makes the entire system a single point of failure, means if the service which has orchestration responsibility like a Service Aggregator failed will affect overall reliability of the system and may prevent the system from achieving the goal. On the other hand, in service choreography, there is no instance to make sure that all required actions done successfully. This is still an open question that requires more research and investigation. Might be consensus algorithms such as Paxos can be useful in this part.

Service Discovery

Unlike SOA, in MSA having a proper service, discovery is not mandatory, it depends on the number of services that are going to be operational. Sometimes even a simple API gateway, Service-pool, or even a configuration file can make all services aware of each other.

Individual Storage

In MSA, each service has its own storage strategy regardless of other services, it is responsible for storing all the necessary information that it needs to pursue its tasks. In fact, this characteristic of MSA stripes away the complexity of handling Data-Flow Paradigms in SOA.

Advantages and Disadvantages

Every system at the end is a trade between a set of cons and pros and this is up to the system engineer to make the right choice according to his system characteristics. To make this more clear, imagine the business of cutting down a tree. There are a few tools that all have cutting functionality, like, a saw, a knife, and an e-Saw. But, the question is which one has better efficiency?

Effectiveness (e) = Efficiency (e) x Performance (p)

The above equation means if efficiency or performance is zero, then the effectiveness will also be zero. Thus, we always need to keep eyes on P and E at the same time. The following is a short list about MSA advantage and disadvantages.

Advantages

1. Decentralized and Decoupled Architecture, using choreography rather than orchestration makes services publish-subscribe based and as a result fully decentralized
2. Do one thing and do it well (Unix philosophy), more focused and singular with very narrow functionality
3. Easy to have parallelism and load balancing, because of being more fine-grained from the business process point of view
4. Statelessness, however, having a stateful Microservice is valid but it is not the ideal
5. Individual data storage makes services relaxed to keep tracing the data-flow
6. Easy and automated deployment and discovery due to use of container engine-based technologies such as docker
7. More interoperability, which makes services able to have more flexibility in accepting/dropping a new/current service or protocol
8. Fully compatible with Representational state transfer (REST) which allows creating stateless services
9. Suitable for discrete systems, for example for batch automation process

Disadvantages

1. Service synchronization, keeping services synchronized in a cooperative way
2. Difficult to find systematic problems, for example, finding a problem in a chain of business activities when there is a logical error in the process is more difficult and it requires to combine several log files into one piece
3. Automated deployment and discovery is a must when the number of microservices is more than a few
4. Difficult to find the right service granularity, which can lead the entire system into instability due to overwhelmed network communication and error rations
5. Challenging when the business system is not discrete enough, like continues process control
6. Developing an automated test is significant difficult than monolithic systems

Since the next part of this article will discuss the following titles in more detail, I would just only give a brief summary.

Suitable Protocols and Architectures

HTTP: "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems." (RFC 2068)

Representational State Transfer (REST): REST is not a protocol, neither a software standard. REST is a software architecture that discusses building stateless software modules such as web services that are communicating over a stateless protocol such as HTTP (or from my opinion any similar protocol that supports statelessness end-to-end). Note that when we are talking about statelessness, in fact, we are smoothly referring to the set of MSA characteristics like Granularity, Self-containment, Bounded context, and Individual storge.

Suitable Frameworks and Interfaces

Nancy: A riverfront city in the northeastern French. The daughter of Frank Sinatra. An umbrella project that contains all necessary components for a lightweight, low-ceremony, framework for building HTTP based services on .NET and Mono. All these three definitions are correct, more information can be found here.

OWIN: Is an interface to decouple .NET web servers and .NET web applications to reduce the complexity and make easy use of HTTP.sys in web applications. You can read more about the OWIN Framework on Part II of this article.

Go to Next Part