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

Microservices - not just with Java

Eberhard Wolff
September 07, 2017

Microservices - not just with Java

This presentation show several options how to implement microservices: the Netflix stack, Consul, and Kubernetes. Also integration options like REST and UI integration are covered.

Eberhard Wolff

September 07, 2017
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. Synchronous Microservices > Service Discovery: IP / port? > Load

    Balancing: Resilience and independent scaling > Routing: Route external request to microservices > Resilience
  4. Why Eureka for Service Discovery? > REST based service registry

    > Supports replication > Caches on the client > Resilient > Fast > Foundation for other services
  5. Eureka Client > @EnableDiscoveryClient: generic > @EnableEurekaClient: specific > Dependency

    on spring-cloud-starter-eureka > Automatically registers application
  6. 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
  7. Proxy Load Balancing > Centralized Load Balancing > Can become

    bottle neck > Single point of failure Load Balancer Server Client
  8. Client Ribbon: Client Side Load Balancing > Decentralized Load Balancing

    > No bottle neck > Resilient > Can consider response time Load Balancer Server
  9. 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
  10. Timeout > Do call in other thread pool > Won’t

    block request handler > Can implement timeout
  11. Circuit Breaker > Called system fails -> open > Open

    -> do not forward call > Forward calls after a time window
  12. Hystrix Configuration > Failure Percentage > Time window until open

    configurable > Time window to reject requests > … > https://github.com/Netflix/Hystrix/wiki/Con figuration
  13. Hystrix & Spring Cloud > Annotation based approach > Annotations

    of javanica libraries > Simplifies Hystrix > No commands
  14. @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public class OrderApp { public static void

    main(String[] args) { SpringApplication.run(OrderApp.class, args); } } Enable Hystrix Need spring-cloud-starter-hystrix
  15. @HystrixCommand(fallbackMethod = "getItemsCache", commandProperties = { @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value

    = "2") } ) public Collection<Item> findAll() { … this.itemsCache = pagedResources.getContent(); return itemsCache; } private Collection<Item> getItemsCache() { return itemsCache; } Fallback
  16. Routing > One URL to the outside > Internal: Many

    Microservices > REST > Or HTML GUI > Hides internal structure (sort of) > Might add filters
  17. Customer Order Catalog Zuul Proxy Automatically maps route to server

    registered on Eureka i.e. /customer/** to CUSTOMER No configuration
  18. Netflix Stack > Service Discovery: Eureka > Load Balancing: Ribbon

    > Routing: Zuul > Resilience: Hystrix > Non-Java microservice: specific clients or sidecar
  19. 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
  20. Kubernetes > Docker container on a single machine: Not resilient

    enough > Kubernetes: Run Docker container in cluster > …and much more!
  21. Pods > Kubernetes runs Pods > Pods = 1..n Docker

    containers > Shared volumes > …and ports
  22. Replica Sets > Deployment creates replica set > Replica sets

    ensure that a certain number of Pods run > ...for load balancing / fail over
  23. 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
  24. 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)
  25. Kubernetes > Service Discovery: DNS > Load Balancing: IP >

    Routing: Load Balancer or Node Port > Resilience: Hystrix? envoy proxy? > Can use any language
  26. UI Integration > Very powerful > Often overlooked > UI

    should be part of a microservices > Self-contained System emphasize UI > http://scs-architecture.org/
  27. 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?
  28. Server-side Integration: Technologies > ESI (Edge Side Include) > E.g.

    Varnish cache > SSI (Server Side Include) > E.g. Apache httpd, Nginx
  29. ESI (Edge Side Includes) ... <header> ... Logged in as:

    Ada Lovelace ... </header> ... <div> ... a lot of static content and images ... </div> ... <div> some dynamic content </div>
  30. ESI (Edge Side Includes) ... <esi:include src="http://example.com/header" /> ... <div>

    ... a lot of static content and images ... </div> ... <esi:include src="http://example.com/dynamic" /> http://www.w3.org/TR/esi-lang
  31. Client-side Integration: Code $("a.embeddable").each(function(i, link) { $("<div />").load(link.href, function(data, status,

    xhr) { $(link).replaceWith(this); }); }); Replace <a href= " " class= "embeddable"> with content of document in a <div> (jQuery)
  32. Transclusion > Tighter coupling than links > …but still very

    loose > Common CSS > (Avoid) common JavaScript > Layout > Look & Feel
  33. 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
  34. Amazon Lambda > Service in the Amazon Cloud > Allows

    you to install individual functions > Java, JavaScript, Python, C#
  35. Amazon Lambda > Upload code (web / command line) >

    Use S3 bucket (Simple Storage Service) > Edit in the browser
  36. Lambda Function Command Line (Tests) Event from Amazon Service i.e.

    database trigger Monitoring Event API Gateway (e.g. REST)
  37. Bundles > Partition system into "bundles” > Bundles can be

    installed, started, stopped, uninstalled and updated > ...at runtime
  38. Code Sharing > Bundles can export and import packages >

    Updating code requires other bundles to start fresh
  39. 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
  40. Calling Bundle Bundle (interface code) Bundle (implementation and service) Service

    Package (interface code) Package (interface code) Update to service in running application
  41. Deployment > JARs e.g. for EJBs > WARs e.g. for

    web application > EARs for JARs and WARs > Completely separated code
  42. 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
  43. Conclusion: Communication > Netflix: Java focus, code dependencies > Kubernetes:

    No code dependencies > UI Integration more decoupling
  44. Conclusion: Operations > Go reduces deployment complexity > Java EE

    and OSGi: less operational complexity, less decoupling > UI Integration more decoupling
  45. 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
  46. EMail [email protected] to get: Slides + Microservices Primer + Sample

    Microservices Book + Sample of Continuous Delivery Book Powered by Amazon Lambda & Microservices