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/

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
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/