Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices - a practical overview

Microservices - a practical overview

Talk presented at OOP conference 2015 in Munich about MicroServices, Self-Contained Systems, the related challenges and how JVM frameworks address them.

https://www.innoq.com/de/talks/2015/01/talk-microservices-on-the-jvm/

Aba82ecdcf1e1534f2c579d124d8cd35?s=128

Alexander Heusingfeld

January 26, 2015
Tweet

Transcript

  1. MicroServices a practical overview Martin Eigenbrodt | martin.eigenbrodt@innoq.com Alexander Heusingfeld

    | alexander.heusingfeld@innoq.com #oop2015 #microservices www.innoQ.com
  2. Reviewing architectures

  3. Generic Architecture Review Results

  4. Generic Architecture Review Results Building features takes too long

  5. Generic Architecture Review Results Building features takes too long Technical

    debt is well-known and not addressed
  6. Generic Architecture Review Results Building features takes too long Technical

    debt is well-known and not addressed Deployment is way too complicated and slow
  7. Generic Architecture Review Results Building features takes too long Technical

    debt is well-known and not addressed Deployment is way too complicated and slow Architectural quality has degraded
  8. Generic Architecture Review Results Building features takes too long Technical

    debt is well-known and not addressed Deployment is way too complicated and slow Scalability has reached its limit Architectural quality has degraded
  9. Generic Architecture Review Results Building features takes too long Technical

    debt is well-known and not addressed Deployment is way too complicated and slow Scalability has reached its limit Architectural quality has degraded “-ility” problems abound
  10. Generic Architecture Review Results Building features takes too long Technical

    debt is well-known and not addressed Deployment is way too complicated and slow Replacement would be way too expensive Scalability has reached its limit Architectural quality has degraded “-ility” problems abound
  11. Any architecture’s quality is inversely proportional to the number of

    bottlenecks limiting its evolution, development, and operations — Stefan Tilkov
  12. Conway’s Law “Organizations which design systems are constrained to produce

    systems which are copies of the communication structures of these organizations.” – M.E. Conway Organization ˠ Architecture
  13. System boundaries

  14. Project scope

  15. New System Project scope

  16. 1 Project = 1 System?

  17. Size Modularization

  18. Size Modularization 1-50 LOC single file

  19. Size Modularization 1-50 LOC single file 50-500 LOC few files,

    few functions
  20. Size Modularization 1-50 LOC single file 50-500 LOC few files,

    few functions 500-1000 LOC Library, class hierarchy
  21. Size Modularization 1-50 LOC single file 50-500 LOC few files,

    few functions 500-1000 LOC Library, class hierarchy 1000-2000 LOC Framework + application
  22. Size Modularization 1-50 LOC single file 50-500 LOC few files,

    few functions 500-1000 LOC Library, class hierarchy 1000-2000 LOC Framework + application >2000 LOC multiple applications
  23. System Characteristics

  24. System Characteristics Separate (redundant) persistence

  25. System Characteristics Separate (redundant) persistence Internal, separate logic

  26. System Characteristics Separate (redundant) persistence Internal, separate logic Domain models

    & implementation strategies
  27. System Characteristics Separate (redundant) persistence Internal, separate logic Domain models

    & implementation strategies Separate UI
  28. System Characteristics Separate (redundant) persistence Internal, separate logic Domain models

    & implementation strategies Separate UI Separate development & evolution
  29. System Characteristics Separate (redundant) persistence Internal, separate logic Domain models

    & implementation strategies Separate UI Separate development & evolution Limited interaction with other systems
  30. System Characteristics Separate (redundant) persistence Internal, separate logic Domain models

    & implementation strategies Separate UI Separate development & evolution Limited interaction with other systems Autonomous deployment and operations
  31. Macro (technical) architecture Domain architecture

  32. JRuby C# Scala Groovy
 Java Clojure

  33. RDBMS NoSQL K/V RDBMS RDBMS/DWH NoSQL
 DocDB

  34. RDBMS NoSQL K/V RDBMS RDBMS/DWH NoSQL
 DocDB Micro architecture

  35. Persistence Logic UI

  36. Persistence Logic UI Module A

  37. Persistence Logic UI Module A Module B

  38. Persistence Logic UI Module A Module B Module C

  39. System A Persistence Logic UI System B Persistence Logic UI

    System C Persistence Logic UI
  40. Are this MicroServices?

  41. MicroService Characteristics http://martinfowler.com/articles/microservices.html

  42. MicroService Characteristics small http://martinfowler.com/articles/microservices.html

  43. MicroService Characteristics small each running in its own process http://martinfowler.com/articles/microservices.html

  44. MicroService Characteristics small each running in its own process lightweight

    communicating mechanisms (often HTTP) http://martinfowler.com/articles/microservices.html
  45. MicroService Characteristics small each running in its own process lightweight

    communicating mechanisms (often HTTP) built around business capabilities http://martinfowler.com/articles/microservices.html
  46. MicroService Characteristics small each running in its own process lightweight

    communicating mechanisms (often HTTP) built around business capabilities independently deployable http://martinfowler.com/articles/microservices.html
  47. MicroService Characteristics small each running in its own process lightweight

    communicating mechanisms (often HTTP) built around business capabilities independently deployable mininum of centralized management http://martinfowler.com/articles/microservices.html
  48. MicroService Characteristics small each running in its own process lightweight

    communicating mechanisms (often HTTP) built around business capabilities independently deployable mininum of centralized management may be written in different programming languages http://martinfowler.com/articles/microservices.html
  49. MicroService Characteristics small each running in its own process lightweight

    communicating mechanisms (often HTTP) built around business capabilities independently deployable mininum of centralized management may be written in different programming languages may use different data storage technologies http://martinfowler.com/articles/microservices.html
  50. Self-Contained System (SCS)

  51. SCS Characteristics

  52. SCS Characteristics Autonomous web application

  53. SCS Characteristics Autonomous web application Owned by one team

  54. SCS Characteristics Autonomous web application Owned by one team sync

    remote calls discouraged
  55. SCS Characteristics Autonomous web application Owned by one team sync

    remote calls discouraged Service API optional
  56. SCS Characteristics Autonomous web application Owned by one team sync

    remote calls discouraged Service API optional Includes data and logic
  57. SCS Characteristics Autonomous web application Owned by one team sync

    remote calls discouraged Service API optional Includes data and logic No shared UI
  58. SCS Characteristics Autonomous web application Owned by one team sync

    remote calls discouraged Service API optional Includes data and logic No shared UI No or pull-based code sharing only
  59. SCS Microservice

  60. SCS Microservice Size (kLoC) 1-50 0.1-?

  61. SCS Microservice Size (kLoC) 1-50 0.1-? State Self-contained Self-contained

  62. SCS Microservice Size (kLoC) 1-50 0.1-? State Self-contained Self-contained #

    per Logical System 5-25 >100
  63. SCS Microservice Size (kLoC) 1-50 0.1-? State Self-contained Self-contained #

    per Logical System 5-25 >100 Communication between units No (if possible) Yes
  64. SCS Microservice Size (kLoC) 1-50 0.1-? State Self-contained Self-contained #

    per Logical System 5-25 >100 Communication between units No (if possible) Yes UI Included External (?)
  65. SCS Microservice Size (kLoC) 1-50 0.1-? State Self-contained Self-contained #

    per Logical System 5-25 >100 Communication between units No (if possible) Yes UI Included External (?) UI Integration Yes (web-based) ?
  66. But why?

  67. Isolation

  68. (Independent) Scalability

  69. Localized decisions

  70. Replaceability

  71. Playground effect

  72. Afraid of chaos?

  73. Necessary Rules & Guidelines

  74. Necessary Rules & Guidelines Cross-system Responsibilities UI integration Communication protocols

    Data formats Redundant data BI interfaces Logging, Monitoring
  75. Necessary Rules & Guidelines Cross-system Responsibilities UI integration Communication protocols

    Data formats Redundant data BI interfaces Logging, Monitoring System-internal Programming languages Development tools Frameworks Process/Workflow control Persistence Design patterns Coding guidelines
  76. t System-internal Rules 1.0 1.1 2.0 2.1

  77. t System-internal Rules 1.0 1.1 2.0 2.1 Cross-system Rules 1.0

    1.1 1.2
  78. t Domain Architecture 1.0 1.1 System-internal Rules 1.0 1.1 2.0

    2.1 Cross-system Rules 1.0 1.1 1.2
  79. 5. Real-World Examples

  80. Werner Vogels, http://www.allthingsdistributed.com/2006/11/working_backwards.html

  81. 1. Write Press Release Werner Vogels, http://www.allthingsdistributed.com/2006/11/working_backwards.html

  82. 1. Write Press Release 2. Write FAQ Werner Vogels, http://www.allthingsdistributed.com/2006/11/working_backwards.html

  83. 1. Write Press Release 2. Write FAQ 3. Describe Customer

    Experience Werner Vogels, http://www.allthingsdistributed.com/2006/11/working_backwards.html
  84. 1. Write Press Release 2. Write FAQ 3. Describe Customer

    Experience 4. Write User Manual Werner Vogels, http://www.allthingsdistributed.com/2006/11/working_backwards.html
  85. 1. Write Press Release 2. Write FAQ 3. Describe Customer

    Experience 4. Write User Manual …only then start building it! Werner Vogels, http://www.allthingsdistributed.com/2006/11/working_backwards.html
  86. Kraus, Steinacker, Wegner: Teile und Herrsche – Kleine Systeme für

    große Architekturen, http://bit.ly/152cXbx
  87. Kraus, Steinacker, Wegner: Teile und Herrsche – Kleine Systeme für

    große Architekturen, http://bit.ly/152cXbx Independent “Verticals”
  88. Kraus, Steinacker, Wegner: Teile und Herrsche – Kleine Systeme für

    große Architekturen, http://bit.ly/152cXbx Independent “Verticals” REST-based macro architecture
  89. Kraus, Steinacker, Wegner: Teile und Herrsche – Kleine Systeme für

    große Architekturen, http://bit.ly/152cXbx Independent “Verticals” REST-based macro architecture Individual micro architecture
  90. App DB Browser App App DB DB

  91. 2 years in total Scaled to >100 people Finished in

    budget Finished in quality Minimum Viable Product Finished before schedule: October, 24th – 4 months early
  92. None
  93. REST APIs

  94. REST APIs Client-specific orchestration

  95. REST APIs Client-specific orchestration Streaming architecture

  96. Browser DB Service Frontend Service Service DB DB Mobile App

    Orch 1 Orch 2
  97. Netflix Stack Zuul Edge Router Eureka Service Registry Hystrix Stability

    patterns Ribbon HTTP client on steroids Karyon Application blueprint Archaius Configuration Asgard Console Servo Annotation-based metrics … … Many, many more at http://netflix.github.io
  98. 6. Challenges

  99. Organization

  100. Cross-system Responsibilities UI integration Communication protocols Data formats Redundant data

    BI interfaces Logging, Monitoring
  101. Cross-system Responsibilities UI integration Communication protocols Data formats Redundant data

    BI interfaces Logging, Monitoring Product Admin OrderMgmt Catalog Inventory Mgmt Data Export Billing
  102. Cross-system Responsibilities UI integration Communication protocols Data formats Redundant data

    BI interfaces Logging, Monitoring Product Admin OrderMgmt Catalog Inventory Mgmt Data Export Billing Architecture Governance
  103. Surprise: There is a justification for someone to take care

    of the overall architecture
  104. Operations

  105. Dev Ops

  106. Dev Ops

  107. Dev Ops

  108. Dev Ops

  109. If systems are really separate, they need to be so

    from start to finish
  110. Migration

  111. Preconditions

  112. Preconditions High business value

  113. Preconditions High business value Very high cost of change

  114. Preconditions High business value Very high cost of change Very

    slow “time to market”
  115. Preconditions High business value Very high cost of change Very

    slow “time to market” Huge backlog of feature requests
  116. Preconditions High business value Very high cost of change Very

    slow “time to market” Huge backlog of feature requests Problem awareness
  117. Preconditions High business value Very high cost of change Very

    slow “time to market” Huge backlog of feature requests Problem awareness Strong management support
  118. Close for change more patterns at http://aim42.org

  119. Close for change Enable integrateability
 (auth/auth, navigation) more patterns at

    http://aim42.org
  120. Close for change Enable integrateability
 (auth/auth, navigation) Create new system


    for new features more patterns at http://aim42.org
  121. Close for change Enable integrateability
 (auth/auth, navigation) Create new system


    for new features Copy & isolate more patterns at http://aim42.org
  122. Close for change Enable integrateability
 (auth/auth, navigation) Create new system


    for new features Copy & isolate Integrate and/or
 replace part more patterns at http://aim42.org
  123. Close for change Enable integrateability
 (auth/auth, navigation) Create new system


    for new features Copy & isolate Integrate and/or
 replace part more patterns at http://aim42.org
  124. Integration

  125. Integration > distributed configuration

  126. Integration > distributed configuration > service registration & discovery

  127. Integration > distributed configuration > service registration & discovery >

    resilience
  128. Integration > distributed configuration > service registration & discovery >

    resilience > simple deployment & operations
  129. Integration > distributed configuration > service registration & discovery >

    resilience > simple deployment & operations > metrics
  130. Integration Challenges Macro- vs. Micro Architecture

  131. Frameworks

  132. Dropwizard

  133. Dropwizard > Glue Code for well known libraries > Java

  134. Dropwizard libraries

  135. Dropwizard libraries > Jetty

  136. Dropwizard libraries > Jetty > Jersey

  137. Dropwizard libraries > Jetty > Jersey > Metrics

  138. Dropwizard libraries > Jetty > Jersey > Metrics > Jackson

    > Guava > Logback > Hibernate Validator > Apache Http Client > JDBI > Liquibase > Freemarker & Mustache > Joda
  139. Spring Boot and Spring Cloud

  140. Spring Boot

  141. Spring Boot > convention over configuration approach

  142. Spring Boot > convention over configuration approach > Java, Groovy

    or Scala
  143. Spring Boot > convention over configuration approach > Java, Groovy

    or Scala > self-contained jar or war
  144. Spring Boot > convention over configuration approach > Java, Groovy

    or Scala > self-contained jar or war > tackles dependency-hell via pre-packaging
  145. Spring Cloud

  146. Spring Cloud > common patterns in distributed systems

  147. Spring Cloud > common patterns in distributed systems > umbrella

    project for cloud connectors
  148. Spring Cloud > common patterns in distributed systems > umbrella

    project for cloud connectors > build on top of Spring Boot
  149. Spring Cloud > common patterns in distributed systems > umbrella

    project for cloud connectors > build on top of Spring Boot > config server for distributed configuration
  150. Spring Cloud > common patterns in distributed systems > umbrella

    project for cloud connectors > build on top of Spring Boot > config server for distributed configuration > annotations for service-discovery & resilience
  151. Play 2

  152. Play 2 > Java or Scala > based on Akka

    > strong async support
  153. Routing

  154. Dropwizard @Path ("/cart") public class ShoppingCartResource { @GET @Path("{id}") @Timed

    @Produces(MediaType.TEXT_HTML) public ShoppingCartView shoppingCart(@PathParam("id") String cartId, @Context UriInfo uriInfo) { ImmutableList<String> urls = dao.findItemsForCartId(cartId); ImmutableList<Product> products = catalog.resolveProducts(urls); return new ShoppingCartView(products, uriInfo.getAbsolutePath().toString() ); } ... }
  155. @Controller
 @RequestMapping(value = ORDERS_RESOURCE)
 public class OrderController {
 
 private

    @Autowired CounterService counterService;
 private @Autowired OrderRepository repository;
 
 @RequestMapping(method = RequestMethod.POST)
 public String checkoutCart(@RequestParam(value = "products") List<String> productUris) {
 counterService.increment("checkouts.withproducts." + productUris.size());
 
 // save products as an order 
 return "redirect:" ORDERS_RESOURCE + savedOrder.getId();
 }
 } Spring Boot
  156. Play

  157. Play # Routes # List of all books GET /

    controllers.BooksController.books # A specific Book GET /books/:id controllers.BooksController.book(id:String)
  158. Play object BooksController extends Controller { def books = Action.async

    { implicit request => val bestsellerFuture = Bestseller.getBestseller val booksFuture = Books.books for { bestseller <- bestsellerFuture books <- booksFuture } yield { Ok(views.html.books(books.values.toList, bestseller)) } } ... }
  159. Configuration

  160. Play - Typesafe Config

  161. Play - Typesafe Config > Config Library used by akka,

    play and others
  162. Play - Typesafe Config > Config Library used by akka,

    play and others > HOCON - JSON Data Model + syntactic sugar
  163. Play - Typesafe Config > Config Library used by akka,

    play and others > HOCON - JSON Data Model + syntactic sugar > override via system property
  164. Play - Typesafe Config > Config Library used by akka,

    play and others > HOCON - JSON Data Model + syntactic sugar > override via system property > rich merge and include possibilities
  165. Spring Boot @ComponentScan
 @EnableAutoConfiguration
 public class OrderApp {
 
 public

    static void main(String[] args) {
 SpringApplication.run(OrderApp.class, args);
 }
 }
  166. Spring Boot @ComponentScan
 @EnableAutoConfiguration
 public class OrderApp {
 
 public

    static void main(String[] args) {
 SpringApplication.run(OrderApp.class, args);
 }
 }
  167. Spring Boot > opinionated preset @ComponentScan
 @EnableAutoConfiguration
 public class OrderApp

    {
 
 public static void main(String[] args) {
 SpringApplication.run(OrderApp.class, args);
 }
 }
  168. Spring Boot > opinionated preset > HTTP resource “/configprops” shows

    all properties @ComponentScan
 @EnableAutoConfiguration
 public class OrderApp {
 
 public static void main(String[] args) {
 SpringApplication.run(OrderApp.class, args);
 }
 }
  169. Spring Boot > opinionated preset > HTTP resource “/configprops” shows

    all properties > overwrite via application.properties or CLI parameter @ComponentScan
 @EnableAutoConfiguration
 public class OrderApp {
 
 public static void main(String[] args) {
 SpringApplication.run(OrderApp.class, args);
 }
 }
  170. Service Discovery

  171. Service Service Discovery Client Service Registry 2. discover service instances

    3. call service instance Service Service 1. register service ("myself") & heartbeat
  172. Spring Cloud @ComponentScan
 @EnableAutoConfiguration
 @EnableEurekaClient
 public class OrdersApp {
 


    public static void main(String[] args) {
 SpringApplication.run(OrdersApp.class, args);
 }
 }
  173. Spring Cloud @ComponentScan
 @EnableAutoConfiguration
 @EnableEurekaClient
 public class OrdersApp {
 


    public static void main(String[] args) {
 SpringApplication.run(OrdersApp.class, args);
 }
 }
  174. Spring Cloud @ComponentScan
 @EnableAutoConfiguration
 @EnableEurekaClient
 public class OrdersApp {
 


    public static void main(String[] args) {
 SpringApplication.run(OrdersApp.class, args);
 }
 }
  175. Service Discovery with Sidecar Sidecar Client Service Registry Sidecar Service

    2. register service ("myself") & heartbeat 4. discover service instances 5. call service instance 1. health check 3.
  176. Resilience

  177. Resilience > isolate Failure > apply graceful degradation > be

    responsive in case of failure
  178. Request service Request service http://en.wikipedia.org/wiki/Circuit_breaker Request service closed open half-

    open
  179. > Provides Command-oriented Integration of Services > Introduces Circuit Breaker,

    Bulkheads and Isolation > Decouples from Service-dependencies > Provides metrics-facility to protect from failures
  180. Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand<Product> { @Override

    protected Product run() throws Exception { Product product = client.resource(url) .accept(MediaType.APPLICATION_JSON).get(Product.class); return product; } protected Product getFallback() { return FALLBACK_PRODUCT } }
  181. Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand<Product> { @Override

    protected Product run() throws Exception { Product product = client.resource(url) .accept(MediaType.APPLICATION_JSON).get(Product.class); return product; } protected Product getFallback() { return FALLBACK_PRODUCT } }
  182. Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand<Product> { @Override

    protected Product run() throws Exception { Product product = client.resource(url) .accept(MediaType.APPLICATION_JSON).get(Product.class); return product; } protected Product getFallback() { return FALLBACK_PRODUCT } }
  183. Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand<Product> { @Override

    protected Product run() throws Exception { Product product = client.resource(url) .accept(MediaType.APPLICATION_JSON).get(Product.class); return product; } protected Product getFallback() { return FALLBACK_PRODUCT } }
  184. Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand<Product> { @Override

    protected Product run() throws Exception { Product product = client.resource(url) .accept(MediaType.APPLICATION_JSON).get(Product.class); return product; } protected Product getFallback() { return FALLBACK_PRODUCT } }
  185. Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand<Product> { @Override

    protected Product run() throws Exception { Product product = client.resource(url) .accept(MediaType.APPLICATION_JSON).get(Product.class); return product; } protected Product getFallback() { return FALLBACK_PRODUCT } }
  186. ResolveProductCommand command = new ResolveProductCommand(client, url); Product product = command.execute();

    Hystrix & Dropwizard
  187. Spring Cloud Hystrix @HystrixCommand(fallbackMethod = “fallbackProduct") private Pair<String, ResponseEntity<Product>> resolveProduct(String

    productUri) {
 final RestTemplate restTemplate = new RestTemplate();
 return new Pair(productUri, restTemplate.getForEntity(productUri, Product.class));
 } private Pair<String, ResponseEntity<Product>> fallbackProduct(String productUri) {
 final Product product = new Product(productUri, null, BigDecimal.ZERO);
 final ResponseEntity<Product> response = new ResponseEntity<Product>(product, PARTIAL_CONTENT); return new Pair(productUri, response);
 }
  188. Spring Cloud Hystrix @HystrixCommand(fallbackMethod = “fallbackProduct") private Pair<String, ResponseEntity<Product>> resolveProduct(String

    productUri) {
 final RestTemplate restTemplate = new RestTemplate();
 return new Pair(productUri, restTemplate.getForEntity(productUri, Product.class));
 } private Pair<String, ResponseEntity<Product>> fallbackProduct(String productUri) {
 final Product product = new Product(productUri, null, BigDecimal.ZERO);
 final ResponseEntity<Product> response = new ResponseEntity<Product>(product, PARTIAL_CONTENT); return new Pair(productUri, response);
 } auto-wrapped with command!
  189. Spring Cloud Hystrix @HystrixCommand(fallbackMethod = “fallbackProduct") private Pair<String, ResponseEntity<Product>> resolveProduct(String

    productUri) {
 final RestTemplate restTemplate = new RestTemplate();
 return new Pair(productUri, restTemplate.getForEntity(productUri, Product.class));
 } private Pair<String, ResponseEntity<Product>> fallbackProduct(String productUri) {
 final Product product = new Product(productUri, null, BigDecimal.ZERO);
 final ResponseEntity<Product> response = new ResponseEntity<Product>(product, PARTIAL_CONTENT); return new Pair(productUri, response);
 }
  190. Spring Cloud Hystrix @HystrixCommand(fallbackMethod = “fallbackProduct") private Pair<String, ResponseEntity<Product>> resolveProduct(String

    productUri) {
 final RestTemplate restTemplate = new RestTemplate();
 return new Pair(productUri, restTemplate.getForEntity(productUri, Product.class));
 } private Pair<String, ResponseEntity<Product>> fallbackProduct(String productUri) {
 final Product product = new Product(productUri, null, BigDecimal.ZERO);
 final ResponseEntity<Product> response = new ResponseEntity<Product>(product, PARTIAL_CONTENT); return new Pair(productUri, response);
 }
  191. Spring Cloud Hystrix @HystrixCommand(fallbackMethod = “fallbackProduct") private Pair<String, ResponseEntity<Product>> resolveProduct(String

    productUri) {
 final RestTemplate restTemplate = new RestTemplate();
 return new Pair(productUri, restTemplate.getForEntity(productUri, Product.class));
 } private Pair<String, ResponseEntity<Product>> fallbackProduct(String productUri) {
 final Product product = new Product(productUri, null, BigDecimal.ZERO);
 final ResponseEntity<Product> response = new ResponseEntity<Product>(product, PARTIAL_CONTENT); return new Pair(productUri, response);
 } method reference!
  192. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  193. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  194. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  195. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  196. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  197. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  198. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  199. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  200. Play - Circuit Breaker val apiUrl = "..." val breaker

    = CircuitBreaker(Akka.system().scheduler, maxFailures = 5, callTimeout = 2.seconds, resetTimeout = 1.minute) def getBestseller : Future[List[Bestseller]] = { breaker.withCircuitBreaker( WS.url(apiUrl).get.map { response => response.json.as[List[Bestseller]] }).recover { case e => List() } }
  201. Deployment

  202. Spring Boot - Packaging ./gradlew distZip ./gradlew build

  203. Spring Boot - Packaging ./gradlew distZip ./gradlew build ZIP +

    shell-script
  204. Spring Boot - Packaging ./gradlew distZip ./gradlew build ZIP +

    shell-script executable JAR
  205. Play - Packaging sbt dist sbt debian:packageBin sbt rpm:packageBin

  206. Metrics

  207. Dropwizard > “Metrics” Integrated with Dropwizard > @Timed on Resources

    > HTTP Client is already instrumented > JVM Data
  208. "org.apache.http.client.HttpClient.cart.get-requests": { "count": 11, "max": 0.062107, "mean": 0.013355909090909092, "min": 0.005750000000000001,

    "p50": 0.009454, "p75": 0.010427, "p95": 0.062107, "p98": 0.062107, "p99": 0.062107, "p999": 0.062107, "stddev": 0.016285873488729705, "m15_rate": 0, "m1_rate": 0, "m5_rate": 0, "mean_rate": 2.9714422786532126, "duration_units": "seconds", "rate_units": "calls/second" } "cart.resources.ShoppingCartResource.shoppingCart": { "count": 22, "max": 0.136162, "mean": 0.01208109090909091, "min": 0.00093, "p50": 0.008174500000000001, "p75": 0.011782250000000001, "p95": 0.11783499999999976, "p98": 0.136162, "p99": 0.136162, "p999": 0.136162, "stddev": 0.02813530239821426, "m15_rate": 1.8524577712890011, "m1_rate": 0.18057796798879996, "m5_rate": 1.315746847992022, "mean_rate": 0.133050618509084, "duration_units": "seconds", "rate_units": "calls/second" }
  209. Dropwizard Metrics > Exposed over HTTP (as Json) > Exposed

    as jmx > Others available: stdout, csv, slf4j, ganglia, graphite
  210. Spring Boot Metrics > Spring Boot “actuator” module > enables

    HTTP resources for metrics > configurable via application.properties http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#production-ready
  211. { "counter.checkouts.withproducts.3": 4, ... } counterService.increment("checkouts.withproducts." + productUris.size());
 GET /metrics

    HTTP/1.1 Using a counter metric in your Java code… …will display it in the /metrics JSON
  212. Summary

  213. Explicitly design system boundaries Summary

  214. Explicitly design system boundaries Modularize into independent, self-contained systems Summary

  215. Explicitly design system boundaries Modularize into independent, self-contained systems Separate

    micro and macro architectures Summary
  216. Explicitly design system boundaries Modularize into independent, self-contained systems Separate

    micro and macro architectures MicroServices aren’t micro! Summary
  217. Explicitly design system boundaries Modularize into independent, self-contained systems Separate

    micro and macro architectures MicroServices aren’t micro! Strike a balance between control and decentralization Summary
  218. Thank you! Questions? Comments? Martin Eigenbrodt | @eigenbrodtm martin.eigenbrodt@innoq.com Alexander

    Heusingfeld | @goldstift alexander.heusingfeld@innoq.com innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Robert-Bosch-Straße 7 64293 Darmstadt Germany Phone: +49 2173 3366-0 Radlkoferstraße 2 D-81373 München Germany Telefon +49 (0) 89 741185-270 https://www.innoq.com/en/talks/2015/01/talk-microservices-on-the-jvm/