Four Times Microservices: REST, Kubernetes, UI Integration, Aync

How you can build microservices:
- REST with the Netflix stack (Eureka for Service Discovery, Ribbon for Load Balancing, Hystrix for Resilience, Zuul for Routing)
- REST with Consul for Services Discovery
- REST with Kubernetes
- UI integration with ESI (Edge Side Includes)
- UI integration on the client with JavaScript
- Async with Apache Kafka
- Async with HTTP + Atom

Transcript

1. Four times Microservices: REST, Kubernetes, UI Integration, Async Eberhard Wolff @ewolff http://ewolff.com Fellow
2. http://continuous-delivery-buch.de/ http://continuous-delivery-book.com/
3. http://microservices-buch.de/ http://microservices-book.com/
4. http://microservices-book.com/ primer.html http://microservices-buch.de/ ueberblick.html FREE!!!!
5. What are Microservices? > Modules providing interfaces > Processes, Containers, virtual machines
6. What are Microservices? > Independent Continuous Delivery Pipeline including tests > Standardized Operations (configuration, log analysis, tracing, monitoring, deployment) > Resilient (compensate failure, crashes …) therefore separate processes, VM, Docker containers
7. Microservices = Extreme Decoupling
8. Operational Complexity Extreme Decoupling
9. Micro Service Micro Service Link Sync Async
10. Synchronous REST Microservices
11. Customer Order Catalog REST internal HTTP external
12. Synchronous Microservices > Service Discovery: IP / port? > Load Balancing: Resilience and independent scaling > Routing: Route external request to microservices > Resilience
13. Synchronous Microservices with Java, Spring Boot / Cloud & the Netflix Stack
14. https://github.com/ ewolff/microservice
15. Service Discovery Eureka
16. Why Eureka for Service Discovery? > REST based service registry > Supports replication > Caches on the client > Resilient > Fast > Foundation for other services
17. Eureka Client > @EnableDiscoveryClient: generic > @EnableEurekaClient: specific > Dependency on spring-cloud-starter-eureka > Automatically registers application
18. 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
20. Load Balancing Ribbon
21. Client Ribbon: Client Side Load Balancing > Decentralized Load Balancing > No bottle neck > Resilient Load Balancer Server
22. 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
23. Resilience
24. Timeout > Do call in other thread pool > Won’t block request handler > Can implement timeout
25. Circuit Breaker > Called system fails -> open > Open -> do not forward call > Forward calls after a time window
26. Hystrix & Spring Cloud > Annotation based approach > Annotations of javanica libraries > Simplifies Hystrix > No commands
27. @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public class OrderApp { public static void main(String[] args) { SpringApplication.run(OrderApp.class, args); } } Enable Hystrix Need spring-cloud-starter-hystrix
28. @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
29. Zuul Routing
30. Routing > One URL to the outside > Internal: Many Microservices > REST > Or HTML GUI > Hides internal structure (sort of) > Might add filters
31. Customer Order Catalog Zuul Proxy Automatically maps route to server registered on Eureka i.e. /customer/** to CUSTOMER No configuration
32. Netflix Stack > Service Discovery: Eureka > Load Balancing: Ribbon > Routing: Zuul > Resilience: Hystrix > Non-Java microservice: specific clients or sidecar
33. 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
34. https://github.com/ ewolff/microservice-consul
35. Kubernetes
36. https://github.com/ ewolff/microservice- kubernetes
37. Kubernetes > Docker container on a single machine: Not resilient enough > Kubernetes: Run Docker container in cluster > …and much more!
38. Pods > Kubernetes runs Pods > Pods = 1..n Docker containers > Shared volumes > …and ports
39. Replica Sets > Deployment creates replica set > Replica sets ensure that a certain number of Pods run > ...for load balancing / fail over
40. 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
41. Replica Set Pod Pod Service starts DNS Cluster IP address Load Balancer Deployment creates
42. 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)
43. Kubernetes > Service Discovery: DNS > Load Balancing: IP > Routing: Load Balancer or Node Port > Resilience: Hystrix? envoy proxy? > Can use any language
44. No code dependencies on Kubernetes!
45. UI Integration
46. UI Integration > Very powerful > Often overlooked > UI should be part of a microservices > Self-contained System emphasize UI > http://scs-architecture.org/
47. Hyperlinks to navigate between systems. System 1 System 2
48. Transclusion of content served by another application System 1 System 2
49. https://www.innoq.com/ en/blog/transclusion/
50. 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?
51. Server-side integration Browser UI 1 UI 2 Frontend Server Backend 1 Backend 2
52. Server-side Integration: Technologies > ESI (Edge Side Include) > E.g. Varnish cache > SSI (Server Side Include) > E.g. Apache httpd, Nginx
53. 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>
54. 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
55. https://github.com/ ewolff/SCS-ESI
56. Client-side integration Browser UI 1 UI 2 Backend 1 Backend 2
57. 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)
58. https://github.com/ ewolff/SCS-jQuery
59. https://github.com/ ewolff/crimson- insurance-demo
60. Asynchronous Microservices
61. Asynchronous > Do not talk to other microservices > ...and wait for a reply > …while processing a request. > Either don‘t wait for a reply > ...or don‘t communicate while processing a request.
62. Asynchronous: Benefits > Deals with unreliable systems > Can guarantee delivery > Good fit for events > …and Bounded Context / DDD
63. Order Invoice Delivery
64. Kafka
65. https://github.com/ ewolff/microservice-kafka
66. Kafka API > Producer API > Consumer API > Streams API (transformation)
67. Kafka Records > Key > Value > Timestamp > No headers > Stored forever (!) Record Key Value Timestamp
68. Kafka Topics > Named > Topics have partitions > Order guaranteed per partition > Consumer commits offset per partition > Consumer group: One consumer per partition Topic Partition Record Record Record
69. Topic Partition Record Record Record Producer Offset Offset committed per consumer Offset Partition Record Record Record Partition Record Record Record
70. Log Compaction > Remove all but the latest record with a given key > Idea: Old events not relevant > …if new events override > Efficient storage in the long run Partition Record id=42 Record id=23 Record id=42
71. Kafka Replication > N Replicas (configurable) > In-sync replicas (configurable): write successful if all written
72. Asynchronous Microservices > Service Discovery: via topic > Load Balancing: via partitions / consumer groups > Routing: ./. > Resilience service fails – latency increases
73. Kafka Conclusion > Provides access to old events > Guaranteed order per key > (Log compaction also per key) > Consumer groups send records to one consumer > Additional (complex) infrastructure
74. REST & ATOM
75. https://github.com/ ewolff/microservice-atom
76. Atom > Data format > …for feeds, blogs, podcasts etc > Access through HTTP > Idea: Provide a feeds of events / orders
77. <feed xmlns="http://www.w3.org/2005/Atom"> <title>Order</title> <link rel="self" href="http://localhost:8080/feed" /> <author><name>Big Money Inc.</name> </author> <subtitle>List of all orders</subtitle> <id>https://github.com/ewolff/microservice- atom/order</id> <updated>2017-04-20T15:28:50Z</updated> <entry> ... </entry> </feed>
78. <entry> <title>Order 1</title> <id>https://github.com/ewolff/microservice- atom/order/1</id> <updated>2017-04-20T15:27:58Z</updated> <content type="application/json“ src="http://localhost:8080/order/1" /> <summary>This is the order 1</summary> </entry>
79. Atom Feed > Some unneeded information > …but not a lot > Mostly links to details > ...and timestamps > Can use content negotiation to provide different data formats or details
80. Subscribing to Feed > Poll the feed (HTTP GET) > Client decides when to process new events > …but very inefficient > Lots of unchanged data
81. HTTP Caching > Client GETs feed > Server send data > + Last-Modified header > Client sends get > + If-Modified-Since header > Server: 304 (Not modified) > …or new data
82. REST can be asynchronous.
83. Atom > Service Discovery: REST > Load Balancing: REST > Routing: ./. > Resilience failures just increase latency
84. Atom Conclusion > Can provides access to old events if they are stored anyway. > One consumer: idempotency > No additional infrastructure
85. Conclusion
86. Operational Complexity Extreme Decoupling
87. Conclusion: Communication > Netflix: Java focus, code dependencies > Kubernetes: No code dependencies > UI Integration: more decoupling > Asynchronous deals with challenges in distributed systems
88. 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
89. EMail bedcon2017@ewolff.com to get: Slides + Microservices Primer + Sample Microservices Book + Sample of Continuous Delivery Book Powered by Amazon Lambda & Microservices