12/6/2020

Pioneers in Microservices Implementation

Microservices Architecture Introduction

Application Architecture
Dr. Nguyen Binh Minh New Entrants
Department Information Systems, SoICT

1 2

1
 12/6/2020

11/17/2018
3
Agenda
1 Overview & Infrastructure Architecture 18 3 Scalability 9
• What are Microservices? • Microservices Scalability
• When Should I use them? • CAP Theorem
• What is the right size for a Microservice? • ACID Vs BASE
• Why is Microservices better than Monoliths? • Distributed Transactions
• Infrastructure Architecture • Eventual Consistency: SAGA Pattern
• Scalability Lessons from EBay

2 Software Architecture and Design

31
• Capability Centric Design
• Domain Driven Design
• Event Sourcing & CQRS

3 4

2
 12/6/2020

1 1
What are Microservices? Microservices Characteristics
The microservice architectural style is an approach to developing
Components Organized around Products
• A single application as a suite of small services, via Business NOT
Services Capabilities Projects
• Each running in its own process and
• Communicating with lightweight mechanisms, often an HTTP resource API. Smart Decentralized
Endpoints Governance &
• These services are built around business capabilities and & Dumb Pipes Data Management

• Independently deployable by fully automated deployment machinery.

Design for Evolutionary
Infrastructure
• There is a bare minimum of centralized management of these services, Automation Failure Design

• Which may be written in different programming languages and

The key in making great and growable systems is much more Modularity ... is to a technological economy what We can scale our operation independently, maintain

• Use different data storage technologies. to design how its modules communicate rather than what
their internal properties and behaviors should be.
the division of labor is to a manufacturing one.
W. Brian Arthur,
unparalleled system availability, and introduce new services
quickly without the need for massive reconfiguration. —
Alan Kay, 1998 email to the Squeak-dev list author of e Nature of Technology Werner Vogels, CTO, Amazon Web Services
Source: https://www.martinfowler.com/microservices/ - James Lewis and Martin Fowler

5 6

3
 12/6/2020

1 1
What is the right size for a Microservice? Microservices System Design Model
Service: Focuses on a specific Business
• Rather than the size what matters is the Business Function / Capability
Service
(Micro)
Domain of the service. Process & Tools: Development, Code
Deployment, Maintenance and Product
• One Microservice may have half a dozen entities and other a Management All these concept
Solution of System Design Process &
couple of dozen entities. What’s more important is the role Culture: A Shared set of values, beliefs by (Macro) will be explained Tools
everyone.
Microservices plays. in detailed in
Section 2 Software
Organization: Structure, Direction of Architecture &
• Bounded Context helps you to decompose a large multi Authority, Granularity, Composition of Design
Teams.
domain Monolith into a Microservice for each Bounded
Context. Solution: Coordinate all inputs and
outputs of multiple services. Macro level Organization Culture
• Focusing on User stories will help you clearly define the view of the system allows the designer to
focus more on desirable system behavior.
boundaries of the Business Domain. Marc Stickdorn, author of This is Service Design Thinking

11/17/2018 8
7 8

4
 12/6/2020

1 1
When should I use them (Microservices)? Why is Microservices better than Monoliths?
Microservices
When you have What’s the Cost 1. A monolith is built as a Large Single Unit
and usually composed of the following
• Strong Module Boundaries: Distribution: Distributed systems are harder to • Small autonomous
Microservices reinforce modular 1. A Database (Typically RDBMS)
structure, which is particularly important
program, since remote calls are slow and are services that work
always at risk of failure.
for larger teams. 2. Backend Code (In Java – war/ear file) together.
Eventual Consistency: Maintaining strong
• Independent Deployment: Simple consistency is extremely difficult for a 3. Frontend Code (HTML5 / JSP / ASP) • Loosely coupled with
services are easier to deploy, and since distributed system, which means everyone has Bounded Context.
they are autonomous, are less likely to to manage eventual consistency. 2. Any feature addition requires the entire
cause system failures when they go unit to be deployed. • It’s a natural
wrong. Operational Complexity: You need a mature consequence of applying
operations team to manage lots of services, 3. When we need to scale we need to have
• Technology Diversity: With microservices which are being redeployed regularly. Multiple copies of the entire App.
SRP at Architecture level.
you can mix multiple languages,
development frameworks and data- • Asynchronous
4. Entire App in Single Technology Stack.
storage technologies. Source: https://www.martinfowler.com/microservices/ SRP = Single Responsibility Pattern

9 10

5
 12/6/2020

1 1 Monolithic vs. Micro Services Example

Microservices Architecture

Infrastructure Architecture Micro Services with Multiple Technology Stack

UI Layer API Gateway (Zuul Edge Server) Service Discovery (Eureka)
• API Gateway • Hexagonal Architecture Load Balancer (Ribbon) Load Balancer (Ribbon) Load Balancer (Ribbon)
Circuit Breaker (Hystrix) Circuit Breaker (Hystrix) Circuit Breaker (Hystrix)
• Service Discovery • Domain Driven Design This 3 tier
model is
obsolete SE 8 EE 7
now.

• Config Service • Event Sourcing Source:

UI Layer UI Layer UI Layer UI Layer

Shopping Cart
Gartner Web Services Web Services Web Services Web Services
Market

Customer

Inventory
• Event Bus / Streams • Functional Reactive
Guide for Business Logic Business Logic Business Logic Business Logic

Order
Application
Platforms Database Layer Database Layer Database Layer Database Layer
Nov 23, 2016 Database
• Service Mesh Programming Micro
Service
Micro
Service
Micro
Service
Micro
Service
1 2 3 4
Traditional Monolithic App using
Single Technology Stack
Event Stream

11 12

6
 12/6/2020

1 SOA vs. Micro Services Example 1 API Gateway Other Services

3rd Party Apps Consumers • Hystrix (CB) is used to wrap calls to our
• Authentication and Security: identifying
origins, which allows us to shed and
Micro Services with Multiple Technology Stack authentication requirements for each resource. prioritize traffic when issues occur.
API Gateway Service Discovery • Dynamic Routing: dynamically routing requests • Ribbon (LB) is our client for all
Load Balancer Load Balancer Load Balancer
to different backend.. outbound requests from Zuul, which
Circuit Breaker Circuit Breaker Circuit Breaker • Stress Testing: gradually increasing the traffic. provides detailed information into
network performance and errors, as
• Load Shedding: allocating capacity for each well as handles software load
SE 8
type of request and dropping requests. balancing for even load distribution.
UI Layer UI Layer UI Layer
• Insights and Monitoring: tracking meaningful • Turbine aggregates fine-grained

Shopping Cart
Web Services Web Services Web Services
data and statistics. metrics in real-time so that we can
Customer

Business Logic Business Logic Business Logic

quickly observe and react to problems.
• Static Response handling: building some
Order
Database Layer Database Layer Database Layer
responses directly. • Archaius handles configuration and
Micro Micro Micro
gives the ability to dynamically change
Service
1
Service
2
Service
3 • Multi region Resiliency: routing requests across properties.
Traditional Monolithic App with SOA
AWS regions. Source: https://dzone.com/articles/spring-cloud-netflix-zuul-edge-serverapi-gatewayga

Event Stream

13 14

7
 12/6/2020

1 1 Micro Services Deployment Model

Service Mesh – Sidecar Design Pattern
Users
Customer Microservice Order Microservice HTTP Server
All UI Code is
Micro Services with Multiple Technology Stack bundled
UI Layer UI Layer
API (Zuul) Gateway

Process 1
Business Logic Business Logic
LB = Ribbon LB = Ribbon LB = Ribbon LB = Ribbon Config
Web Services Web Services Server
CB = Hystrix CB = Hystrix CB = Hystrix CB = Hystrix (Spring)
Application Localhost calls Application Localhost calls
http://localhost/order/processOrder http://localhost/payment/processPayment
SE 8 SE 8
SE 8 Service
UI Layer UI Layer Discovery
Network Stack Network Stack

Process 2
UI Layer

Service Mesh
UI Layer
Service Mesh

Sidecar
Sidecar

(Eureka)

Shopping Cart
Service
Microservice CB LB SD Mesh CB LB SD Web Services Web Services
Web Services Web Services

Customer
Product
Data Plane Calls Business Logic Business Logic
CB – Circuit Breaker Business Logic Business Logic
Router Router

Order
LB – Load Balancer Database Layer Database Layer Database Layer
Database Layer
SD – Service Discovery
Micro
Service Discovery Calls Micro Service 1 Service Micro Service 3 Micro Service 4 Virtual
With 4 node cluster 2 With 2 node With 2 node
Control Plane will have all the rules for Routing and Private
Cluster cluster
Service Discovery. Local Service Mesh will download the
rules from the Control pane will have a local copy. Network
Event Stream

15 16

8
 12/6/2020

1 1
Microservices Pros and Cons Summary – Micro Services Intro
Key Features
Pros Cons Micro
Service
Micro 1. Small in size
Service
1. Robust 1. Adds Complexity 2. Messaging–enabled
Micro
2. Scalable 2. Skillset shortage Service Micro Micro 3. Bounded by contexts
SSeO
rviA
ce Service
3. Testable (Local) 3. Confusion on getting the 4. Autonomously developed
Micro
4. Easy to Change and right size Service Micro 5. Independently deployable
Service
Replace 4. Team need to manage Micro
6. Decentralized
Service
5. Easy to Deploy end-to-end of the Service
7. Language–agnostic
(From UI to Backend to Microservice is not SOA.
6. Technology Agnostic Running in Production). 8. Built and released with
Martin Fowler – Micro Services Architecture
https://martinfowler.com/articles/microservices.html
Dzone – SOA vs Micro Services : https://dzone.com/articles/microservices-vs-soa-2
automated processes
17-11-2018

17 18

9
 12/6/2020

2
2 Business Solution & Business Process
Microservices Architecture & Design
❑ Business Solution focuses the entire Journey of the User which
• Business Solution & Process can run across multiple Micro Services.
• Capability Centric Design
• Domain Driven Design ❑ Business Solution comprises a set of Business Processes.
It’s not necessary that • Strategic Design
you need to use all • Tactical Design ❑ A specific Micro Service functionality will be focused on a
these patterns. You Business Process / Concern
will be using these • Hexagonal Architecture
based on your
technical requirement
• Event Sourcing & CQRS Business Solution: Customer Dining Experience
• ES and CQRS
Browse Menu Order Dinner Dinner Served Get Bill Make Payment
• Event Sourcing Example
Food Menu Dining Kitchen Order Payment
• Functional Reactive Programming
• 4 Building Blocks of RxJava
• Observable and Observer Design Pattern

11/17/2018 11/17/2018

19 20

10
 12/6/2020

2
Capability Centric Design
In a typical Monolithic way the team is
Front-End-Team Back-End-Team Database-Team QA / QC Team
divided based on technology / skill set
rather than business functions. This leads
to not only bottlenecks but also lack of
understanding of the Business Domain.

Business Centric Development

• Focus on Business Capabilities

• Entire team is aligned towards

Business Capability.
Domain Driven Design
• From Specs to Operations – The • Strategic Design
team handles the entire spectrum
of Software development. • Tactical Design
• Every vertical will have it’s own
Code Pipeline
Vertically sliced Product Team

21 22

11
 12/6/2020

2 2
Bounded Context – Strategic Design DDD: Bounded Context – Strategic Design
Semi Cooked
An App User’s Journey can run across

Understanding Bounded Context (DDD) of a Restaurant App

• Bounded Context is a Specific Business Process / Concern. Recipes
Frozen
multiple Bounded Context / Micro Steward
Chef
Raw

• Components / Modules inside the Bounded Context are context specific. Services.
Tables Dinning
uses Materials

User Journey X Order

• Multiple Bounded Contexts are linked using Context Mapping. Bounded Bounded Bounded
Reservation uses
Appetizer Veg Main Course
Veg
Menu Appetizer Non
Context Context Context
• One Team assigned to a Bounded Context. Soft Drinks Hot Drinks
Veg
Desserts
Main Course
Non Veg

• Each Bounded Context will have it’s own Source Code Repository. Kitchen
Dinning Semi Cooked
Recipes Context
• When the Bounded Context is being developed as a key strategic Areas of the domain treated Context Chef
Frozen

independently Steward Raw

initiative of your organization, it’s called the Core Domain. uses Materials
Tables Dinning
Order
• Within a Bounded Context the team must have same language called Discovered as you assess Reservation uses
Appetizer Veg Main Course
Veg
Ubiquitous language for Spoken and for Design / Code Implementation. requirements and build language Menu Appetizer Non
Veg
Main Course
Soft Drinks Hot Drinks Desserts Non Veg
Source: Domain-Driven Design
11/17/2018 Reference by Eric Evans Menu Context 27
23 24

12
 12/6/2020

1
Shopping Portal Modules – Code Packaging
Auth Customer Products Cart Order
Packaging Structure

Domain Layer
• Models
Domain Layer
• Models
Bounded Context
Domain Models
Domain Layer
• Models
CRUD / CQRS & Event Sourcing
•
•
Repo
Services
•
•
Repo
Services
(Entities, Value Objects, DTOs)
Interfaces (Ports)
•
•
Repo
Services
A brief introduction, more in Part 2 of the Series
(Repositories, Business Services, Web Services)
• Factories • Factories
Entity Factories
• Factories
Event Storming and SAGA
Adapters Adapters Adapters
• Repo • Repo Implementation • Repo
• Services • Services (Repositories, Business Services, Web Services) • Services
• Web Services • Web Services • Web Services

25 26

13
 12/6/2020

2 Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs 2
CRUD and CQRS https://blogs.msdn.microsoft.com/maarten_mullender/2004/07/23/crud-only-when-you-can-afford-it-revisite
Event Sourcing & CQRS (Command and Query Responsibility Segregation)
Traditional CRUD Architecture • In traditional data management systems, both
CRUD Disadvantages commands (updates to the data) and queries
Presentation • A mismatch between the read and write (requests for data) are executed against the same
set of entities in a single data repository.
representations of the data.
Services
• CQRS is a pattern that segregates the operations
• It risks data contention when records are locked in that read data (Queries) from the operations that
Business Logic the data store in a collaborative domain, where update data (Commands) by using separate
multiple actors operate in parallel on the same set of interfaces.

Data Access
data. These risks increase as the complexity and
throughput of the system grows. • CQRS should only be used on specific portions of a
system in Bounded Context (in DDD).
Queries Updates • It can make managing security and permissions • CQRS should be used along with Event Sourcing.
more complex because each entity is subject to both
read and write operations, which might expose data Java Axon Framework Resource : http://www.axonframework.org Axon CQS : Greg
Data Store MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx | Framework
in the wrong context. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html For Java
Bertrand Meyer Young

27 28

14
 12/6/2020

2 2
Event Sourcing Intro Restaurant Dining – Event Sourcing and CQRS
Standard CRUD Operations – Customer Profile – Aggregate Root
Processes 1 When people arrive at the Restaurant and take a table, a Table 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. Table is closed then the bill is prepared.
Customer Journey thru Dinning Processes
Commands 2 •
•
Open Table
Add Juice
•
•
Remove Soda
Add Food 1 • Serve Drinks • Prepare Bill
ES Aggregate
4
• Add Drinks • Dinning Order
Profile Created Title Updated New Address added Notes Removed • Add Soda • Add Food 2 • Prepare Food • Process
• Add Food • Billable Order
• Add Appetizer 1 • Place Order • Serve Food Payment
• Update Food
• Add Appetizer 2 • Close Table
Time T1 T2 T3 T4

Microservices
Event Sourcing and Derived Aggregate Root Kitchen Order Payment
Food Menu Dining
Commands Events Event store

1. Create Profile 1. Profile Created Event Derived

2. Update Title 2. Title Updated Event
3.
4.
Add Address
Delete Notes
3.
4.
Address Added Event
Notes Deleted Event
Current State of the
Customer Profile
Events
• Drinks Added
3 •
•
Table Opened
Juice Added
•
•
Remove Soda
Food 1 Added
•
•
Juice Served
Soda Served • Payment Approved
• • • Bill Prepared •
• Food Added Soda Added Food 2 Added • Appetizer Served Payment Declined
•
2 3 Single Source of Truth 4 •
•
Food Updated
Food Discontinued
•
•
Appetizer 1 Added
Appetizer 2 Added
•
•
Order Placed
Table Closed
•
•
Food Prepared
Food Served
Payment Processed • Cash Paid

The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles.

29 30

15
 12/6/2020

2
Summary – Event Sourcing and CQRS 3
Scalability
1. Immutable Events • Microservice Scalability
2. Events represents the state change in Aggregate Root
• CAP Theorem
3. Aggregates are Derived from a Collection of Events.
4. Separate Read and Write Models • ACID vs BASE
5. Commands (originated from user or systems) creates
• Infrastructure Design Pattern
Events.
6. Commands and Queries are always separated and
possibly reads and writes using different data models.

11/17/2018 11/17/2018

31 32

16
 12/6/2020

3 3
Scale Cube and Micro Services CAP Theorem
by Eric Allen Brewer
Pick Any 2!!
Say NO to 2 Phase Commit ☺

1. Y Axis Scaling – Functional Decomposition : Business Function as a Service

2. Z Axis Scaling – Database Partitioning : Avoid locks by Database Sharding
3. X Axis Scaling – Cloning of Individual Services for Specific Service Scalability
“In a network subject to communication failures, it is impossible for any web service to implement an atomic read / write shared
Source: The NewStack. Based on the Art of Scalability by By Martin Abbot & Michael Fisher memory that guarantees a response to every request.” 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

33 34

17
 12/6/2020

3
ACID vs BASE
Atomic
• All operations in a transaction succeed or every Basic Availability
operation is rolled back. • The database appears to

Consistent
• On the completion of a transaction, the
work most of the time.

Soft-state
Infrastructure Design Patterns
• Stores don’t have to be • API G ATEWAY
database is structurally sound.
write-consistent, nor do • LOAD BALAN C ER
Isolated different replicas have to • S ERVI CE D I S COVERY
• Transactions do not contend with one another. be mutually consistent all • C I RC UI T B R EA K ER
Contentious access to data is moderated by the the time.
• S ERVI CE AG G R EGATOR
database so that transactions appear to run
Eventual consistency • LE T-I T C RAS H PAT TERN
sequentially.
• Stores exhibit consistency
Durable at some later point (e.g.,
• The results of applying a transaction are lazily at read time).
permanent, even in the presence of failures.

35 36

18
 12/6/2020

API Gateway Design Pattern Load Balancer Design Pattern

Firewall Firewall

API Gateway (Reverse Proxy Server) routes

Product
the traffic to appropriate Microservices

Circuit Breaker

Circuit Breaker
Load Balancer
Customer (Load Balancers)

Database
Load
UI Layer

Users Order API Gateway Balancer

Database Layer

Database Layer
Business Logic

Business Logic
Access the

Web Services

Web Services
SE 8
SE 8

UI Layer

UI Layer
Product Product
Monolithic Shopping Cart Microservice Microservice
With 4 node With 4 node
App
WS

Load Balancer Rules

DL

cluster cluster
BL

Directly
Product Product
1. Round Robin
API Gateway (Reverse Proxy Server) routes the traffic
to appropriate Microservices (Load Balancers)
2. Based on

Circuit Breaker
Load Balancer

CB = Hystrix
Availability Load

Database Layer

Database Layer
Business Logic

Business Logic
Web Services

Web Services
UI Layer

UI Layer
Customer Customer
Microservice
With 2 node
3. Based on Balancer Microservice
With 2 node

Users API Gateway cluster

Users Response Time cluster

Customer

37 38

19
 12/6/2020

Service Discovery – NetFlix Network Stack Model Service Discovery – Kubernetes Model
Firewall Firewall Pods Nodes Pods Nodes
Service Discovery Internal
Internal
Load Balancers
Reverse Proxy Server Load Balancers Politics 1 N2
N3 EndPoints
EndPoints News Pod 1
News Politics Politics 2 N2 DB
API News Pod 2 N2
Service
Gateway Service N1
Politics 3

Circuit Breaker
Load Balancer
N4
API Gateway News Pod 3

Internal
Load Balancers Sports 1 N4
Service Call
Kube DNS Sports N1
Product Service Definition Sports 2 DB
• In this model Developers write the Microservice Service
code in every Microservice to register With 4 node from Kubernetes EndPoints
Sports 3 N3
Product cluster
with NetFlix Eureka Service Discovery Perspective
Server.
• Load Balancers and API Gateway also
• API Gateway (Reverse Proxy Server) doesn't know the instances (IP

Circuit Breaker
registers with Service Discovery. Load Balancer Addresses) of News Pod. It knows the IP address of the Services

Database Layer
Business Logic
Web Services
defined for each Microservice (News, Politics, Sports etc.).

UI Layer
• Service Discovery will inform the Load Customer
Microservice
Kubernetes
Users
Balancers about the instance details With 2 node
cluster Users • Services handles the dynamic IP Addresses of the pods. Services Objects
(IP Addresses). will automatically discover the new Pods based on Labels.
Customer

39 40

20
 12/6/2020

4 4
References References
1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. Domain Driven Design
2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 16. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans
3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 17. Mar 19, 2013 Domain Driven Design By Eric Evans
4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 18. May 16, 2015 Microsoft Ignite: Domain Driven Design for the Database Driven Mind
5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 19. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World
6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 20. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard
7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 21. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke
8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 22. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson
9. Zuul Edge Server, Ketan Gote, May 22, 2017 23. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune
10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017
Event Sourcing and CQRS
11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017
23. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young
12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017
13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 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
14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016
26. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes
15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015
72
41 42

21
 12/6/2020

4 4
References References – Micro Services – Videos
27. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 41. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s
28. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 42. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg
43.
29. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans
44.
30. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs GOTO 2015 – Challenges Implementing Micro Services By Fred George
45.
GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer
31. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 46. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith
32. CQS : http://en.wikipedia.org/wiki/Command–query_separation 47. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k

33. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 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
34. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
50. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016
35. CAP 12 years how the rules have changed
51. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles
36. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 52. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan
37. Pat Helland (Amazon) : Life beyond distributed transactions 53. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup.
38. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 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
39. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem
56. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford.
40. Rx Observable : https://dzone.com/articles/using-rx-java-observable
57.
GOTO 2017 – Microservices without Servers. By Glynn Bird.

43 44

22