This is a brief introduction to a new style of architecture also called as micro-service architectural style.

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

2. 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. 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
Functionaldecomposition
Scaling Cube