Slide 1

Slide 1 text

MicroServices a practical overview Martin Eigenbrodt | [email protected] Alexander Heusingfeld | [email protected] #oop2015 #microservices www.innoQ.com

Slide 2

Slide 2 text

Reviewing architectures

Slide 3

Slide 3 text

Generic Architecture Review Results

Slide 4

Slide 4 text

Generic Architecture Review Results Building features takes too long

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Any architecture’s quality is inversely proportional to the number of bottlenecks limiting its evolution, development, and operations — Stefan Tilkov

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

System boundaries

Slide 14

Slide 14 text

Project scope

Slide 15

Slide 15 text

New System Project scope

Slide 16

Slide 16 text

1 Project = 1 System?

Slide 17

Slide 17 text

Size Modularization

Slide 18

Slide 18 text

Size Modularization 1-50 LOC single file

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

System Characteristics

Slide 24

Slide 24 text

System Characteristics Separate (redundant) persistence

Slide 25

Slide 25 text

System Characteristics Separate (redundant) persistence Internal, separate logic

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Macro (technical) architecture Domain architecture

Slide 32

Slide 32 text

JRuby C# Scala Groovy
 Java Clojure

Slide 33

Slide 33 text

RDBMS NoSQL K/V RDBMS RDBMS/DWH NoSQL
 DocDB

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Persistence Logic UI

Slide 36

Slide 36 text

Persistence Logic UI Module A

Slide 37

Slide 37 text

Persistence Logic UI Module A Module B

Slide 38

Slide 38 text

Persistence Logic UI Module A Module B Module C

Slide 39

Slide 39 text

System A Persistence Logic UI System B Persistence Logic UI System C Persistence Logic UI

Slide 40

Slide 40 text

Are this MicroServices?

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Self-Contained System (SCS)

Slide 51

Slide 51 text

SCS Characteristics

Slide 52

Slide 52 text

SCS Characteristics Autonomous web application

Slide 53

Slide 53 text

SCS Characteristics Autonomous web application Owned by one team

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

SCS Microservice

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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 (?)

Slide 65

Slide 65 text

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) ?

Slide 66

Slide 66 text

But why?

Slide 67

Slide 67 text

Isolation

Slide 68

Slide 68 text

(Independent) Scalability

Slide 69

Slide 69 text

Localized decisions

Slide 70

Slide 70 text

Replaceability

Slide 71

Slide 71 text

Playground effect

Slide 72

Slide 72 text

Afraid of chaos?

Slide 73

Slide 73 text

Necessary Rules & Guidelines

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

t System-internal Rules 1.0 1.1 2.0 2.1

Slide 77

Slide 77 text

t System-internal Rules 1.0 1.1 2.0 2.1 Cross-system Rules 1.0 1.1 1.2

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

5. Real-World Examples

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

App DB Browser App App DB DB

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

REST APIs

Slide 94

Slide 94 text

REST APIs Client-specific orchestration

Slide 95

Slide 95 text

REST APIs Client-specific orchestration Streaming architecture

Slide 96

Slide 96 text

Browser DB Service Frontend Service Service DB DB Mobile App Orch 1 Orch 2

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

6. Challenges

Slide 99

Slide 99 text

Organization

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

Surprise: There is a justification for someone to take care of the overall architecture

Slide 104

Slide 104 text

Operations

Slide 105

Slide 105 text

Dev Ops

Slide 106

Slide 106 text

Dev Ops

Slide 107

Slide 107 text

Dev Ops

Slide 108

Slide 108 text

Dev Ops

Slide 109

Slide 109 text

If systems are really separate, they need to be so from start to finish

Slide 110

Slide 110 text

Migration

Slide 111

Slide 111 text

Preconditions

Slide 112

Slide 112 text

Preconditions High business value

Slide 113

Slide 113 text

Preconditions High business value Very high cost of change

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

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

Slide 118

Slide 118 text

Close for change more patterns at http://aim42.org

Slide 119

Slide 119 text

Close for change Enable integrateability
 (auth/auth, navigation) more patterns at http://aim42.org

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

Integration

Slide 125

Slide 125 text

Integration > distributed configuration

Slide 126

Slide 126 text

Integration > distributed configuration > service registration & discovery

Slide 127

Slide 127 text

Integration > distributed configuration > service registration & discovery > resilience

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

Integration Challenges Macro- vs. Micro Architecture

Slide 131

Slide 131 text

Frameworks

Slide 132

Slide 132 text

Dropwizard

Slide 133

Slide 133 text

Dropwizard > Glue Code for well known libraries > Java

Slide 134

Slide 134 text

Dropwizard libraries

Slide 135

Slide 135 text

Dropwizard libraries > Jetty

Slide 136

Slide 136 text

Dropwizard libraries > Jetty > Jersey

Slide 137

Slide 137 text

Dropwizard libraries > Jetty > Jersey > Metrics

Slide 138

Slide 138 text

Dropwizard libraries > Jetty > Jersey > Metrics > Jackson > Guava > Logback > Hibernate Validator > Apache Http Client > JDBI > Liquibase > Freemarker & Mustache > Joda

Slide 139

Slide 139 text

Spring Boot and Spring Cloud

Slide 140

Slide 140 text

Spring Boot

Slide 141

Slide 141 text

Spring Boot > convention over configuration approach

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

Spring Boot > convention over configuration approach > Java, Groovy or Scala > self-contained jar or war > tackles dependency-hell via pre-packaging

Slide 145

Slide 145 text

Spring Cloud

Slide 146

Slide 146 text

Spring Cloud > common patterns in distributed systems

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

Play 2

Slide 152

Slide 152 text

Play 2 > Java or Scala > based on Akka > strong async support

Slide 153

Slide 153 text

Routing

Slide 154

Slide 154 text

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 urls = dao.findItemsForCartId(cartId); ImmutableList products = catalog.resolveProducts(urls); return new ShoppingCartView(products, uriInfo.getAbsolutePath().toString() ); } ... }

Slide 155

Slide 155 text

@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 productUris) {
 counterService.increment("checkouts.withproducts." + productUris.size());
 
 // save products as an order 
 return "redirect:" ORDERS_RESOURCE + savedOrder.getId();
 }
 } Spring Boot

Slide 156

Slide 156 text

Play

Slide 157

Slide 157 text

Play # Routes # List of all books GET / controllers.BooksController.books # A specific Book GET /books/:id controllers.BooksController.book(id:String)

Slide 158

Slide 158 text

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)) } } ... }

Slide 159

Slide 159 text

Configuration

Slide 160

Slide 160 text

Play - Typesafe Config

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

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

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

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

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

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);
 }
 }

Slide 169

Slide 169 text

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);
 }
 }

Slide 170

Slide 170 text

Service Discovery

Slide 171

Slide 171 text

Service Service Discovery Client Service Registry 2. discover service instances 3. call service instance Service Service 1. register service ("myself") & heartbeat

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

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

Slide 175

Slide 175 text

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.

Slide 176

Slide 176 text

Resilience

Slide 177

Slide 177 text

Resilience > isolate Failure > apply graceful degradation > be responsive in case of failure

Slide 178

Slide 178 text

Request service Request service http://en.wikipedia.org/wiki/Circuit_breaker Request service closed open half- open

Slide 179

Slide 179 text

> Provides Command-oriented Integration of Services > Introduces Circuit Breaker, Bulkheads and Isolation > Decouples from Service-dependencies > Provides metrics-facility to protect from failures

Slide 180

Slide 180 text

Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand { @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 } }

Slide 181

Slide 181 text

Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand { @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 } }

Slide 182

Slide 182 text

Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand { @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 } }

Slide 183

Slide 183 text

Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand { @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 } }

Slide 184

Slide 184 text

Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand { @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 } }

Slide 185

Slide 185 text

Hystrix & Dropwizard public class CommandInDropwizard extends TenacityCommand { @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 } }

Slide 186

Slide 186 text

ResolveProductCommand command = new ResolveProductCommand(client, url); Product product = command.execute(); Hystrix & Dropwizard

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

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

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

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() } }

Slide 193

Slide 193 text

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() } }

Slide 194

Slide 194 text

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() } }

Slide 195

Slide 195 text

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() } }

Slide 196

Slide 196 text

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() } }

Slide 197

Slide 197 text

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() } }

Slide 198

Slide 198 text

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() } }

Slide 199

Slide 199 text

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() } }

Slide 200

Slide 200 text

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() } }

Slide 201

Slide 201 text

Deployment

Slide 202

Slide 202 text

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

Slide 203

Slide 203 text

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

Slide 204

Slide 204 text

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

Slide 205

Slide 205 text

Play - Packaging sbt dist sbt debian:packageBin sbt rpm:packageBin

Slide 206

Slide 206 text

Metrics

Slide 207

Slide 207 text

Dropwizard > “Metrics” Integrated with Dropwizard > @Timed on Resources > HTTP Client is already instrumented > JVM Data

Slide 208

Slide 208 text

"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" }

Slide 209

Slide 209 text

Dropwizard Metrics > Exposed over HTTP (as Json) > Exposed as jmx > Others available: stdout, csv, slf4j, ganglia, graphite

Slide 210

Slide 210 text

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

Slide 211

Slide 211 text

{ "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

Slide 212

Slide 212 text

Summary

Slide 213

Slide 213 text

Explicitly design system boundaries Summary

Slide 214

Slide 214 text

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

Slide 215

Slide 215 text

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

Slide 216

Slide 216 text

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

Slide 217

Slide 217 text

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

Slide 218

Slide 218 text

Thank you! Questions? Comments? Martin Eigenbrodt | @eigenbrodtm [email protected] Alexander Heusingfeld | @goldstift [email protected] 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/