Micro-Service Architecture

by Shashi Shekhar

“The system is not working.

That is how a paradigm shift

begins: the established way of

seeing the world no longer

functions.” – Matthew Fox.

This article describes the increasingly popular Micro-

service architecture pattern. The term "Micro-service

Architecture" has sprung up over the last few years to

describe a particular way of designing software

applications as suites of independently deployable

services.

Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers. The trending act is to adapt Micro-Services based architecture, as was adapted by Netflix when they moved from a single large war file deployment to a more fluid and flexible, out-of-process service deployments. To understand micro-service architecture, it is important to first understand the limitations of monolithic applications.

Case Study:

For the purpose of this discussion, consider an example of an airline portal, providing key services to their web desktop users including flight information, internet booking, member service like loyalty programs and recommendation service that suggest best possible offers based on user’s preference, membership type and previous site visits. Current Monolithic Application Architecture Since the earliest days of developing applications for the web, the most widely used enterprise application architecture has been one that packages all the application’s server-side components into a single unit. Many enterprise applications consist of a single deployment

bundle (for e.g. .war or .dll file). For this airline web-portal, the server side components like Flight Info Service and Member

Service has been identified, that are bundled as one large deployable bundle. This approach works well for small applications as this simplifies the process of development, testing and deployment. However, the monolithic architecture becomes unwieldy for complex applications. Some of its limitations are: Obstacle to frequent deployment

There are long QA cycles and release time

Least frequent feature releases

High risk of failure with every release

Nervous Developers

Large & complex code base

Intermingled dependencies

Mutated integrity

Overloaded IDE and Containers

Refactoring takes minutes

Builds take hours

Testing in continuous integration takes hours

Inflexible Scalability

Scalability through replication only behind the load-balancer.

Replication at application level and not at feature level.

Obstacle to Feature Enhancements

Team follows communication structure of organization (Conway’s law)

Developers become specialists on specific application layer

Communication between teams is biased by layer experience (or lack thereof)

Long-term Commitment to a technology Stack

Binding to one technology stack

Layer wise distribution of technology stack

Therefore, Micro-Services (MS) Paradigm shift

From single large application to a suite of self-contained services

Each MS self-contained with its resource representation and data management

Each MS with autonoumy on technology stack and data repository

Independent deployability of MS, implying no shared state and inter-process communication through service communication layer

Each MS handling one resource (verb), e.g flight related MS, booking related MS.

Characteristics of Micro-services are: Application as a suite of services

Each software component identified as a MS (micro-service)

MS segregated on the basis of Single Responsibility Principle

Each MS functionally complete with resource representation and data management

Each MS as a separate deployable unit running in a separate process

MS Communication

Smart end-points and dumb communication points

Choreographed using simple RESTish protocol excluding BPEL, WS-Choreography

Focus on light messaging over message bus Decentralized Governance

Internal architecture of each MS

Cross-functional team owning a MS from design & development to application support & enhancement

Freedom of choice for technology selection

Each MS has its own software repository

Data models conceptualized specific to a MS

Each MS managing its own database

Design for failure

Application can tolerate failure of MS

Emphasis on real-time monitoring of MS availability

Sophisticated monitoring and logging of MS

3-D Scalability Model

Y-axis scaling (Functional decomposition)

Partition of application by Verb or Use-case

Independent service based change release

Independent service based deployment X-axis scaling (Functional replication)

X-axis scaling through cloning/replication

Apply x-axis cloning to each service independently

Z-axis scaling (Data Localization)

X-axis scaling through slicing of data and

localization of data-set

Independent scale-out of specific data-set Client-Service Communication (API Gateway)

API gateway will be the single point of entry

Client specific APIs (Web and Mobile clients have their own specific APIs)

Protocol translation through API gateway

Services published at the gateway for client access

Gateway act as mediator for services, abstracting fine grained services into coarse-grained service call

Inter-Service Communication

Services can interact through synchronous

HTTP based mechanism like REST or SOAP

Fault tolerant asynchronous message based mechanism like AMQP based message broker

Comparison with service-oriented architecture SOA system also focuses on system

decomposition, but unlike MS, SOA services are not self-contained with data and UI

SOA is concentrated on further decomposing business layer into a separate service orchestration layer

SOA focuses mainly on business agility unlike MS that focuses primarily on functional clustering and independent deployment units

MS can be seen as “SOA – the good parts”

Challenges with MS implementation Complexity of developing & testing a

distributed system

Multiple database and transaction management

Developing and deploying features that span multiple services requires careful co-ordination

Refactoring would be much harder with remote communication between services

Moving code would be difficult across service boundaries

In case services not identified properly, the complexity would simply shift from inside component to the interaction between components

Requires paradigm shift in how team looks at software development

Horizontal replication Fu

nctio

na

l de

com

po

sitio

n

Scaling Cube