"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
Introduction to Micro Services
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