From SOA to MSA–
Creating Adaptive and Innovation
Supportive Architecture and
Organization
-by William
Topics
• Principles of Microservices Architecture
• Patterns and Best Practices of Microservices
• Microservices Organization
• Application of Microserivces Architecture
Problem Domain
• System & Organization Decoupling
• Legacy System Upgrading
• Use suitable platform and technology to solve
different problems
– Golden Hammer Syndrome - Always Win/.Net
• Foster business innovation, dealing with outside
competition
– Innovation as a platform
• Creating extensible, agile and adaptive
architecture and organization.
SOLID Review - Single Responsibility
Principle
SOLID Review – Liskov Substitution
Principle
SOLID Review – Dependency Inversion
Principle
GRASP – General Responsibility
Assignment Software Principles
• High Cohesion, Low Coupling
– How to keep objects appropriately focused, manageable and understandable?
– How to minimize dependencies, change impact and maximize reuse?
• Information Expert
– What’s the general principle to assign responsibilities to object?
• Controller
– Who should receive events and coordinate the overall system operation?
• Polymorphism
– How to make components pluggable?
• Pure Fabrication
– How to assign responsibilities to class representing concept not existing in problem domain?
• Indirection
– How to decouple between two(or more) objects?
• Protected Variation
– How to design object or system that its internal instability or variation will not have bad
impact to other elements of the object or system?
Microservices Architecture
• A system architectural style, it is SOLID and
GRASP principles applied at architectural level,
including some patterns and best practices.
• SOA is too coarse-grained, Microservices is
fine-grained and practical SOA.
• Microservices architecture needs technical
infrastructure and organization support.
Monolithic -> SOA -> MicorServices
Legacy System Decouple & Upgrade
Coupled SOA
Edge Service
Middle Tier
Service
Edge Service聚合服务Middle Tier
Service
后端服务
Clients
Middle
Tier Svc
Edge Svc
Decoupled SOA
Balance Standardization & Autonomy
Standardization
Interface
Monitoring
Deployment
Key Elements of Microservices
Architecture
• Stateless Service
– Support scale out
• Low Friction Deployment
– Fast and flexible service deployment and upgrade.
• Automated Management & Monitoring
– Push common concerns to technical infrastructure
and framework, service developers only need to care
for business logic.
• Automated Service Discovery & Routing
– Decouple services, flexible upgrade and replacement.
Microservices Framework
Drop-in
Business Logic
Service
Discovery
RESTFul
API
XML/JSON/
Proto-buf
Contract
First
Security
Policy
Configuration
Client/Proxy
Autogen
Error
Handling
Metric
System
Central
Logging
Request
Validation
Governance
Rate
Limiting
Version Control of Microservices
 Leave multiple old
microservice versions running
 Fast introduction vs. slow
retirement asymmetry Brute force upgrade
Backward compatible Multiple versions coexistence
Invocation Pattern of Microservices
Service Dependency
Single Dependency Delay Causing
Blocking of User Request
All Request Threads Can be Blocked at
Peak Hour(aka. Cascading Failure)
Circuit Breaker Fault Tolerant Pattern
https://github.com/Netflix/Hystrix
GLSB
DC Aware
Gateway
SOA Edge Service
Service
Registry
Peer Sync
Invoke
Invoke Invoke
Invoke
DC 1 DC 2
SOA Middle Tier Service
DC Aware
Gateway
SOA Edge Service
SOA Middle Tier Service
Service
RegistryDC Aware
Client
DC Aware
Client
Invoke
Invoke
Invoke
Lookup
Lookup
Register Register
Lookup Lookup
RegisterRegister
Cross Data Center Active-Active
Conway’s Law
• “…organization which design systems … are
constrained to produce designs which are copies
of the communication structure of those
organizations”
– Melvin Conway, 1968
• “If you ask nine people to write a compiler, you
get a nine pass compiler”
• “Those system then constrain the options for
organizational change”
– Dan North
Team Organized by Technical Layer
Traditional Organizational Structure
Microservices Organization
 Organized around
Business Capabilities
 Products not Projects
 Full stack skill team
The Cost of Microservices
• System Complexity
– Too much microservices, developer can’t build
context and see the big picture,
– Need better architectural integration patterns.
• Performance
– Performance penalty because of cross-process
invocation, 20 - 200ms per hop average.
– Tune time consuming invocation, leverage
microservices invocation pattern.
API Gateway
Service
Registry
SOA2
ESB
SQL
Server
SOA2
SOA2
ESB
SOA2-
JAVA
MySQL
SOA2-
JAVA
Mem
Cached
HBase
Redis
SBU A SBU B SBU C SBU D
Common Concerns :
routing, auth, rate
limiting, monitoring,
logging
View
Controller
Model
Service
Routing
Table
Microservices
Architecture - A
Case In Practice
Take Away
• Independently scalable, deployable, changeable,
replaceable
• Evolutionary architecture and emergent design
are approaches that maximize flex
• Programmable microservices platform fostering
innovation
• Standardize in the gaps between services –
flexible about what happens inside the boxes
• Separation of Concerns & Bounded Context
• Another layer of indirection for decoupling
Reference
• Micro-service architecture
– http://yobriefca.se/blog/2013/04/28/micro-service-
architecture/
• Micro-service by Martin Fowler
– http://martinfowler.com/articles/microservices.html
• Migrating to microservices by former Netflix
cloud architect Adrian Cockcroft.
– http://qconlondon.com/dl/qcon-london-
2014/slides/AdrianCockcroft_MigratingToMicroservice
s.pdf

From SOA to MSA

  • 1.
    From SOA toMSA– Creating Adaptive and Innovation Supportive Architecture and Organization -by William
  • 2.
    Topics • Principles ofMicroservices Architecture • Patterns and Best Practices of Microservices • Microservices Organization • Application of Microserivces Architecture
  • 3.
    Problem Domain • System& Organization Decoupling • Legacy System Upgrading • Use suitable platform and technology to solve different problems – Golden Hammer Syndrome - Always Win/.Net • Foster business innovation, dealing with outside competition – Innovation as a platform • Creating extensible, agile and adaptive architecture and organization.
  • 4.
    SOLID Review -Single Responsibility Principle
  • 5.
    SOLID Review –Liskov Substitution Principle
  • 6.
    SOLID Review –Dependency Inversion Principle
  • 7.
    GRASP – GeneralResponsibility Assignment Software Principles • High Cohesion, Low Coupling – How to keep objects appropriately focused, manageable and understandable? – How to minimize dependencies, change impact and maximize reuse? • Information Expert – What’s the general principle to assign responsibilities to object? • Controller – Who should receive events and coordinate the overall system operation? • Polymorphism – How to make components pluggable? • Pure Fabrication – How to assign responsibilities to class representing concept not existing in problem domain? • Indirection – How to decouple between two(or more) objects? • Protected Variation – How to design object or system that its internal instability or variation will not have bad impact to other elements of the object or system?
  • 8.
    Microservices Architecture • Asystem architectural style, it is SOLID and GRASP principles applied at architectural level, including some patterns and best practices. • SOA is too coarse-grained, Microservices is fine-grained and practical SOA. • Microservices architecture needs technical infrastructure and organization support.
  • 9.
    Monolithic -> SOA-> MicorServices
  • 10.
  • 11.
    Coupled SOA Edge Service MiddleTier Service Edge Service聚合服务Middle Tier Service 后端服务 Clients Middle Tier Svc Edge Svc
  • 12.
  • 13.
  • 14.
  • 15.
    Key Elements ofMicroservices Architecture • Stateless Service – Support scale out • Low Friction Deployment – Fast and flexible service deployment and upgrade. • Automated Management & Monitoring – Push common concerns to technical infrastructure and framework, service developers only need to care for business logic. • Automated Service Discovery & Routing – Decouple services, flexible upgrade and replacement.
  • 16.
  • 17.
    Version Control ofMicroservices  Leave multiple old microservice versions running  Fast introduction vs. slow retirement asymmetry Brute force upgrade Backward compatible Multiple versions coexistence
  • 18.
    Invocation Pattern ofMicroservices
  • 19.
  • 20.
    Single Dependency DelayCausing Blocking of User Request
  • 21.
    All Request ThreadsCan be Blocked at Peak Hour(aka. Cascading Failure)
  • 22.
    Circuit Breaker FaultTolerant Pattern https://github.com/Netflix/Hystrix
  • 23.
    GLSB DC Aware Gateway SOA EdgeService Service Registry Peer Sync Invoke Invoke Invoke Invoke DC 1 DC 2 SOA Middle Tier Service DC Aware Gateway SOA Edge Service SOA Middle Tier Service Service RegistryDC Aware Client DC Aware Client Invoke Invoke Invoke Lookup Lookup Register Register Lookup Lookup RegisterRegister Cross Data Center Active-Active
  • 24.
    Conway’s Law • “…organizationwhich design systems … are constrained to produce designs which are copies of the communication structure of those organizations” – Melvin Conway, 1968 • “If you ask nine people to write a compiler, you get a nine pass compiler” • “Those system then constrain the options for organizational change” – Dan North
  • 25.
    Team Organized byTechnical Layer
  • 26.
  • 27.
    Microservices Organization  Organizedaround Business Capabilities  Products not Projects  Full stack skill team
  • 28.
    The Cost ofMicroservices • System Complexity – Too much microservices, developer can’t build context and see the big picture, – Need better architectural integration patterns. • Performance – Performance penalty because of cross-process invocation, 20 - 200ms per hop average. – Tune time consuming invocation, leverage microservices invocation pattern.
  • 29.
    API Gateway Service Registry SOA2 ESB SQL Server SOA2 SOA2 ESB SOA2- JAVA MySQL SOA2- JAVA Mem Cached HBase Redis SBU ASBU B SBU C SBU D Common Concerns : routing, auth, rate limiting, monitoring, logging View Controller Model Service Routing Table Microservices Architecture - A Case In Practice
  • 30.
    Take Away • Independentlyscalable, deployable, changeable, replaceable • Evolutionary architecture and emergent design are approaches that maximize flex • Programmable microservices platform fostering innovation • Standardize in the gaps between services – flexible about what happens inside the boxes • Separation of Concerns & Bounded Context • Another layer of indirection for decoupling
  • 32.
    Reference • Micro-service architecture –http://yobriefca.se/blog/2013/04/28/micro-service- architecture/ • Micro-service by Martin Fowler – http://martinfowler.com/articles/microservices.html • Migrating to microservices by former Netflix cloud architect Adrian Cockcroft. – http://qconlondon.com/dl/qcon-london- 2014/slides/AdrianCockcroft_MigratingToMicroservice s.pdf