Microservices - not just with Java

Slide 1

Slide 1 text

Microservices – Implementations not only with Java Eberhard Wolff @ewolff Fellow

Slide 2

Slide 2 text

http://continuous-delivery-buch.de/ http://continuous-delivery-book.com/

Slide 3

Slide 3 text

http://microservices-buch.de/ http://microservices-book.com/

Slide 4

Slide 4 text

http://microservices-book.com/ primer.html http://microservices-buch.de/ ueberblick.html FREE!!!!

Slide 5

Slide 5 text

What are Microservices? > Modules providing interfaces > Processes, Containers, virtual machines > Standardized communication: Synchronous, asynchronous, or UI integration > Macro- and Micro-Architecture i.e. clearly defined common, and specific decisions

Slide 6

Slide 6 text

What are Microservices? > Independent Continuous Delivery Pipeline including tests > Standardized Operations (configuration, log analysis, tracing, monitoring, deployment) > Standards on the interface level e.g. not a specific log library > Resilient (compensate failure, crashes …) therefore separate processes, VM, Docker containers

Slide 7

Slide 7 text

Microservices = Extreme Decoupling

Slide 8

Slide 8 text

Operational Complexity Extreme Decoupling

Slide 9

Slide 9 text

Micro Service Micro Service Link Sync Async

Slide 10

Slide 10 text

Synchronous REST Microservices

Slide 11

Slide 11 text

Customer Order Catalog REST internal HTTP external

Slide 12

Slide 12 text

Synchronous Microservices > Service Discovery: IP / port? > Load Balancing: Resilience and independent scaling > Routing: Route external request to microservices > Resilience

Slide 13

Slide 13 text

Synchronous Microservices with Java, Spring Bott / Cloud & the Netflix Stack

Slide 14

Slide 14 text

https://github.com/ ewolff/microservice

Slide 15

Slide 15 text

Service Discovery Eureka

Slide 16

Slide 16 text

Why Eureka for Service Discovery? > REST based service registry > Supports replication > Caches on the client > Resilient > Fast > Foundation for other services

Slide 17

Slide 17 text

Eureka Client > @EnableDiscoveryClient: generic > @EnableEurekaClient: specific > Dependency on spring-cloud-starter-eureka > Automatically registers application

Slide 18

Slide 18 text

Eureka Server @EnableEurekaServer @EnableAutoConfiguration public class EurekaApplication { public static void main(String[] args) { SpringApplication.run(EurekaApplication.class, args); } } Add dependency to spring-cloud-starter-eureka-server

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

Load Balancing Ribbon

Slide 21

Slide 21 text

Proxy Load Balancing > Centralized Load Balancing > Can become bottle neck > Single point of failure Load Balancer Server Client

Slide 22

Slide 22 text

Client Ribbon: Client Side Load Balancing > Decentralized Load Balancing > No bottle neck > Resilient > Can consider response time Load Balancer Server

Slide 23

Slide 23 text

Ribbon Example private LoadBalancerClient loadBalancer; … ServiceInstance instance = loadBalancer.choose("CATALOG"); String url = "http://" + instance.getHost() + ":” + instance.getPort() + "/catalog/"; Via Dependency Injection Eureka name Need dependency to spring-cloud-starter-ribbon

Slide 24

Slide 24 text

Resilience

Slide 25

Slide 25 text

Timeout > Do call in other thread pool > Won’t block request handler > Can implement timeout

Slide 26

Slide 26 text

Circuit Breaker > Called system fails -> open > Open -> do not forward call > Forward calls after a time window

Slide 27

Slide 27 text

Hystrix Configuration > Failure Percentage > Time window until open configurable > Time window to reject requests > … > https://github.com/Netflix/Hystrix/wiki/Con figuration

Slide 28

Slide 28 text

Hystrix & Spring Cloud > Annotation based approach > Annotations of javanica libraries > Simplifies Hystrix > No commands

Slide 29

Slide 29 text

@SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public class OrderApp { public static void main(String[] args) { SpringApplication.run(OrderApp.class, args); } } Enable Hystrix Need spring-cloud-starter-hystrix

Slide 30

Slide 30 text

@HystrixCommand(fallbackMethod = "getItemsCache", commandProperties = { @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "2") } ) public Collection findAll() { … this.itemsCache = pagedResources.getContent(); return itemsCache; } private Collection getItemsCache() { return itemsCache; } Fallback

Slide 31

Slide 31 text

Zuul Routing

Slide 32

Slide 32 text

Routing > One URL to the outside > Internal: Many Microservices > REST > Or HTML GUI > Hides internal structure (sort of) > Might add filters

Slide 33

Slide 33 text

Customer Order Catalog Zuul Proxy Automatically maps route to server registered on Eureka i.e. /customer/** to CUSTOMER No configuration

Slide 34

Slide 34 text

Netflix Stack > Service Discovery: Eureka > Load Balancing: Ribbon > Routing: Zuul > Resilience: Hystrix > Non-Java microservice: specific clients or sidecar

Slide 35

Slide 35 text

Consul > Service Discovery by Hashicorp > DNS interface > Platform independent > Consul Template can fill out config file templates > e.g. for load balancer > …unaware of service discovery

Slide 36

Slide 36 text

https://github.com/ ewolff/microservice-consul

Slide 37

Slide 37 text

Kubernetes

Slide 38

Slide 38 text

https://github.com/ ewolff/microservice- kubernetes

Slide 39

Slide 39 text

Kubernetes > Docker container on a single machine: Not resilient enough > Kubernetes: Run Docker container in cluster > …and much more!

Slide 40

Slide 40 text

Pods > Kubernetes runs Pods > Pods = 1..n Docker containers > Shared volumes > …and ports

Slide 41

Slide 41 text

Replica Sets > Deployment creates replica set > Replica sets ensure that a certain number of Pods run > ...for load balancing / fail over

Slide 42

Slide 42 text

Services > Services ensure access to the Pods > DNS entry > Cluster-wide unique IP address for internal access > Node port … > … or external load balancer for external access

Slide 43

Slide 43 text

Replica Set Pod Pod Service starts DNS Cluster IP address Load Balancer Deployment creates

Slide 44

Slide 44 text

Load Balancer Kubernetes Cluster Server Service 1 Service 2 Kubernetes Cluster Server Service 1 Service 2 Service adds a load balancer Load Balancer (e.g. Amazon Elastic Load Balancer)

Slide 45

Slide 45 text

Kubernetes > Service Discovery: DNS > Load Balancing: IP > Routing: Load Balancer or Node Port > Resilience: Hystrix? envoy proxy? > Can use any language

Slide 46

Slide 46 text

No code dependencies on Kubernetes!

Slide 47

Slide 47 text

UI Integration

Slide 48

Slide 48 text

UI Integration > Very powerful > Often overlooked > UI should be part of a microservices > Self-contained System emphasize UI > http://scs-architecture.org/

Slide 49

Slide 49 text

Hyperlinks to navigate between systems. System 1 System 2

Slide 50

Slide 50 text

Transclusion of content served by another application System 1 System 2

Slide 51

Slide 51 text

https://www.innoq.com/ en/blog/transclusion/

Slide 52

Slide 52 text

UI Integration > Extremely decoupled > Here is a link: http://ewolff.com > No need to know anything else about the system > What about more complex transclusion?

Slide 53

Slide 53 text

Server-side integration > Centralized aggregation > Bottleneck (runtime/development time) Browser UI 1 UI 2 Frontend Server Backend 1 Backend 2

Slide 54

Slide 54 text

Server-side Integration: Technologies > ESI (Edge Side Include) > E.g. Varnish cache > SSI (Server Side Include) > E.g. Apache httpd, Nginx

Slide 55

Slide 55 text

ESI (Edge Side Includes) ... ... Logged in as: Ada Lovelace ... ...

... a lot of static content and images ...

...

some dynamic content

Slide 56

Slide 56 text

ESI (Edge Side Includes) ... ...

... a lot of static content and images ...

... http://www.w3.org/TR/esi-lang

Slide 57

Slide 57 text

https://github.com/ ewolff/SCS-ESI

Slide 58

Slide 58 text

Client-side integration Browser UI 1 UI 2 Backend 1 Backend 2

Slide 59

Slide 59 text

Client-side Integration: Code $("a.embeddable").each(function(i, link) { $("

").load(link.href, function(data, status, xhr) { $(link).replaceWith(this); }); }); Replace with content of document in a

(jQuery)

Slide 60

Slide 60 text

Transclusion > Tighter coupling than links > …but still very loose > Common CSS > (Avoid) common JavaScript > Layout > Look & Feel

Slide 61

Slide 61 text

https://github.com/ ewolff/SCS-jQuery

Slide 62

Slide 62 text

Morgen 11:20

Slide 63

Slide 63 text

Operational Complexity Extreme Decoupling

Slide 64

Slide 64 text

Can you simplify operations?

Slide 65

Slide 65 text

Reduce Operational Complexity > Go provides statically linked binaries > No additional binaries > No additional dynamic libraries > Docker container just contains one file > No Linux distribution > Simplest deployment

Slide 66

Slide 66 text

Amazon Lambda

Slide 67

Slide 67 text

Amazon Lambda > Service in the Amazon Cloud > Allows you to install individual functions > Java, JavaScript, Python, C#

Slide 68

Slide 68 text

Amazon Lambda > Upload code (web / command line) > Use S3 bucket (Simple Storage Service) > Edit in the browser

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

Lambda Function Command Line (Tests) Event from Amazon Service i.e. database trigger Monitoring Event API Gateway (e.g. REST)

Slide 71

Slide 71 text

Monitoring built-in!

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

Lambda simplifies operations and deployment.

Slide 75

Slide 75 text

Lambda allows many small services.

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

Bundles > Partition system into "bundles” > Bundles can be installed, started, stopped, uninstalled and updated > ...at runtime

Slide 78

Slide 78 text

Code Sharing > Bundles can export and import packages > Updating code requires other bundles to start fresh

Slide 79

Slide 79 text

Services > Bundles can publish services… dynamically! > Service = Java Object > Service Registry allows other bundles to consume services > Services come and go at runtime > Quite easy with OSGi Blueprints or OSGi Declarative Services

Slide 80

Slide 80 text

Calling Bundle Bundle (interface code) Bundle (implementation and service) Service Package (interface code) Package (interface code) Update to service in running application

Slide 81

Slide 81 text

Operational Complexity Extreme Decoupling

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

Deployment > JARs e.g. for EJBs > WARs e.g. for web application > EARs for JARs and WARs > Completely separated code

Slide 84

Slide 84 text

Microservices > Microservice = 1 WAR / JAR + application server (Spring / plain Java EE) > Microservice = Fat JAR (Spring Boot / Wildfly Swarm) > Per microservice decision > App server more complex and dead > https://www.slideshare.net/ewolff/java- application-servers-are-dead

Slide 85

Slide 85 text

Alternative > Might help: Deployment model > i.e. application server > More services per JVM

Slide 86

Slide 86 text

Tomcat Java EE Server order.war customer.war catalog.war Customer

Slide 87

Slide 87 text

Operational Complexity Extreme Decoupling

Slide 88

Slide 88 text

Conclusion

Slide 89

Slide 89 text

Operational Complexity Extreme Decoupling

Slide 90

Slide 90 text

Conclusion: Communication > Netflix: Java focus, code dependencies > Kubernetes: No code dependencies > UI Integration more decoupling

Slide 91

Slide 91 text

Conclusion: Operations > Go reduces deployment complexity > Java EE and OSGi: less operational complexity, less decoupling > UI Integration more decoupling

Slide 92

Slide 92 text

Links > List of microservices demos (sync, async, UI): http://ewolff.com/microservices-demos.html > REST vs. Messaging for Microservices https://www.slideshare.net/ewolff/rest-vs- messaging-for-microservices

Slide 93

Slide 93 text

EMail herbstcampus2017@ewolff.com to get: Slides + Microservices Primer + Sample Microservices Book + Sample of Continuous Delivery Book Powered by Amazon Lambda & Microservices