Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Stijn Van den Enden 
CTO 
stijn.vandenenden@aca-it.be 
Tom De Wolf 
Technical Lead 
tom.dewolf@aca-it.be 
www.aca-it.be 
T...
Concepts - What are Micro services? 
Patterns - How to solve the challenges? 
Technology - Using what?
The microservice architectural style is an approach to developing a single 
application as a suite of small services, each...
SERVICE ORIENTED ARCHITECTURE? 
Yes, it’s SOA … but different implementation approach: 
Classic SOA 
integrates different ...
Classic SOA 
integrates different applications as a set of services 
Microservices 
WS* WS* WS* WS* WS* 
Enterprise Servic...
business platform 
{ API } { API } { API } 
accounting 
ordering 
service 
service contract 
{ API } { API } 
Microservice...
Classic SOA 
Typical implementation solution differs! 
integrates different applications as a set of services 
Heavy-weigh...
WHY
SOA 
WHY - DIFFERENTIATE FROM SOA
Simple to develop Simple to deploy Simple to scale 
WAR/EAR 
UI 
Ordering 
Inventory 
Billing 
App Server 
Database 
WHY -...
Large Code Intimidates Developers 
Hard to understand 
WAR/EAR 
UI 
Ordering 
Inventory 
Billing 
App Server 
and modify 
...
Small Change - Big Impact 
Any change requires 
full rebuild, test and deploy 
Impact analysis 
is huge effort and takes l...
Big Risk for Re-Write 
WAR/EAR 
UI 
Ordering 
Inventory 
Billing 
App Server 
No hard module boundaries 
quality and modul...
Little Resilience to Failure 
WAR/EAR 
UI Failure in monolith 
Ordering 
Inventory 
Billing 
App Server 
brings it down 
W...
Scaling 
can be difficult 
WAR/EAR 
UI 
Ordering 
Inventory 
Billing 
App Server 
Mostly Horizontal scaling 
many load bal...
Horizontal Scaling 
WAR/EAR 
UI 
Ordering 
Inventory 
Billing 
App Server 
(monolith) 
WAR/EAR 
UI 
Ordering 
Inventory 
B...
Ordering 
Container 
Ordering 
Container 
Ordering 
Container 
Database 
Ordering 
Functional Scaling 
(micro-services) 
U...
• Small and focussed on 1 capability 
• easier to understand 
• IDE and deployment faster for 1 service 
• Independent 
• ...
1 - Key (business) drivers guide architectural decisions 
Micro-services are organised around business capabilities 
2 - P...
HOW TO
Approach - Key to success 
Challenges - And ways to overcome them 
HOW TO
Functional decomposition of the business domain
Functional decomposition of the business domain 
Software Design Customer Satisfaction 
Separation of Concerns 
Low Coupli...
Functional decomposition of the business domain 
B A 
B 
A 
• Change A impacts all modules = costly 
• Change B requires s...
side note: Domain Driven Design 
Tackling complexity by abstracting the business domain concepts and logic into a 
domain ...
Bounded contexts 
Domain driven design deals with large complex models by dividing them into 
different functionally bound...
Functional decomposition of the business domain 
Ordering Billing 
ONLINE STORE 
Inventory Accounting
Functional decomposition of the business domain 
Ordering Billing 
customer 
Inventory Accounting 
Invoice 
balance 
order...
Benefits of functional decomposition
Ordering Billing 
customer 
Inventory Accounting 
Invoice 
balance 
order 
item 
item 
stock order 
order 
item 
incoming ...
Applying services to bounded contexts 
Ordering Service Billing 
Service 
customer 
Inventory Service Accounting 
Service ...
Side note: Conway’s Law 
Any organization that designs a system (defined broadly) will produce a design 
whose structure i...
Side note: Conway's Law 
Technology-based Team Composition Functional Team Composition 
Billing Inventory 
Ordering 
Accou...
PITFALL: 
Incorrect functional decomposition 
Leads to higher coupling between services 
most of the microservices archite...
PITFALL: 
Incorrect functional decomposition 
Safer to start with a functionally well decomposed monolith 
and evolve it t...
Approach - Key to success 
Challenges - And ways to overcome them
CHALLENGE #1: 
Operational Complexity 
Complex Runtime: many moving parts 
- Keep Releases and deployments manageable 
- h...
CHALLENGE #2: 
Distributed Development 
Services are deployed on multiple instances 
- distributed architectural propertie...
Decentralised data 
Each service has its own database - loose coupling 
Might even be in another database technology 
Data...
Distributed Transactions vs Eventual Consistency 
DISTRIBUTED TRANSACTIONS 
- data is always consistent 
! 
- reduces syst...
Distributed Transactions vs Eventual Consistency 
EVENT-DRIVEN ASYNCHRONOUS UPDATES 
- use a message broker to publish use...
Communication between services 
Network properties need to be taken into account 
Use cases can span multiple services 
Wh...
What type of Communication? 
SYNCHRONOUS HTTP-BASED 
- easy 
- firewall-friendly, works across the internet 
! 
- doesn’t ...
What type of Communication? 
ASYNCHRONOUS NON-BLOCKING 
- Client doesn’t block calling thread 
- allows for parallelism 
!...
What type of Communication? 
ASYNCHRONOUS MESSAGING 
- For example through a Broker 
- decouples message producers from co...
What type of Communication? 
Use case: New Order Received 
New order Create invoice 
Ordering Service Billing Service 
Upd...
Handling Failures 
Services can fail at any moment 
Design services to handle these kind of failures
Side note: Reactive Programming 
Reactive systems are: 
Responsive 
Resilient 
Elastic 
Message Driven 
! 
-- Reactive Man...
Handling Failures 
FALLBACK MESSAGE QUEUE 
Ordering Service new order received Billing Service 
failure 
Fallback queue
Handling Failures 
PER-SERVICE THREAD POOLS 
Ordering Service Billing Service 
new order received 
Thread pool 
10 threads
CHALLENGE #3 
Minimising Communicational Overhead 
Avoid Chatty Communication 
- communication between services is reduced...
Minimising Communicational Overhead 
API GATEWAY 
Monolith Micro Services 
Ordering 
Inventory 
Billing 
Accounting 
Order...
Minimising Communicational Overhead 
API GATEWAY 
Ordering 
Container 
Inventory 
Container 
Billing 
Container 
Accountin...
Handling Failures in Communication 
CIRCUIT BREAKER 
- Wrap a protected function in a circuit breaker 
- Monitor protected...
Handling Failures in Communication 
CIRCUIT BREAKER 
Ordering Service Billing Service 
new order received 
Circuit breaker...
TECHNOLOGY
Microservice 
Implementation Stack
DROPWIZARD 
Make features not WAR
DROPWIZARD 
guava 
jackson 
metrics 
Validator 
YAML 
JDBI 
core 
migrations 
hibernate 
jdbi 
…
java -jar ./target/profileservice-0.1.0-SNAPSHOT.jar server ./src/ 
main/resources/userprofileservice.yml
SPRING BOOT 
opinionated view of building production-ready Spring applications
• Convention over configuration 
approach 
• Deployable as a Self-contained 
jar or war 
•Tackles dependency-hell via 
pre...
Deployment
VM’s abstract underlying 
hardware, but limit 
resource utilisation 
MicroService MicroService 
JVM 
VM1 VM2 
JVM 
Guest O...
DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODE 
Static website User DB Web frontend Queue Analytics DB 
Developmen 
t VM 
...
DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODE 
Static website User DB Web frontend Queue Analytics DB 
Developmen 
t VM 
...
DOCKER SOLVES THE NXN PROBLEM 
Static website 
Web frontend 
Background workers 
User DB 
Analytics DB 
Queue 
Development...
• Isolation 
• namespace 
• pid mnt net uts ipc user 
• resource usage 
• (CPU, memory, disk I/O, etc.) 
• Limited impact ...
Continuous Integration 
Infrastructure 
Source 
Control System 
DockerFile 
Container Image Repository 
Host OS 
pull 
dae...
https://github.com/spotify/helios 
http://mesos.apache.org/ 
https://github.com/openshift/geard 
… 
Private Hybrid Public
MicroService MicroService 
JVM 
VM1 VM2 
JVM 
Guest OS 
Guest OS 
Hypervisor 
Host OS 
Compute, Storage, Network 
MicroSer...
Balancing Load
Static 
Dynamic 
Loadbalancer Loadbalancer 
Web Front 
End 
Web Front 
End 
MicroService MicroService MicroService MicroSe...
Static 
Dynamic 
Loadbalancer Loadbalancer 
Web Front 
End 
Web Front 
End 
MicroService MicroService MicroService MicroSe...
The Story 
* based on Functional Programming the Netflix API - Ben Christensen
Netflix API 
Dependency A 
Dependency D 
Dependency G 
Dependency B 
Dependency J 
Dependency E 
Dependency M 
Dependency ...
Discovery of Rx began with a re-architecture ... 
* based on Functional Programming the Netflix API - Ben Christensen
... that collapsed network traffic into coarse API calls ... 
* based on Functional Programming the Netflix API - Ben Chri...
Iterable 
pull 
Observable 
push 
T next() 
throws Exception 
returns; 
onNext(T) 
onError(Exception) 
onCompleted() 
!//"...
* based on Functional Programming the Netflix API - Ben Christensen
* based on Functional Programming the Netflix API - Ben Christensen
+ = 
https://github.com/Netflix/Hystrix
HystrixCommand run() 
failure/circuit open 
getFallback() 
public class GetUserPerferencesCommand extends HystrixCommand<U...
Monitoring
A MicroService MicroService MicroService MicroService MicroService 
Logstash 
Log Aggregation 
Graphite 
Metrics and Monit...
- Correct Functional decomposition is crucial 
Conclusion 
- reflect it in a organisational structure (Conway’s law) 
- pr...
MicroServices, yet another architectural style?
MicroServices, yet another architectural style?
MicroServices, yet another architectural style?
MicroServices, yet another architectural style?
MicroServices, yet another architectural style?
Upcoming SlideShare
Loading in …5
×

MicroServices, yet another architectural style?

10,229 views

Published on

This presentation gives a broad overview of the microservice architectural style. It highlights the difference between microservices and SOA, the challenges and pattern and popular tools to implement an microservice architecture

Published in: Software

MicroServices, yet another architectural style?

  1. 1. Stijn Van den Enden CTO stijn.vandenenden@aca-it.be Tom De Wolf Technical Lead tom.dewolf@aca-it.be www.aca-it.be Thomas Borghs Solution Engineer thomas.borghs@aca-it.be MICRO SERVICES Yet another architectural style?
  2. 2. Concepts - What are Micro services? Patterns - How to solve the challenges? Technology - Using what?
  3. 3. The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. ! Martin Fowler
  4. 4. SERVICE ORIENTED ARCHITECTURE? Yes, it’s SOA … but different implementation approach: Classic SOA integrates different applications as a set of services Microservices architect a single application as a set of services
  5. 5. Classic SOA integrates different applications as a set of services Microservices WS* WS* WS* WS* WS* Enterprise Service Bus Workflow Engine Orchestration Intelligence WS* WS* WS* WS* WS*
  6. 6. business platform { API } { API } { API } accounting ordering service service contract { API } { API } Microservices service architect a single application as a set of services prospects logistics service service capability X service capability Y service backends external integrations { API } { API } { API } { API } { API } { API }
  7. 7. Classic SOA Typical implementation solution differs! integrates different applications as a set of services Heavy-weight Microservices Orchestration Intelligent Communication Layer architect a single application as a set of services ESB WS*/SOAP License-driven Target problem: Integrate (Legacy) Software Light-weight Choreography HTTP/REST/JSON Dumb Communication Layer Target problem: Intelligent Services Architect new Business Platform
  8. 8. WHY
  9. 9. SOA WHY - DIFFERENTIATE FROM SOA
  10. 10. Simple to develop Simple to deploy Simple to scale WAR/EAR UI Ordering Inventory Billing App Server Database WHY - THE CURSE OF THE MONOLITH
  11. 11. Large Code Intimidates Developers Hard to understand WAR/EAR UI Ordering Inventory Billing App Server and modify Overloaded web container Development slows down Overloaded IDE WHY - THE CURSE OF THE MONOLITH
  12. 12. Small Change - Big Impact Any change requires full rebuild, test and deploy Impact analysis is huge effort and takes long Obstacle for frequent changes and deployments WAR/EAR UI Ordering Inventory Billing App Server WHY - THE CURSE OF THE MONOLITH
  13. 13. Big Risk for Re-Write WAR/EAR UI Ordering Inventory Billing App Server No hard module boundaries quality and modularity breaks down over time this enforces eventual need for re-write Long term commitment to technology stack change or try-out new technology implies re-write Re-write = complete re-write no partial re-write WHY - THE CURSE OF THE MONOLITH
  14. 14. Little Resilience to Failure WAR/EAR UI Failure in monolith Ordering Inventory Billing App Server brings it down WHY - THE CURSE OF THE MONOLITH
  15. 15. Scaling can be difficult WAR/EAR UI Ordering Inventory Billing App Server Mostly Horizontal scaling many load balanced instances Hard to scale to data growth cope with all data Different components have different resource needs Scaling development implies coordination overhead WHY - THE CURSE OF THE MONOLITH
  16. 16. Horizontal Scaling WAR/EAR UI Ordering Inventory Billing App Server (monolith) WAR/EAR UI Ordering Inventory Billing App Server Database All data WAR/EAR UI Ordering Inventory Billing App Server Vertical Scaling WAR/EAR UI Ordering Inventory Billing App Server WAR/EAR UI Ordering Inventory Billing App Server (monolith) Database All data WHY - TYPES OF SCALING Data Scaling WAR/EAR UI Ordering Inventory Billing App Server WAR/EAR UI Ordering Inventory Billing App Server Database segment WAR/EAR UI Ordering Inventory Billing App Server Database segment Database segment (monolith)
  17. 17. Ordering Container Ordering Container Ordering Container Database Ordering Functional Scaling (micro-services) UI Container Inventory Container Billing Container Billing Container Database Inventory Database Billing Ordering WHY - TYPES OF SCALING Team Scaling Container Inventory Container Billing Container (micro-services) balances application and development complexity
  18. 18. • Small and focussed on 1 capability • easier to understand • IDE and deployment faster for 1 service • Independent • Release and deployment • Scaling • Development • Loosely Coupled • through lightweight communication • Fault Isolation vs bring all down. • Allows try-out of new technologies. • Re-write can be limited to 1 service • Impact Analysis stops at boundary • Provide firm module boundaries with explicit interface! • Less risk on re-write • Harder to violate boundary in development • Decentralised choreography • vs central orchestration • vs central point of failure • Decentralised data • polyglot persistence WHY - ARCHITECTURAL BENEFITS
  19. 19. 1 - Key (business) drivers guide architectural decisions Micro-services are organised around business capabilities 2 - Postpone decisions to Last Responsible Moment Micro-services allow delay of scaling and technological decisions 3 - Architect and develop for Evolvability Micro-services support evolution in technology, scaling, and features WHY - EVOLUTIONARY ARCHITECTURE
  20. 20. HOW TO
  21. 21. Approach - Key to success Challenges - And ways to overcome them HOW TO
  22. 22. Functional decomposition of the business domain
  23. 23. Functional decomposition of the business domain Software Design Customer Satisfaction Separation of Concerns Low Coupling, High Cohesion Reduce Impact by Encapsulating Source of Change Predictable Cost of Change Changes are Business Driven Source of Change = Business Functional Modularisation
  24. 24. Functional decomposition of the business domain B A B A • Change A impacts all modules = costly • Change B requires split of module = costly • Change A only impacts other module if api change • Change B limited to module
  25. 25. side note: Domain Driven Design Tackling complexity by abstracting the business domain concepts and logic into a domain model and using this as a base for software development “In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.” From: Domain Driven Design by Eric Evans.
  26. 26. Bounded contexts Domain driven design deals with large complex models by dividing them into different functionally bounded subdomains and the explicitly describing the interrelations between these subdomains.
  27. 27. Functional decomposition of the business domain Ordering Billing ONLINE STORE Inventory Accounting
  28. 28. Functional decomposition of the business domain Ordering Billing customer Inventory Accounting Invoice balance order item item stock order order item incoming cash outgoing cash stock
  29. 29. Benefits of functional decomposition
  30. 30. Ordering Billing customer Inventory Accounting Invoice balance order item item stock order order item incoming cash outgoing cash stock Benefits of functional decomposition
  31. 31. Applying services to bounded contexts Ordering Service Billing Service customer Inventory Service Accounting Service Invoice balance order item item stock order order item incoming cash outgoing cash stock
  32. 32. Side note: Conway’s Law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. ! -- Melvyn Conway, 1967
  33. 33. Side note: Conway's Law Technology-based Team Composition Functional Team Composition Billing Inventory Ordering Accounting Ordering Container Billing Container Inventory Container Accounting Container UI UI
  34. 34. PITFALL: Incorrect functional decomposition Leads to higher coupling between services most of the microservices architectural benefits are lost - harder to functionally scale the application - errors will propagate through multiple services - graceful degradation will be harder to achieve - team development overhead - T-scaling becomes harder - large communicational overhead between services - large overhead in releasing/deploying business features - refactoring to correct decomposition is costly
  35. 35. PITFALL: Incorrect functional decomposition Safer to start with a functionally well decomposed monolith and evolve it to a microservices architecture when the need arises Refactoring the initial functional decomposition will be easier in a monolith - rewriting failure scenario’s - decentralised data - service contract redesign
  36. 36. Approach - Key to success Challenges - And ways to overcome them
  37. 37. CHALLENGE #1: Operational Complexity Complex Runtime: many moving parts - Keep Releases and deployments manageable - high level of automation is needed - Service monitoring is required - Configuration management becomes more complex
  38. 38. CHALLENGE #2: Distributed Development Services are deployed on multiple instances - distributed architectural properties to consider: - decentralised data - communication between services - handling failures of components - testing effort becomes greater
  39. 39. Decentralised data Each service has its own database - loose coupling Might even be in another database technology Data duplication between services might be required to ensure loose coupling When implementing use cases spanning multiple services: distributed transactions vs eventual consistency
  40. 40. Distributed Transactions vs Eventual Consistency DISTRIBUTED TRANSACTIONS - data is always consistent ! - reduces system availability - services are more tightly coupled - has fallen out of favor in modern stacks (REST, NoSQL)
  41. 41. Distributed Transactions vs Eventual Consistency EVENT-DRIVEN ASYNCHRONOUS UPDATES - use a message broker to publish use cases to other services - decouples producers and consumers (services) of events - improves availability - tradeoff between availability and data consistenty - application needs to be able to handle eventually consistent data
  42. 42. Communication between services Network properties need to be taken into account Use cases can span multiple services What type of communication is best used to implement such a use case?
  43. 43. What type of Communication? SYNCHRONOUS HTTP-BASED - easy - firewall-friendly, works across the internet ! - doesn’t support publisher-subscriber patterns - client and server must both be available simultaneously - client needs to know host and port of server
  44. 44. What type of Communication? ASYNCHRONOUS NON-BLOCKING - Client doesn’t block calling thread - allows for parallelism ! - client and server still must both be available simultaneously - client still needs to know host and port of server
  45. 45. What type of Communication? ASYNCHRONOUS MESSAGING - For example through a Broker - decouples message producers from consumers - broker can buffer messages - supports a variety of communication patterns ! - broker is another moving part - adds complexity - request-reply communication pattern is not a natural fit
  46. 46. What type of Communication? Use case: New Order Received New order Create invoice Ordering Service Billing Service Update Stock Update Incoming Cashflow Inventory Service Accounting Service
  47. 47. Handling Failures Services can fail at any moment Design services to handle these kind of failures
  48. 48. Side note: Reactive Programming Reactive systems are: Responsive Resilient Elastic Message Driven ! -- Reactive Manifesto: september 16 2014
  49. 49. Handling Failures FALLBACK MESSAGE QUEUE Ordering Service new order received Billing Service failure Fallback queue
  50. 50. Handling Failures PER-SERVICE THREAD POOLS Ordering Service Billing Service new order received Thread pool 10 threads
  51. 51. CHALLENGE #3 Minimising Communicational Overhead Avoid Chatty Communication - communication between services is reduced - when functional decomposition is done right - when service size isn’t too small - reduce communication between clients and Services with an API gateway - executing service calls in parallel reduces impact of communication overhead - reduce unneeded network usage by using circuit breakers
  52. 52. Minimising Communicational Overhead API GATEWAY Monolith Micro Services Ordering Inventory Billing Accounting Ordering Container Inventory Container Billing Container Accounting Container Desktop client Mobile client Desktop client Mobile client
  53. 53. Minimising Communicational Overhead API GATEWAY Ordering Container Inventory Container Billing Container Accounting Container Desktop client Mobile client Api gateway
  54. 54. Handling Failures in Communication CIRCUIT BREAKER - Wrap a protected function in a circuit breaker - Monitor protected function for failures - The circuit breaks when a predefined threshold of fails is reached - All future calls to the function go to fallback until the circuit is restored
  55. 55. Handling Failures in Communication CIRCUIT BREAKER Ordering Service Billing Service new order received Circuit breaker Threshold = 10 Fallback queue
  56. 56. TECHNOLOGY
  57. 57. Microservice Implementation Stack
  58. 58. DROPWIZARD Make features not WAR
  59. 59. DROPWIZARD guava jackson metrics Validator YAML JDBI core migrations hibernate jdbi …
  60. 60. java -jar ./target/profileservice-0.1.0-SNAPSHOT.jar server ./src/ main/resources/userprofileservice.yml
  61. 61. SPRING BOOT opinionated view of building production-ready Spring applications
  62. 62. • Convention over configuration approach • Deployable as a Self-contained jar or war •Tackles dependency-hell via pre-packaging • Support for monitoring and metrics (actuator module)
  63. 63. Deployment
  64. 64. VM’s abstract underlying hardware, but limit resource utilisation MicroService MicroService JVM VM1 VM2 JVM Guest OS Guest OS Hypervisor Host OS Compute, Storage, Network Containers have own isolated resources MicroService MicroService MicroService JVM JVM JVM container2 container3 Host OS MicroService JVM container1 container4 Compute, Storage, Network
  65. 65. DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODE Static website User DB Web frontend Queue Analytics DB Developmen t VM QA server Public Cloud Contributor’s laptop Multiplicity of Stacks Multiplicity of hardware environments Production Cluster Customer Data Center Do services and apps interact appropriately? Can I migrate smoothly and quickly …that can be manipulated using standard operations and run consistently on virtually any hardware platform An engine that enables any payload to be encapsulated as a lightweight, portable, self-sufficient container…
  66. 66. DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODE Static website User DB Web frontend Queue Analytics DB Developmen t VM QA server Public Cloud Contributor’s laptop Multiplicity of Stacks Multiplicity of hardware environments Production Cluster Customer Data Center Do services and apps interact appropriately? Can I migrate smoothly and quickly Operator: Configure Once, Run Anything Developer: Build Once, Run Anywhere
  67. 67. DOCKER SOLVES THE NXN PROBLEM Static website Web frontend Background workers User DB Analytics DB Queue Development VM QA Server Single Prod Server Onsite Cluster Public Cloud Contributor’s laptop Customer Servers
  68. 68. • Isolation • namespace • pid mnt net uts ipc user • resource usage • (CPU, memory, disk I/O, etc.) • Limited impact on Performance - http://ibm.co/V55Otq • Daemon and CLI MicroService MicroService MicroService JVM JVM JVM container2 container3 Host OS MicroService JVM container1 container4 Compute, Storage, Network
  69. 69. Continuous Integration Infrastructure Source Control System DockerFile Container Image Repository Host OS pull daemon MicroService JVM container1 Compute, Storage, Network MicroService JVM Host OS Slave Node push build provision container1
  70. 70. https://github.com/spotify/helios http://mesos.apache.org/ https://github.com/openshift/geard … Private Hybrid Public
  71. 71. MicroService MicroService JVM VM1 VM2 JVM Guest OS Guest OS Hypervisor Host OS Compute, Storage, Network MicroService MicroService MicroService JVM JVM JVM container2 container3 Host OS MicroService JVM container1 container4 Compute, Storage, Network VM’s abstract underlying hardware, but limit resource utilisation Containers have own isolated resources Microservice run in their own isolated classloader and standbox in the JVM OSGi Runtime MicroService MicroService JVM MicroService Host OS Compute, Storage, Network
  72. 72. Balancing Load
  73. 73. Static Dynamic Loadbalancer Loadbalancer Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService Web Front End Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService A B Midtier Service Registry MicroService register renew get registry
  74. 74. Static Dynamic Loadbalancer Loadbalancer Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService Web Front End Web Front End Web Front End MicroService MicroService MicroService MicroService MicroService A B https://github.com/Netflix/ribbon Midtier Service Registry MicroService register renew get registry eureka ribbon https://github.com/Netflix/eureka
  75. 75. The Story * based on Functional Programming the Netflix API - Ben Christensen
  76. 76. Netflix API Dependency A Dependency D Dependency G Dependency B Dependency J Dependency E Dependency M Dependency H Dependency P Dependency C Dependency K Dependency F Dependency N Dependency I Dependency Q Dependency L Dependency O Dependency R * based on Functional Programming the Netflix API - Ben Christensen
  77. 77. Discovery of Rx began with a re-architecture ... * based on Functional Programming the Netflix API - Ben Christensen
  78. 78. ... that collapsed network traffic into coarse API calls ... * based on Functional Programming the Netflix API - Ben Christensen
  79. 79. Iterable pull Observable push T next() throws Exception returns; onNext(T) onError(Exception) onCompleted() !//"Iterable<String>" !//"that"contains"75"Strings !getDataFromLocalMemory() !!.skip(10) !!.take(5) !!.map({!s!%>! !!!return!s!+!"_transformed"}) !!.forEach( .....{!println!"next!=>!"!+!it}) !//"Observable<String>" !//"that"emits"75"Strings !getDataFromNetwork() !!.skip(10) !!.take(5) !!.map({!s!%>! !!!return!s!+!"_transformed"}) !!.subscribe( .....{!println!"onNext!=>!"!+!it}) * based on Functional Programming the Netflix API - Ben Christensen
  80. 80. * based on Functional Programming the Netflix API - Ben Christensen
  81. 81. * based on Functional Programming the Netflix API - Ben Christensen
  82. 82. + = https://github.com/Netflix/Hystrix
  83. 83. HystrixCommand run() failure/circuit open getFallback() public class GetUserPerferencesCommand extends HystrixCommand<UserPreferences> {! // ..//! ! @Override! protected UserPreferences run() {! ! ! // call the UserPreferencesService ! }! ! @Override! protected UserPreferences getFallback() {! !! return UserPreference.empty();! }! }
  84. 84. Monitoring
  85. 85. A MicroService MicroService MicroService MicroService MicroService Logstash Log Aggregation Graphite Metrics and Monitoring
  86. 86. - Correct Functional decomposition is crucial Conclusion - reflect it in a organisational structure (Conway’s law) - pretty hard to get right from the start - A modular system can evolve to microservices - balance the needs (advantages) with the costs (tradeoffs) Are they here to stay? who can tell? but the monolith is dead

×