Micro services Architecture

Micro Services Architecture
CSI – IT2020, IIT Mumbai, October 6th 2017
Computer Society of India, Mumbai Chapter
Araf Karsh Hamid : Co-Founder & CTO, MetaMagic Global Inc., NJ, USA
Twitter / Skype / LinkedIn : arafkarsh Email : araf.karsh@metamagic.in
A Micro Service will have its own Code Pipeline for build and deployment functionalities and it’s scope will be defined
by the Bounded Context focusing on the Business Capabilities and the interoperability between Micro Services will be
achieved using message based communication.

Pioneers in Microservices Implementation
10/8/2017 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 2
New Entrants

Agenda
10/8/2017 3
• Pros and Cons
• Micro Services Characteristics
• Monolithic Vs. Micro Services Architecture
• SOA Vs. Micro Services Architecture
• App Scalability Based on Micro Services
• Hexagonal Architecture
Architecture Styles1
• Domain Driven Design
• Event Sourcing & CQRS
• Functional Reactive Programming
Design Styles2
• CAP Theorem
• Distributed Transactions : 2 Phase Commit
• SAGA Design Pattern
• Scalability Lessons from EBay
• Design Patterns
• References
Scalability3
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA

Pros
1. Adds Complexity
2. Skillset shortage
3. Confusion on getting the
right size
4. Team need to manage
end-to-end of the Service
(From UI to Backend to
Running in Production).
10/8/2017 4
1. Robust
2. Scalable
3. Testable (Local)
4. Easy to Change and
Replace
5. Easy to Deploy
6. Technology Agnostic
Cons
Pros and Cons1

Micro Services Characteristics
5
1
By James Lewis and Martin Fowler
We can scale our operation independently, maintain
unparalleled system availability, and introduce new services
quickly without the need for massive reconfiguration. —
Werner Vogels, CTO, Amazon Web Services
Modularity ... is to a technological economy what
the division of labor is to a manufacturing one.
W. Brian Arthur,
author of e Nature of Technology
The key in making great and growable systems is much more
to design how its modules communicate rather than what
their internal properties and behaviors should be.
Alan Kay, 1998 email to the Squeak-dev list
Components
via
Services
Organized around
Business
Capabilities
Products
NOT
Projects
Smart
Endpoints
& Dumb Pipes
Decentralized
Governance &
Data Management
Infrastructure
Automation
Design for
Failure
Evolutionary
Design

Micro Services System Design Model
Service
(Micro)
Process &
Tools
CultureOrganization
Solution
(Macro)
10/8/2017 6
Service: Focuses on a specific Business
Capability
Process & Tools: Development, Code
Deployment, Maintenance and Product
Management
Culture: A Shared set of values, beliefs by
everyone. Ubiquitous Language in DDD is
an important aspect of Culture.
Organization: Structure, Direction of
Authority, Granularity, Composition of
Teams.
Solution: Coordinate all inputs and
outputs of multiple services. Macro level
view of the system allows the designer to
focus more on desirable system behavior.
1
The very first step of a
service design process is to
design the process itself.
Marc Stickdorn, author of
This is Service Design
Thinking

10/8/20177
Monolithic vs. Micro Services Example
Traditional Monolithic App using
Single Technology Stack
Micro Services with Multiple Technology Stack
Existing
aPaaS
vendors
creates
Monolithic
Apps.
This 3 tier
model is
obsolete
now.
Source:
Gartner
Market
Guide for
Application
Platforms
Nov 23, 2016
Event Stream
API Gateway (Zuul Edge Server)
Load Balancer (Ribbon)
Circuit Breaker (Hysterix)
Service Discovery (Eureka)
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
4
EE 7
Inventory
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
1
Customer
SE 8
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
3
ShoppingCart
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
2
Order
1
UI Layer
WS
BL
DL
Database
ShoppingCart
Order
Customer
Inventory

10/8/2017
8
SOA vs. Micro Services Example
Traditional Monolithic App with SOA
Micro Services with Multiple Technology Stack
Event Stream
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
1
Customer
SE 8
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
3
ShoppingCart
UI Layer
Web Services
Business Logic
Database Layer
Micro
Service
2
Order
1
API Gateway
Load Balancer
Circuit Breaker
Service Discovery
Load Balancer
Circuit Breaker
Load Balancer
Circuit Breaker
UI Layer
Database
ShoppingCart
Order
Customer
Inventory
Enterprise Service
Bus
Messaging
REST / SOAP
HTTP
MOM
JMS
ODBC / JDBC
Translation
Web Services
XML
WSDL
Addressing
Security
Registry
Management
Producers
Shared
Database
Consumers3rd Party Apps

10/8/2017 9
App Scalability based
on micro services
architecture
Source: The NewStack. Based on the Art of Scalability by By Martin Abbot
& Michael Fisher
1

Scale Cube and Micro Services
1. Functional
Decomposition
2. Avoid locks by
Database Sharding
3. Cloning Services

10/8/2017 11
Hexagonal Architecture
Ports & Adapters
The layer between the Adapter and
the Domain is identified as the Ports
layer. The Domain is inside the port,
adapters for external entities are on
the outside of the port.
The notion of a “port” invokes the
OS idea that any device that adheres
to a known protocol can be plugged
into a port. Similarly many adapters
may use the Ports.
Source : http://alistair.cockburn.us/Hexagonal+architecture
https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net
Services
for UI
Ports
File
system Database
Order Tracking
JPA Repository
Implementation
Adapters
OrderProcessing
Domain Service
(Business Rules)
Implementation
Domain
Models
Domain Layer
Order Data
Validation
OrderService
REST Service
Implementation
OrderProcessing
Interface
p
Order Tracking
Repository
Interface
p
A
A
External
Apps
A
A A
Others
A
A
OrderService
Interface
p
Web
Services
Data
Store
Use Case Boundary
Bounded Context
A
1

• Domain Driven Design
• Understanding Requirement Analysis
• Bounded Context
• Context Map
• Aggregate Root
• Event Sourcing & CQRS
• CRUD
• ES and CQRS
• Event Sourcing Example
• Functional Reactive Programming
• 4 Building Blocks of RxJava
• Observable and Observer Design Pattern
• Comparison : Iterable / Streams / Observable
• Design Patterns : Let it Crash / SAGA
Design Styles2
It’s not necessary that
you need to use all
these patterns. You
will be using these
based on your
technical requirement

Domain Driven Design
10/8/2017
13
Source: Domain-Driven Design Reference by Eric Evans
2

Understanding Requirement Analysis using DDD
08 October 2017 14
Ubiquitous
Language
Vocabulary
shared by all
involved parties
Used in all forms of
spoken / written
communication
Ubiquitous Language using BDD
As an insurance Broker
I want to know who my Gold Customers are
So that I sell more
Given Customer John Doe exists
When
he buys insurance ABC for
$1000 USD
Then He becomes a Gold Customer
2

Understanding Requirement Analysis using DDD
08 October 2017 15
Bounded
Context
Areas of the
domain treated
independently
Discovered as you
assess requirements
and build language
2

DDD : Understanding Bounded Context
08 October 2017
16
Source: BoundedContext By Martin Fowler :
http://martinfowler.com/bliki/BoundedContext.html
• DDD deals with large models by
dividing them into different
Bounded Contexts and being explicit
about their interrelationships.
• Bounded Contexts have both
unrelated concepts
• Such as a support ticket only
existing in a customer support
context
• But also share concepts such as
products and customers.
• Different contexts may have
completely different models of
common concepts with mechanisms
to map between these polysemic
concepts for integration.
2

DDD : Context Map
08October2017
17
Source: Domain-Driven Design Reference by Eric Evans
2

Understanding Aggregate Root
18
Order
Customer
Shipping
Address
Aggregate
Root
Line Item
Line Item
Line Item
*
Payment
Strategy
Credit Card
Cash
Bank Transfer
Source: Martin Fowler : Aggregate Root
• An aggregate will have one of its component
objects be the aggregate root. Any references
from outside the aggregate should only go to the
aggregate root. The root can thus ensure the
integrity of the aggregate as a whole.
• Aggregates are the basic element of transfer of
data storage - you request to load or save whole
aggregates. Transactions should not cross
aggregate boundaries.
• Aggregates are sometimes confused with
collection classes (lists, maps, etc.).
• Aggregates are domain concepts (order, clinic visit,
playlist), while collections are generic. An
aggregate will often contain multiple collections,
together with simple fields.
125
Domain
Driven
Design
2

Designing and Fine Tuning Aggregate Root
08October2017
19
Source : Effective Aggregate Design Part 1/2/3 : Vaughn Vernon
http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf
Aggregate Root - #1 Aggregate Root - #2
Super Dense Single Aggregate Root
Results in Transaction concurrency issues.
Super Dense Aggregate Root is split into 4
different smaller Aggregate Root in the 2nd
Iteration.
Working on different design models helps the developers to come up with best
possible design.
2

CRUD and CQRS
10/8/2017 20
Presentation
Services
Business Logic
Data Access
Data Store
UpdatesQueries
Traditional CRUD Architecture
Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
https://blogs.msdn.microsoft.com/maarten_mullender/2004/07/23/crud-only-when-you-can-afford-it-revisite
• A mismatch between the read and write
representations of the data.
• It risks data contention when records are locked in
the data store in a collaborative domain, where
multiple actors operate in parallel on the same set of
data. These risks increase as the complexity and
throughput of the system grows.
• It can make managing security and permissions
more complex because each entity is subject to both
read and write operations, which might expose data
in the wrong context.
CRUD Disadvantages
2

Event Sourcing & CQRS (Command and Query Responsibility Segregation)
• In traditional data management systems, both
commands (updates to the data) and queries
(requests for data) are executed against the same
set of entities in a single data repository.
• CQRS is a pattern that segregates the operations
that read data (Queries) from the operations that
update data (Commands) by using separate
interfaces.
• CQRS should only be used on specific portions of a
system in Bounded Context (in DDD).
• CQRS should be used along with Event Sourcing.
10/8/2017
(C)COPYRIGHTMETAMAGICGLOBALINC.,NEWJERSEY,USA
21
MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx |
Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
CQS :
Bertrand Meyer
Axon
Framework
For Java
Java Axon Framework Resource : http://www.axonframework.org
Greg
Young
2

Event Sourcing and CQRS Design Example
08 October 2017
22
Domain
The example focus on a concept of a Café which tracks the visit of an individual or group to the café. When people
arrive at the café and take a table, a tab is opened. They may then order drinks and food. Drinks are served
immediately by the table staff, however food must be cooked by a chef. Once the chef prepared the food it can then
be served.
Events
• TabOpened
• DrinksOrdered
• FoodOrdered
• DrinksCancelled
• FoodCancelled
• DrinksServed
• FoodPrepared
• FoodServed
• TabClosed
Commands
• OpenTab
• PlaceOrder
• AmendOrder
• MarkDrinksServed
• MarkFoodPrepared
• MarkFoodServed
• CloseTab
Exception
• CannotCancelServedItem
• TabHasUnservedItem
• MustPayEnough
Commands are things that indicate requests to
our domain. While an event states that
something certainly happened, a command may
be accepted or rejected.
An accepted command leads to zero or more
events being emitted to incorporate new facts
into the system. A rejected command leads to
some kind of exception.
An important part of the modeling process is
thinking about the things that can cause a
command to be refused.
Aggregates
• A Single Object, which doesn’t reference any
others.
• An isolated Graph of objects, with One object
designated as the Root of the Aggregate.
An Event Stream which is an
immutable collection of events up
until a specific version of an
aggregate.
The purpose of the version is to
implement optimistic locking:
Source:http://cqrs.nu/tutorial/cs/01-design
2

Functional Reactive Programming
10/8/2017 23
ResilientElastic
Message – Driven
1. A responsive, maintainable &
Extensible application is the goal.
2. A responsive application is both
scalable (Elastic) and resilient.
3. Responsiveness is impossible to
achieve without both scalability and
resilience.
4. A Message-Driven architecture is the
foundation of scalable, resilient, and
ultimately responsive systems.
Value
Means
Form
Principles What it means?
Responsive thus React to users demand
Resilient thus React to errors and failures
Elastic thus React to load
Message-Driven thus React to events and messages
Source: http://reactivex.io/
Responsive Maintainable Extensible
2

4 Building Blocks of RxJava
08 October 2017 24
Source of Data Stream [ Sender ]Observable
Listens for emitted values [ Receiver ]Observer
Client Server
Request
Response
Traditional Synchronous Pull
Communications
1. The Observer subscribes (listens) to the Observable
2. Observer react to what ever item or sequence of items the Observable emits.
3. Many Observers can subscribe to the same Observable
Observer Observableon Next
on Completed
on ErrorTime
Subscribes
Non Blocking
Time
1
2
2

4 Building Blocks of RxJava
08 October 2017 25
Schedulers
Operators
Content Filtering
Time Filtering
Transformation
Schedulers are used to manage and control
concurrency.
1. observeOn: Thread Observable is executed
2. subscribeOn: Thread subscribe is executed
Operators that let you
Transform, Combine,
Manipulate, and work
with the sequence of
items emitted by
Observables
3
4
2

Observable Design Pattern (Marble Diagram)
08 October 2017
26
• An Observer subscribes to an Observable.
• Then that observer reacts to whatever item or sequence of items the
Observable emits.
1
Building
Block
Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html | http://rxmarbles.com
2

Observable / Observer Design Pattern
08 October 2017 27
• Allows for Concurrent Operations: the
observer does not need to block while
waiting for the observable to emit values
• Observer waits to receive values when
the observable is ready to emit them
• Based on push rather than pull
1 & 2Building Block
Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html
2

What’s missing from GOF Observer Pattern
08 October 2017
28
1
Building Block
Source:http://reactivex.io/intro.html
1. The ability for the producer to signal to the consumer that
there is no more data available (a foreach loop on an
Iterable completes and returns normally in such a case; an
Observable calls its observer’s onCompleted method)
2. The ability for the producer to signal to the consumer that
an error has occurred (an Iterable throws an exception if
an error takes place during iteration; an Observable calls
its observer’s onError method)
3. Multiple Thread Implementations and hiding those details.
4. Dozens of Operators to handle data.
2

Compare Iterable Vs. Observable
08 October 2017
29
Observable is the asynchronous / push
dual to the synchronous pull Iterable
• Composable: Easily chained together
or combined
• Flexible: Can be used to emit:
• A scalar value (network result)
• Sequence (items in a list)
• Infinite streams (weather sensor)
• Free from callback hell: Easy to
transform one asynchronous stream
into another
Observables are:
Event
Iterable
(Pull)
Observable
(Push)
Retrieve Data T next() onNext(T)
Discover Error
throws
Exception
onError
(Exception)
Complete !hasNext() onComplete()
1Building Block
2

Comparison : Iterable / Streams / Observable
08 October 2017 30
1Building Block
First Class Visitor (Consumer)
Serial Operations
Parallel Streams (10x Speed)
Still On Next, On Complete and
On Error are Serial Operations
Completely Asynchronous
Operations
Java 8 – Blocking CallJava 6 – Blocking Call Rx Java - Freedom
2

Observer<T> Contract
08 October 2017 31
Methods:
• onNext(T)
• onError(Throwable T)
• onCompleted()
onError / onCompleted called exactly once
2Building Block
X
|
Time Line
2

RxJava Scheduler Details
08 October 2017 32
Source: http://reactivex.io/documentation/scheduler.html
• If you want to introduce multithreading into your cascade of Observable
operators, you can do so by instructing those operators (or particular
Observables) to operate on particular Schedulers.
• By default, an Observable and the chain of operators that you apply to
it will do its work, and will notify its observers, on the same thread on
which its Subscribe method is called.
• The SubscribeOn operator changes this behavior by specifying a
different Scheduler on which the Observable should operate.
TheObserveOn operator specifies a different Scheduler that the
Observable will use to send notifications to its observers.
3Building Block
2

08 October 2017 33
Functional Reactive Programming : Design Patterns
Single
Component Pattern
A Component shall do ONLY one thing,
But do it in FULL.
Single Responsibility Principle By DeMarco : Structured
Analysis & System Specification (Yourdon, New York, 1979)
Let-It-Crash
Pattern
Prefer a FULL component restart to
complex internal failure handling.
Candea & Fox: Crash-Only Software (USENIX HotOS IX, 2003)
Popularized by Netflix Chaos Monkey. Erlang Philosophy
Saga
Pattern
Divide long-lived distributed
transactions into quick local ones with
compensating actions for recovery.
Pet Helland: Life Beyond Distributed Transactions CIDR 2007
2

• CAP Theorem
• Distributed Transactions : 2 Phase Commit
• SAGA Design Pattern
• Scalability Lessons from EBay
• Design Patterns
• References
Scalability3

CAP Theorem
by Eric Allen Brewer
08October2017
35
Pick Any 2!!
Say NO to 2 Phase Commit 
Source: http://en.wikipedia.org/wiki/Eric_Brewer_(scientist)
CAP 12 years later: How the “Rules have changed” : http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
“In a network subject to communication failures, it is impossible for any web service to implement an atomic read / write shared
memory that guarantees a response to every request.”
3

Distributed Transactions : 2 Phase Commit
2 PC or not 2 PC, Wherefore Art Thou XA?
08October2017
36
How does 2PC impact scalability?
• Transactions are committed in two phases.
• This involves communicating with every database (XA
Resources) involved to determine if the transaction will commit
in the first phase.
• During the second phase each database is asked to complete
the commit.
• While all of this coordination is going on, locks in all of the data
sources are being held.
• The longer duration locks create the risk of higher contention.
• Additionally, the two phases require more database
processing time than a single phase commit.
• The result is lower overall TPS in the system.
Transaction
Manager
XA Resources
Request to Prepare
Commit
Prepared
Prepare
Phase
Commit
PhaseDone
Source : Pat Helland (Amazon) : Life Beyond Distributed Transactions Distributed Computing : http://dancres.github.io/Pages/
Solution : Resilient System
• Event Based
• Design for failure
• Asynchronous Recovery
• Make all operations idempotent.
• Each DB operation is a 1 PC
3

SAGA Design Pattern instead of 2PC
10/8/2017 37
Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying
the termination of shorter and more common transactions.
Source: SAGAS (1987) Hector Garcia Molina / Kenneth
Salem, Dept. of Computer Science, Princeton
University, NJ, USA
T1 T2 Tn
Local Transactions
C1 C2 Cn-1
Compensating Transaction
Divide long–lived, distributed transactions into quick local ones with compensating actions for
recovery.
3
Reserve Room
Ticket Payment
Reserve Seat
Flight Ticket & Hotel Booking Example
Room Payment
Rollback Seat Booking
Rollback Room Booking
Rollback Ticket Payment
BASE (Basic Availability, Soft
State, Eventual Consistency)

Scalability Best Practices : Lessons from
Best Practices Highlights
#1 Partition By Function
• Decouple the Unrelated Functionalities.
• Selling functionality is served by one set of applications, bidding by another, search by yet another.
• 16,000 App Servers in 220 different pools
• 1000 logical databases, 400 physical hosts
#2 Split Horizontally
• Break the workload into manageable units.
• eBay’s interactions are stateless by design
• All App Servers are treated equal and none retains any transactional state
• Data Partitioning based on specific requirements
#3
Avoid Distributed
Transactions
• 2 Phase Commit is a pessimistic approach comes with a big COST
• CAP Theorem (Consistency, Availability, Partition Tolerance). Apply any two at any point in time.
• @ eBay No Distributed Transactions of any kind and NO 2 Phase Commit.
#4
Decouple Functions
Asynchronously
• If Component A calls component B synchronously, then they are tightly coupled. For such systems to
scale A you need to scale B also.
• If Asynchronous A can move forward irrespective of the state of B
• SEDA (Staged Event Driven Architecture)
#5
Move Processing to
Asynchronous Flow
• Move as much processing towards Asynchronous side
• Anything that can wait should wait
#6 Virtualize at All Levels • Virtualize everything. eBay created their on O/R layer for abstraction
#7 Cache Appropriately • Cache Slow changing, read-mostly data, meta data, configuration and static data.
08October2017
38
Source:http://www.infoq.com/articles/ebay-scalability-best-practices
3

Summary
10/8/2017 39
1. High Scalable & Resilient
Architecture
2. Technology Agnostic
3. Easy to Deploy
4. SAGA for Distributed
Transaction
5. Faster Go To Market
In a Micro Service Architecture,
The services tend to get
simpler, but the architecture
tends to get more complex.
That complexity is often
managed with Tooling,
Automation, and Process.

10/8/2017 40
Design Patterns are
solutions to general
problems that
software developers
faced during software
development.
Design Patterns3

References
10/8/2017 41
1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014.
2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015.
3. Newman, Sam. Building Microservices. O’Reilly Media, 2015.
4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015.
5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014.
6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014.
7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015.
8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012.
9. Zuul Edge Server, Ketan Gote, May 22, 2017
10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017
11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017
12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017
13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016
14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016
15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015
3

References
Domain Driven Design
16. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans
17. Mar 19, 2013 Domain Driven Design By Eric Evans
18. May 16, 2015 Microsoft Ignite: Domain Driven Design for the Database Driven Mind
19. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World
20. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard
21. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke
22. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson
23. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune
Event Sourcing and CQRS
23. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young
24. Mar 22, 2016 Spring Developer – Building Micro Services with Event Sourcing and CQRS
25. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler
26. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes

References
10/8/2017 43
27. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx
28. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
29. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/
30. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs
31. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer
32. CQS : http://en.wikipedia.org/wiki/Command–query_separation
33. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem
34. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
35. CAP 12 years how the rules have changed
36. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices
37. Pat Helland (Amazon) : Life beyond distributed transactions
38. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw
39. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem
40. Rx Observable : https://dzone.com/articles/using-rx-java-observable
3

References – Micro Services – Videos
41. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s
42. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg
43. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans
44. GOTO 2015 – Challenges Implementing Micro Services By Fred George
45. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer
46. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith
47. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k
48. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans
49. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney
50. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016
51. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles
52. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan
53. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup.
54. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant
55. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula
56. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford.
57. GOTO 2017 – Microservices without Servers. By Glynn Bird.
10/8/2017 44
3

10/8/2017 45
Thank you
Araf Karsh Hamid : Co-Founder / CTO
araf.karsh@metamagic.in
USA: +1 (973) 969-2921
India: +91.999.545.8627
Skype / LinkedIn / Twitter / Slideshare : arafkarsh
http://www.slideshare.net/arafkarsh
https://www.linkedin.com/in/arafkarsh/
http://www.slideshare.net/arafkarsh/software-architecture-styles-64537120
http://www.slideshare.net/arafkarsh/function-point-analysis-65711721
http://www.slideshare.net/arafkarsh/functional-reactive-programming-64780160

UI
Design
Patterns

UI DesignPatterns
MVC/ MVP/ MVVM
47
View
Controller
Model
Passes
calls To
Fire
Events
Manipulates
• The Controller is responsible to process incoming
requests. It receives input from users via the View,
then process the user's data with the help of Model
and passing the results back to the View.
• Typically, it acts as the coordinator between the
View and the Model.
• The Presenter is responsible for handling all UI events on
behalf of the view. This receive input from users via the
View, then process the user's data with the help of Model
and passing the results back to the View.
• Unlike view and controller, view and presenter are
completely decoupled from each other’s and
communicate to each other’s by an interface. Also,
presenter does not manage the incoming request traffic as
controller.
• Supports two-way data binding between View and
ViewModel.
View
ViewModel
Model
Passes
calls To
Manipulates
Updates
Fire
Events
• The View Model is responsible for exposing methods,
commands, and other properties that helps to maintain
the state of the view, manipulate the model as the
result of actions on the view, and trigger events in the
view itself.
• There is many-to-one relationship between View and
ViewModel means many View can be mapped to one
ViewModel.
• Supports two-way data binding between View and
ViewModel.
View
Presenter
Model
Passes
calls To
Fire
Events
Manipulates
Updates1
1
1
*
Model
View
Controller
Model
View
Presenter
Model
View
ViewModel

UI Design Patterns
Flux / Redux
ViewDispatcher
Every action is sent to all Stores via callbacks the
stores register with the Dispatcher
Store
Action
Action
1 *
Controller-Views
• Listens to Store changes
• Emit Actions to Dispatcher
Dispatcher
• Single Dispatcher per Application
• Manages the Data Flow View to Model
• Receives Actions and dispatch them to Stores
Stores
• Contains state for a Domain (Vs. Specific Component)
• In Charge of modifying the Data
• Inform the views when the Data is changed by emitting the
Changed Event.
Flux Core Concepts
1. One way Data Flow
2. No Event Chaining
3. Entire App State is resolved in store before Views Update
4. Data Manipulation ONLY happen in one place (Store).
Actions
• Simple JS Objects
• Contains Name of the Action and Data (Payload)
• Action represent something that has happened.
• Has No Business Logic

UI Design Patterns Redux
Actions
• Simple JS Objects
• Contains Name of the
Action and Data
(Payload)
• Has NO Business Logic
• Action represent
something that has
happened.
Store
• Multiple View layers can Subscribe
• View layer to Dispatch actions
• Single Store for the Entire Application
• Data manipulation logic moves out of
store to Reducers
Reducer
• Pure JS Functions
• No External calls
• Can combine multiple reducers
• A function that specifies how the state changes in response to an Action.
• Reducer does NOT modify the state. It returns the NEW State.
Redux Core Concepts
1. One way Data Flow
2. No Dispatcher compared to Flux
3. Immutable Store
Available for React & Angular
View
Action
State
Dispatcher
Reducer
R R
R
Store
Middleware
Middleware
Middleware
• Handles External calls
• Multiple Middleware's can be chained.

Micro services Architecture

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Similar to Micro services Architecture

Similar to Micro services Architecture (20)

More from Araf Karsh Hamid

More from Araf Karsh Hamid (19)

Recently uploaded

Recently uploaded (20)

Micro services Architecture

Editor's Notes