05/11/2018 Dive into Microservices Architecture - Part I - CodeProject

Dive into Microservices Architecture - Part I

Aydin Homay, 31 Oct 2018

Internet of Things requires fully decentralized platforms which can be developed, deployed, discovered, and requested more easily.

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 two parts. Part I will discuss the Microservices Architecture (MSA) and will try to explain the basic
concepts of MSA and its advantages and disadvantages. Part II will introduce a simple implementation of MSA by using OWIN and
Nancy.

Background
"Do one thing, and do it well."
The Unix Philosophy, McIlroy

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 is 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.

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I?display=Print 1/5
05/11/2018 Dive into Microservices Architecture - Part I - CodeProject

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.

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I?display=Print 2/5
05/11/2018 Dive into Microservices Architecture - Part I - CodeProject

Service Choreography vs Service Orchestration

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.

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I?display=Print 3/5
05/11/2018 Dive into Microservices Architecture - Part I - CodeProject

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. Please have a look here to read more about the OWIN.

License
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I?display=Print 4/5
05/11/2018 Dive into Microservices Architecture - Part I - CodeProject

Aydin Homay
I am an eternal programmer.
Software Developer (Senior) BHGE
Germany

Comments and Discussions

4 messages have been posted for this article Visit https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-
Architecture-Part-I to post and view comments on this article, or click here to get a print view with messages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile Article Copyright 2018 by Aydin Homay
Web06-2016 | 2.8.180920.1 | Last Updated 31 Oct 2018 Everything else Copyright © CodeProject, 1999-2018

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I?display=Print 5/5