This document discusses microservices architecture. It begins by describing earlier platform architectures like monolithic and SOA. Microservices architecture breaks applications into small, independent services that can be updated independently. Key characteristics include domain-driven design, single responsibility, separate data stores, and horizontal scaling. Microservices use techniques like API gateways, service discovery, and containers to provide flexibility, scalability, and reliability compared to earlier architectures.

1. Microservices
Auxenta Tech Talk ­ March 2017
Crishantha Nanayakkara
(@crishantha)

2. Platform 1.0Platform 1.0Platform 1.0Platform 1.0
Platform 2.0Platform 2.0Platform 2.0Platform 2.0
Platform 3.0Platform 3.0Platform 3.0Platform 3.0
(1980s to 1990s)
(2000 ­ 2010)
(2010 onwards)

3. Platform 3.0Platform 3.0Platform 3.0Platform 3.0
●
Processing Data in the Cloud (Cloud Computing)
●
Integrate mobile devices with the enterprise APIs
●
Incorporate new sources of data to the Internet of
things (IoT)
●
Manage and share data that has high volume (Big
Data)
●
Turn the data into usable information through
analytics (Big Data Analytics)
●
Ability to build software cheaply and fast, deploy it
instantly (DevOps)
­ The Modern Generation

4. Reference: Microservices: The resurgence of SOA principles and an alternative to the monolith (PWC)
Monolithic / SOA / Microservices

5. Monolithic Architecture
Reference: Getting Started with Microservices – By Arun Gupta

6. Monolithic solutions are built, tested and
deployed as one large body of code, typically
across a set of servers or Virtual Machine
instances, in order to provide scale and
Performance.
Monolithic Architecture

7. 7
Service Oriented Architecture (SOA)
Source: Open Source SOA

8. 8
Service Oriented Architecture (SOA)

9. 9

10. 10
Source: http://www.idevnews.com/views/images/uploads/general/talend_intfactory.jpg
Enterprise Integration Patterns

11. Enterprise Service BusEnterprise Service Bus
Cloud Infrastructure
48 Ministries 60 Departments 8 Provincial
Councils
271 DS Offices
Application
Application
Services
Application
Services
32 Provincial
Ministries
16 Provincial
Departments
Application
Services
Message
BrokerBPS
Service
Registry
An Example ­ SOA
Smart Pipe

12. “Gartner predicts that by 2017 over 20% of large
organizations will deploy self­contained
microservices”
Microservices

13. “Microservice is a new software development
architectural approach that has grown to
increase the speed and efficiency of developing
and managing the software solutions.”
Microservices

14. “Microservices are self­contained units of
functionality with loosely coupled dependencies
on other services and are designed, developed,
tested and released independently”
Microservices

15. Is Microservices SOA?
Source: https://www.youtube.com/watch?v=wgdBVIX9ifA

16. Key Characteristics
1. Domain Driven Design (DDD) ­ Stateless
2. Single Responsibility Principle (SRP)
3. Having a separate data store
4. Autonomy (Service is full­stack and has the control of the all
the components – ui/middleware/persistence/ transactions /
database)
5. Published Service Contracts (Swagger /RAML)
6. Container based Deployment (independent, lightweight)
7. Lightweight Communications (REST/HTTP, Websockets)
8, Dumb Pipes, Smart Endpoints
9. Horizontal Scaling (Y­Scale)

17. Domain Driven Design (DDD)
Bounded context : Explicit boundary within a domain.

18. Domain Driven Design (DDD)

19. 19
Private Sector Companies
Services
Application
Services
Application
The Department of Motor Traffic
Vehicle Domain
Services
Application
The Department Registration of Persons
Personal Domain
Services
Application
The Land Ministry
Land Domain

20. Each microservice has to maintain and own the
data and no other service can access the data
without the knowledge of the responsible
microservices.
Single Responsibility Principle (SRP)

21. Central Database Decentralized Database
Separate Data Stores

22. Hide your Database

23. Scale the whole application Scale based on the demand/ traffic
Horizontal Scaling

24. Dumb Pipes, Smart Endpoints

25. Dumb Pipes, Smart Endpoints
●
MSA uses a lightweight message bus or a
gateway with minimal routing capabilities and
acting as a “dumb pipe”
● Services invocation types
– Point­Point Style
– API Gateway Style
– Message Broker Style

26. Point­Point Style
(For simple microservices)
Works only for simple microservices
When the number of microservices increases, things can get complex
As drawbacks, not having a central place to execute non­functional requirements :
­ end­user authentication, throttling, monitoring need to be implemented in
Each Microservice

27. API Gateway Style
(Most widely used)
Works as a lightweight message gateway
Working as the single API entry point for all the clients
Implements common non­functional requirements
­ lightweight message routing, filtering and transformation
­ Implements security, monitoring, throttling

28. Message Broker Style
(For asynchronous messaging)
Used for asynchronous messaging between microservices
Uses standard protocols such as AMQP, MQTT

29. “MSA is an architectural style that structures
A system as a set of collaborative services that
Are organized around business capabilities”
Microservices Architecture (MSA)

30. Microservices Architecture (MSA)
●
Need to focus on how you would scope out a
service that provide a single function rather
than the size.
●
MSA consists of,
– Inner Architecture ­ handles the
implementation of microservices
– Outer Architecture ­ handles the
platform capability that handles the
connectivity, flexibility and scalability

31. MSA
Reference: Getting Started with Microservices – By Arun Gupta

32. ●
It is functionally decomposed where User, Order, and
Catalog components are packaged as separate WAR
files
●
Each component has its own database allowing
microservices to to evolve and choose whatever type
of data store (relational, NoSQL, in­memory, etc)
●
Each component registers with a Service Registry.
This is required because multiple stateless instances of
each service might be running at a given time, and
their exact endpoint locations will be known only at
the runtime (Netflix Wureka)
MSA

33. ●
Components talk each other via API(s) defined for
each component
●
Client interaction for the application is defined in
another application (shopping cart UI), which
discovers the services from the “Service Registry”.
MSA

34. Microservices Classification

35. Source: Best Practices for Microservices – A Whitepaper by MuleSoft
Microservices Classification

36. Microservices Design Patterns
(Command Query Responsibility Segregation)
●
Most requests to micro­services are to retrieve
information for presentation purposes
●
A lesser number for state changing services
●
Depend on the high traffic of the service they
can be separated into separate micro­services
– One for retrievals
– One for state changing updates

37. Microservices Design Patterns
(Aggregator)
Aggregator can be a simple web page that can invoke multiple services to achieve the
Functionality.
Can also be a composite mcroservice, which can be reused by others as well.

38. Microservices Design Patterns
(Chained)
Produces a single consolidated response to a request.

39. Microservices Design Patterns
(Branch)
Allows simultaneous response processing from two or more mutually exclusive
Microservices.
You may use a composite microservice for this invocation.

40. Microservices Design Patterns
(Shared Resources)
While migrating from monolithic to microservices design, sometimes you
Have to use a shared data store.
Can be an anti-pattern, but sometimes its useful

41. Microservices Design Patterns
(Async Messaging)
The reliability can be ensured with the help of Messaging Queues.

42. Microservices Security
API Manager/
Gateway
API Manager/
Gateway
Micro Services
Identity Server
Access Token
JWT
JWT

43. Transactions in Microservices
●
MSA encourages the “transaction­less” coordination
between microservices
●
Transactions should be applicable for only within the
scope of the microservice
●
Handling Ttransactions orchestrated with multiple
microservices can be difficult
●
e.g: Credit card bill payment
– Debit Savings bank account
– Credit to Credit Card account

44. Transactions in Microservices
●
Compensating Transactions (Can be synchronous/
asynchronous)
– If one microservice fails, the “upstream”
microservices should be undone using
respective compensating operations

45. Orchestration with Microservices
Orchestration at
Microservice Level
Orchestration at
Gateway Level
RECOMMENDED

46. The “Outer” Architecture
(The Ecosystem)
An “outer” architecture can consists of,
– An API Gateway (Dumb Pipe)
– A Service Registry (for service
discovery)
– A Messaging Channel (To connect to
legacy systems)

48. Microservices and API Gateway
API Manager/
Gateway
API Manager/
Gateway
Micro Services

49. Microservices and API Gateway
●
Design and Deployment flexibility
●
Security and Access Control
●
Monitoring and Analyzing
●
Manage traffic
●
Enforcing Policies (throttling)
●
Extension points – (mediation, security,
workflow, etc)

50. Microservices and ESB
●
MSA does not recommend to use ESB as service
orchestration, routing and transformation as an
integration platform
●
Encourage to decouple them by applying them to
other components such as microservices.
●
However, having a complete MSA is not possible to
large systems, unless the enterprise systems are built
from scratch
●
Hence, it is required to maintain a hybrid solution
haing both MSA + an ESB platform to connect other
legacy systems

51. Microservices and ESB

52. Microservices Deployment

53. Microservices Deployment
●
The requirement
– Ability to deploy/undeploy independently on
other services
– Ability to scale out at the microservices level
based on the traffic they get
– Ability to deploy quickly
– Failure in one microservice will not effect
others

54. Microservices Deployment
●
The solution
– Docker (docker.com)
●
Each microservice can Package, Deploy, Scale
using Docker and it’s faster than normal Vms
– Kubernetes – (kubernetes.io)
●
Managing a “docker container cluster” as a
single system especially for large scale
deployments

55. 55
Source: http://www.zdnet.com/article/what­is­docker­and­why­is­it­so­darn­popular/

56. Microservices Deployment

57. Migration
●
Start with a cloud transformation strategy
(container based)
●
Have two branches 1) Monolithic 2)
Microservices
●
Divide the scope and create business unit
teams, whom can work independently
●
Have a Devops strategy for each team
●
Have an iterative strategy and migrate the
whole system. [It will take time]

58. Netflix started Microservices implementation with the Cloud Migration

59. Thank YouThank You
Crishantha NanayakkaraCrishantha Nanayakkara
Twitter: @crishanthaTwitter: @crishantha
Web Site: Web Site: www.crishantha.comwww.crishantha.com
LinkedIn: http://linkedin.com/in/crishanthaLinkedIn: http://linkedin.com/in/crishantha