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.
μServices Architecture
● SA at EPAM Systems
● primary skill is Java
● hands-on-coding with Groovy, Ruby
● trying to learn some Scala and Erlang
●...
Agenda
● What is this?
● Architecture
● Case study
● Existing tools
● Summary
● How to get there?
● Q&A
● Small (10-100 LOC)
Overview
● Small (10-100 LOC)
● Lightweight (run several per box)
Overview
● Small (10-100 LOC)
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
Overview
● Small (10-100 LOC)
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (d...
● Small (10-100 LOC)
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (d...
● Small (10-100 LOC)
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (d...
● Design
● Implementation
● Delivery
● Monitoring
Architecture
Design
● What ab SOA?
● Externalize Configuration
● Versioning
● Communication Contract
● Asynchronicity
● Reusability
● S...
What ab SOA?
● Sensible idea
● Combat challenges of large monolithic
applications
● Lack of guidance
Externalize Configuration
● Support for X > 1 environments
● Run-time changes
Versioning
● Leave multiple old microservice versions running
● Fast introduction vs. slow retirement asymmetry
Communication Contract
● Own service - own client
● Thin transport
Asynchronicity
● Non-blocking
● Reactive model
● Messaging to send and forget
Reusability
● Each service does one dedicated thing
● Utilize suitable components/frameworks
● Cohesive
● Stateless
● Independent
Scalability
● Fault-tolerance
● Introduce failures
Availability
Implementation
● Separate Concerns
Separate Concerns
● Inverse Conway’s law – teams own service groups
Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One de...
Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One de...
Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One de...
Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One de...
Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One de...
Delivery
● Disposability
● Containerisation
● Build
● Run
● Destroy
Disposability
● Container as deployment artifact
● Environment agnostic
● New version - new container
● All dependencies built in
Contai...
● Blue-green pattern
● Feature toggle
● Database migration/versioning
Zero-down-time
Frequency
● Fast rollouts
● Fast rollbacks
● Technical
● Business
● Stats
Monitoring
● Hardware monitoring
● Resources utilisation
● Health checking
Technical monitoring
● Business aware metrics
● A/B testing metrics
Business monitoring
● Increased traffic velocity makes individual events
less important
● More vertical components requires more
measurement
●...
Benefits
● Polyglot technology stack
● Polyglot persistence
● Frameworks
● Thin transport
Toolset unchained
● HTTP stack
● Independent provisioning
● Fine tuning
● Elasticity
Scalability
● Development
● Testing
● Deployment
● Reliability
Independence
Shortcomings
● More responsibility from Devs to support Ops
Shortcomings
● More responsibility from Devs to support Ops
● Polyglot infrastructure (if any)
Shortcomings
● More responsibility from Devs to support Ops
● Polyglot infrastructure (if any)
● Orchestration
Shortcomings
● More responsibility from Devs to support Ops
● Polyglot infrastructure (if any)
● Orchestration
● Costs
Shortcomings
Twitter before
Twitter now*
Twitter requests
● Speed wins in the marketplace
Lessons learned
● Speed wins in the marketplace
● Remove friction from product development
Lessons learned
● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
Lessons learned
● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and respons...
● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and respons...
● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and respons...
● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and respons...
Toolset
● Dropwizard
● Spring Boot
● Vert.X
● More...
Dropwizard http://dropwizard.github.io/dropwizard/
Java framework for developing ops-
friendly, high-performance, RESTful
...
Spring Boot http://projects.spring.io/spring-boot/
Takes an opinionated view of
building production-ready Spring
applicati...
Vert.X http://vertx.io/
● Lightweight, reactive, application
platform
● Superficially similar to Node.js -
but not a clone...
More...
● Ratpack http://www.ratpack.io/
● Sinatra http://www.sinatrarb.com/
● Webbit https://github.com/webbit/webbit
● F...
Summary
Summary
● Speed wins in the marketplace
Summary
● Speed wins in the marketplace
● Separated concerns at app level
Summary
● Speed wins in the marketplace
● Separated concerns at app level
● Focused and automated
Summary
● Speed wins in the marketplace
● Separated concerns at app level
● Focused and automated
● Elastically scalable
Summary
● Speed wins in the marketplace
● Separated concerns at app level
● Focused and automated
● Elastically scalable
●...
● Automate repeating activities
● “Run what you wrote” – root access and duty
● Freedom and responsibility for developers
...
References
● http://martinfowler.com/articles/microservices.html
● http://yobriefca.se/blog/2013/04/28/micro-service-
arch...
Q&A
Izzet Mustafayev@EPAM Systems
@webdizz webdizz izzetmustafaiev
http://webdizz.name
Microservices Architecture
Microservices Architecture
Microservices Architecture
Microservices Architecture
Microservices Architecture
Upcoming SlideShare
Loading in …5
×

Microservices Architecture

7,357 views

Published on

Modern HA applications in nowadays are developed with set of small focused and discrete microservices. It's a trending concept and opens/solves questions like maintenance, scaling, live-deployments, security, fault-tolerance etc.

Published in: Technology
  • I have always found it hard to meet the requirements of being a student. Ever since my years of high school, I really have no idea what professors are looking for to give good grades. After some google searching, I found this service ⇒ www.HelpWriting.net ⇐ who helped me write my research paper.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! I can recommend a site that has helped me. It's called ⇒ www.WritePaper.info ⇐ So make sure to check it out!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Microservices Architecture

  1. 1. μServices Architecture
  2. 2. ● SA at EPAM Systems ● primary skill is Java ● hands-on-coding with Groovy, Ruby ● trying to learn some Scala and Erlang ● passionate about agile, clean code and devops Izzet Mustafayev@EPAM Systems @webdizz webdizz izzetmustafaiev http://webdizz.name
  3. 3. Agenda ● What is this? ● Architecture ● Case study ● Existing tools ● Summary ● How to get there? ● Q&A
  4. 4. ● Small (10-100 LOC) Overview
  5. 5. ● Small (10-100 LOC) ● Lightweight (run several per box) Overview
  6. 6. ● Small (10-100 LOC) ● Lightweight (run several per box) ● Takes strength of platform/language (polyglot) Overview
  7. 7. ● Small (10-100 LOC) ● Lightweight (run several per box) ● Takes strength of platform/language (polyglot) ● Independent (development/deployment) Overview
  8. 8. ● Small (10-100 LOC) ● Lightweight (run several per box) ● Takes strength of platform/language (polyglot) ● Independent (development/deployment) ● Stateless (everything persisted in DB) Overview
  9. 9. ● Small (10-100 LOC) ● Lightweight (run several per box) ● Takes strength of platform/language (polyglot) ● Independent (development/deployment) ● Stateless (everything persisted in DB) ● Monitored (health and business value) Overview
  10. 10. ● Design ● Implementation ● Delivery ● Monitoring Architecture
  11. 11. Design ● What ab SOA? ● Externalize Configuration ● Versioning ● Communication Contract ● Asynchronicity ● Reusability ● Scalability ● Availability
  12. 12. What ab SOA? ● Sensible idea ● Combat challenges of large monolithic applications ● Lack of guidance
  13. 13. Externalize Configuration ● Support for X > 1 environments ● Run-time changes
  14. 14. Versioning ● Leave multiple old microservice versions running ● Fast introduction vs. slow retirement asymmetry
  15. 15. Communication Contract ● Own service - own client ● Thin transport
  16. 16. Asynchronicity ● Non-blocking ● Reactive model ● Messaging to send and forget
  17. 17. Reusability ● Each service does one dedicated thing ● Utilize suitable components/frameworks
  18. 18. ● Cohesive ● Stateless ● Independent Scalability
  19. 19. ● Fault-tolerance ● Introduce failures Availability
  20. 20. Implementation ● Separate Concerns
  21. 21. Separate Concerns ● Inverse Conway’s law – teams own service groups
  22. 22. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice
  23. 23. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice
  24. 24. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice ● Each microservice is it’s own build
  25. 25. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice ● Each microservice is it’s own build ● Stateful cached data access layer
  26. 26. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice ● Each microservice is it’s own build ● Stateful cached data access layer ● Lightweight mocked dependencies
  27. 27. Separate Concerns ● Inverse Conway’s law – teams own service groups ● One “verb” per single function microservice ● One developer independently produces a microservice ● Each microservice is it’s own build ● Stateful cached data access layer ● Lightweight mocked dependencies ● Easy to run locally
  28. 28. Delivery ● Disposability ● Containerisation
  29. 29. ● Build ● Run ● Destroy Disposability
  30. 30. ● Container as deployment artifact ● Environment agnostic ● New version - new container ● All dependencies built in Containerisation
  31. 31. ● Blue-green pattern ● Feature toggle ● Database migration/versioning Zero-down-time
  32. 32. Frequency ● Fast rollouts ● Fast rollbacks
  33. 33. ● Technical ● Business ● Stats Monitoring
  34. 34. ● Hardware monitoring ● Resources utilisation ● Health checking Technical monitoring
  35. 35. ● Business aware metrics ● A/B testing metrics Business monitoring
  36. 36. ● Increased traffic velocity makes individual events less important ● More vertical components requires more measurement ● Failure Rate is more informative than individual failures Stats matter on scale
  37. 37. Benefits
  38. 38. ● Polyglot technology stack ● Polyglot persistence ● Frameworks ● Thin transport Toolset unchained
  39. 39. ● HTTP stack ● Independent provisioning ● Fine tuning ● Elasticity Scalability
  40. 40. ● Development ● Testing ● Deployment ● Reliability Independence
  41. 41. Shortcomings
  42. 42. ● More responsibility from Devs to support Ops Shortcomings
  43. 43. ● More responsibility from Devs to support Ops ● Polyglot infrastructure (if any) Shortcomings
  44. 44. ● More responsibility from Devs to support Ops ● Polyglot infrastructure (if any) ● Orchestration Shortcomings
  45. 45. ● More responsibility from Devs to support Ops ● Polyglot infrastructure (if any) ● Orchestration ● Costs Shortcomings
  46. 46. Twitter before
  47. 47. Twitter now*
  48. 48. Twitter requests
  49. 49. ● Speed wins in the marketplace Lessons learned
  50. 50. ● Speed wins in the marketplace ● Remove friction from product development Lessons learned
  51. 51. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process Lessons learned
  52. 52. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process ● Freedom and responsibility culture Lessons learned
  53. 53. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process ● Freedom and responsibility culture ● Simple patterns automated by tooling Lessons learned
  54. 54. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process ● Freedom and responsibility culture ● Simple patterns automated by tooling ● Microservices for speed and availability Lessons learned
  55. 55. ● Speed wins in the marketplace ● Remove friction from product development ● High trust, low process ● Freedom and responsibility culture ● Simple patterns automated by tooling ● Microservices for speed and availability ● Use statistics to monitor behavior Lessons learned
  56. 56. Toolset ● Dropwizard ● Spring Boot ● Vert.X ● More...
  57. 57. Dropwizard http://dropwizard.github.io/dropwizard/ Java framework for developing ops- friendly, high-performance, RESTful web services. - pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package - has out-of-the-box support for sophisticated configuration, application metrics, logging, operational tools, and much more
  58. 58. Spring Boot http://projects.spring.io/spring-boot/ Takes an opinionated view of building production-ready Spring applications. - favors convention over configuration and is designed to get you up and running as quickly as possible. - production-ready features such as metrics, health checks and externalized configuration
  59. 59. Vert.X http://vertx.io/ ● Lightweight, reactive, application platform ● Superficially similar to Node.js - but not a clone! ● Inspired also from Erlang/OTP ● Polyglot ● High performance ● Simple but not simplistic
  60. 60. More... ● Ratpack http://www.ratpack.io/ ● Sinatra http://www.sinatrarb.com/ ● Webbit https://github.com/webbit/webbit ● Finagle http://twitter.github.io/finagle/ ● Connect http://www.senchalabs.org/connect/ ● XDropWizard https://github.com/timmolter/XDropWizard
  61. 61. Summary
  62. 62. Summary ● Speed wins in the marketplace
  63. 63. Summary ● Speed wins in the marketplace ● Separated concerns at app level
  64. 64. Summary ● Speed wins in the marketplace ● Separated concerns at app level ● Focused and automated
  65. 65. Summary ● Speed wins in the marketplace ● Separated concerns at app level ● Focused and automated ● Elastically scalable
  66. 66. Summary ● Speed wins in the marketplace ● Separated concerns at app level ● Focused and automated ● Elastically scalable ● Polyglot architecture
  67. 67. ● Automate repeating activities ● “Run what you wrote” – root access and duty ● Freedom and responsibility for developers How to get there?
  68. 68. References ● http://martinfowler.com/articles/microservices.html ● http://yobriefca.se/blog/2013/04/28/micro-service- architecture/ ● http://goo.gl/4dOVjj ● http://goo.gl/RGgnd3 ● http://goo.gl/TmZ4Ee ● http://12factor.net/ ● http://goo.gl/tnPxLP
  69. 69. Q&A
  70. 70. Izzet Mustafayev@EPAM Systems @webdizz webdizz izzetmustafaiev http://webdizz.name

×