Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Spring Cloud Gateway - Nate Schutta

169 views

Published on

Spring Cloud Gateway- Nate Schutta

Published in: Software
  • Be the first to comment

Spring Cloud Gateway - Nate Schutta

  1. 1. Spring Cloud Gateway @ntschutta ntschutta.io Nathaniel Schutta
  2. 2. https://content.pivotal.io/ ebooks/thinking-architecturally
  3. 3. Ah, microservices!
  4. 4. Kind of the in thing these days…
  5. 5. And everything that entails!
  6. 6. Lot of teams are adopting microservices…
  7. 7. Only to discover some assembly required.
  8. 8. Think about all the things a cloud native app needs…
  9. 9. Service registry. Circuit breaker. Config server. UAA.
  10. 10. Spring Cloud Services!
  11. 11. And, often, an API gateway.
  12. 12. What would you say that is?
  13. 13. Why would you need one?
  14. 14. What are my options?
  15. 15. Why should I consider Spring Cloud Gateway?
  16. 16. Why do i need A Gateway?
  17. 17. Remember the monolith?
  18. 18. It was a simpler time…
  19. 19. The Monolith The Browser HTTP Request HTTP Response
  20. 20. What is our target resolution?
  21. 21. Away we went!
  22. 22. Well, we’d argue about some things…
  23. 23. But things changed.
  24. 24. The Monolith The Browser HTTP Request HTTP Response
  25. 25. The Monolith (with a side of REST) The Browser HTTP Request Mobile Apps XML/JSON Res HTTP Request XML/JSON Res
  26. 26. You get an API, and *you* get and API, and YOU get an API!
  27. 27. What caused this Cambrian explosion of APIs?
  28. 28. Technology changes.
  29. 29. Reaction to monoliths and heavy weight services.
  30. 30. As well as cloud environments.
  31. 31. https://mobile.twitter.com/linux/status/936877536780283905?lang=en
  32. 32. But it didn’t stop there…
  33. 33. Enter the microservice.
  34. 34. The Monolith (with a side of REST) The Browser HTTP Request Mobile Apps XML/JSON Res HTTP Request XML/JSON Res
  35. 35. The Browser Mobile Apps Microservice Microservice Microservice Microservice Microservice
  36. 36. Before you know it…
  37. 37. http://evolutionaryarchitecture.com
  38. 38. Please Microservice Responsibly. https://content.pivotal.io/blog/should-that-be-a- microservice-keep-these-six-factors-in-mind
  39. 39. Shoot. What do we do now?
  40. 40. More architectural patterns, more problems.
  41. 41. How do we facilitate communication?
  42. 42. API Gateway pattern. https://microservices.io/patterns/apigateway.html
  43. 43. Forces.
  44. 44. API granularity mismatch.
  45. 45. Different clients need different data!
  46. 46. Services are dynamic.
  47. 47. Backend for front-end variation.
  48. 48. Each client gets their own gateway.
  49. 49. Enter the API Gateway!
  50. 50. The Browser Mobile Apps Microservice Microservice Microservice Microservice Microservice
  51. 51. The Browser Mobile Apps Microservice Microservice Microservice Microservice Microservice APIGateway
  52. 52. Gateways are not, in fact, magic sparkle ponies...
  53. 53. Sorry about that.
  54. 54. Use them wisely.
  55. 55. Isn’t this just an ESB?
  56. 56. Saw that movie…know how it ends.
  57. 57. The principles of ESB aren’t bad.
  58. 58. Potential to recreate the worst of the ESB era…
  59. 59. Single point of failure.
  60. 60. Tickets on top of tickets. With a side of tickets. And more tickets.
  61. 61. Development bottleneck.
  62. 62. Feature bloat.
  63. 63. Doesn’t have to be that way!
  64. 64. Just a tool.
  65. 65. Gateway Features
  66. 66. Routing.
  67. 67. Surgical Routing.
  68. 68. Canarying.
  69. 69. Resiliency.
  70. 70. Monolith Strangling. https://www.martinfowler.com/bliki/StranglerApplication.html
  71. 71. Even better - data driven strangler. https://content.pivotal.io/slides/strangling-the- monolith-with-a-data-driven-approach-a-case-study
  72. 72. Security.
  73. 73. Monitoring.
  74. 74. Metrics.
  75. 75. Flexibility.
  76. 76. Decouple clients from endpoints.
  77. 77. End point per use case.
  78. 78. Rate limiting.
  79. 79. Rate limiting is easy right?
  80. 80. It is just X requests per second.
  81. 81. How do you actually enforce it?
  82. 82. Is it on the second boundary?
  83. 83. Straightforward on a single process.
  84. 84. But most apps are distributed these days so…
  85. 85. Token bucket algorithm.
  86. 86. Two parameters: replenish rate and burst capacity.
  87. 87. Tap is dripping “tokens” into the bucket.
  88. 88. This is you’re replenish rate.
  89. 89. Requests come and pull tokens out of the bucket.
  90. 90. If there are any!
  91. 91. If not?
  92. 92. 429 Too Many Requests. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
  93. 93. Burst capacity is the size of the bucket.
  94. 94. How many tokens will this bucket hold?
  95. 95. Could have more tokens than requests per second.
  96. 96. In other words, burst capacity is larger than the replenish rate.
  97. 97. Can have “rollover tokens!”
  98. 98. Good enough for Stripe. https://stripe.com/blog/rate-limiters
  99. 99. Spring Cloud Gateway brings Stripe’s approach to you.
  100. 100. More on that in a minute…
  101. 101. Load balancing.
  102. 102. What does a reactive load balancer look like exactly?
  103. 103. Many strategies are no better than 2 random choices.
  104. 104. The Power of 2. https://brooker.co.za/blog/2012/01/17/two-random.html
  105. 105. The Power of Two Choices in Randomized Load Balancing. https://www.eecs.harvard.edu/~michaelm/postscripts/tpds2001.pdf
  106. 106. Stale data leads to herd behavior.
  107. 107. Host A is quiet… keep sending it traffic.
  108. 108. But now A is overloaded.
  109. 109. The LB doesn’t know it yet.
  110. 110. Next time it updates the cache, A is overloaded…
  111. 111. So it goes quiet again.
  112. 112. Cycle back and forth. Quiet, busy, quiet, busy…
  113. 113. There is another way.
  114. 114. Pick two hosts.
  115. 115. Forward to the least busy one.
  116. 116. Has the best of both worlds.
  117. 117. Uses current data.
  118. 118. Doesn’t suffer from the herd behavior.
  119. 119. Throttling.
  120. 120. Request aggregation…
  121. 121. The list goes on!
  122. 122. Bit of a gray area here…
  123. 123. The line is fuzzy.
  124. 124. Don’t sneak any business logic into your gateway!
  125. 125. Often want to modify the request/response…
  126. 126. Don’t recreate the worst of the ESB era.
  127. 127. Options
  128. 128. As you can guess, there is a veritable plethora of options.
  129. 129. Appliances.
  130. 130. Can be hardware or virtual.
  131. 131. Act as a black box.
  132. 132. Low level.
  133. 133. F5, Apigee, CA API Gateway, etc.
  134. 134. SaaS solutions.
  135. 135. No management (for you).
  136. 136. Black box.
  137. 137. API driven.
  138. 138. Can be very pricey.
  139. 139. AWS Elastic Load Balancing, Apigee.
  140. 140. Work really well - when you are running on the same cloud!
  141. 141. But if you aren’t…
  142. 142. Web Server.
  143. 143. Typically open source.
  144. 144. Reliable, proven.
  145. 145. Apache mod_proxy, Nginx Kong, HA Proxy
  146. 146. Can be programmable (often via C or Lua).
  147. 147. Service Mesh.
  148. 148. https://mobile.twitter.com/ntschutta/status/1024735701349355521
  149. 149. Happy Birthday Istio. https://content.pivotal.io/blog/happy-birthday-istio-a-closer-look-at-how-pivotal-is- embedding-the-service-mesh-to-cloud-foundry-kubernetes-and-knative
  150. 150. Service meshes are kind of all the rage these days.
  151. 151. Distinction between east/west and north/south routing.
  152. 152. East/west === internal.
  153. 153. Think app to app or app to service. Container to container.
  154. 154. All within the family.
  155. 155. North/south also called ingress.
  156. 156. External traffic calling your services.
  157. 157. Aka from outside the family.
  158. 158. Meshes tend to be oriented towards operations and platforms.
  159. 159. Very much “ops”, not so much dev ops.
  160. 160. Istio, Envoy, LinkerD.
  161. 161. But no discussion would be complete without mentioning…
  162. 162. Zuul.
  163. 163. You know, the Gatekeeper of Gozer.
  164. 164. Came out of Netflix.
  165. 165. No one could have predicted this.
  166. 166. Zuul 1. https://www.youtube.com/watch?v=mHHHpxJuTAo
  167. 167. Servlet based.
  168. 168. Blocking API.
  169. 169. Servlet 2.5 I/O.
  170. 170. No long lived connections.
  171. 171. Clunky API, not overly developer friendly.
  172. 172. Can be tough to integrate.
  173. 173. Path based routing.
  174. 174. Number of proprietary features.
  175. 175. Early part of Spring Cloud.
  176. 176. Engineers at Netflix don’t just sit around drinking espresso.
  177. 177. Zuul 2.
  178. 178. Lessons learned from Zuul 1.
  179. 179. It is *not* backwards compatible.
  180. 180. Non blocking I/O.
  181. 181. Originally written on RxNetty.
  182. 182. Rewritten to Netty primitives.
  183. 183. Supports HTTP/2.
  184. 184. Proprietary features.
  185. 185. https://mobile.twitter.com/agonigberg/status/914895239042740225
  186. 186. Zuul 2 : The Netflix Journey… https://medium.com/netflix-techblog/zuul-2-the-netflix-journey- to-asynchronous-non-blocking-systems-45947377fb5c
  187. 187. Many, many options.
  188. 188. Often very heavy weight.
  189. 189. Tickets on top of tickets. With a side of tickets. And more tickets.
  190. 190. Embodies the negative connotation of “enterprise software”.
  191. 191. It doesn’t have to be this way…
  192. 192. SC Gateway
  193. 193. A Spring approach to the gateway problem!
  194. 194. Based on Spring 5, Reactor and Boot 2.
  195. 195. Non blocking IO.
  196. 196. Backpressure.
  197. 197. Event loop!
  198. 198. Spring WebFlux.
  199. 199. Lives along side Spring MVC.
  200. 200. Non-blocking, reactive.
  201. 201. Streams!
  202. 202. HandlerMapping - what code is going to handle this request.
  203. 203. WebFilter - manipulate the request/response.
  204. 204. Predicate - test some aspect of the request…
  205. 205. And determine whether to route it.
  206. 206. ServerWebExchange: access all parts of the http request/response.
  207. 207. Configure routes in Java, YAML or via repositories.
  208. 208. Can route on path, host, headers, parameters…
  209. 209. Anything in the request.
  210. 210. Filters!
  211. 211. Rewrite path.
  212. 212. Add or remove request/ response headers.
  213. 213. Rate limiting.
  214. 214. Hystrix.
  215. 215. With so many options, why should I use Spring Cloud Gateway?
  216. 216. It is programmer centric routing.
  217. 217. Antithesis of tickets with a side of tickets. And more tickets.
  218. 218. Would you rather refresh a configuration?
  219. 219. Or fill out another ticket?
  220. 220. Java centric, Spring centric.
  221. 221. You are in control.
  222. 222. Instead of one of these…
  223. 223. You can craft your own…
  224. 224. Except *you* decide what tools, blades etc. you want.
  225. 225. Lightweight, simple.
  226. 226. Use it as you will. You aren’t forced down a certain path.
  227. 227. Think of it as an ESB with inversion of control.
  228. 228. It is not a SaaS, it is a tool.
  229. 229. You can’t just “run” SC Gateway.
  230. 230. It is just an app.
  231. 231. Developer focussed.
  232. 232. You know how to build and run applications.
  233. 233. You build it, you push it.
  234. 234. It is in your hands, not some random enterprise group.
  235. 235. Anything you could do in Zuul 1 is supported in SC Gateway.
  236. 236. But what about performance?
  237. 237. There was a benchmark published in December 2017.
  238. 238. SC Gateway was not officially released at that time.
  239. 239. There are no performance issues today.
  240. 240. Many large companies rely on it.
  241. 241. Examples
  242. 242. Easy to add.
  243. 243. Use the starter: org.springframework.cloud
  244. 244. Artifact id: spring-cloud-starter-gateway
  245. 245. Route: basic building block of the gateway.
  246. 246. ID, a destination URI, a collection of predicates & a collection of filters.
  247. 247. If the aggregate predicate is true, the route is matched.
  248. 248. Predicate: a Java 8 Function Predicate. https://docs.oracle.com/javase/8/docs/api/java/util/function/Predicate.html
  249. 249. Allows you to match on anything from the HTTP request.
  250. 250. Filter: Instances Spring Framework GatewayFilter. https://cloud.spring.io/spring-cloud-gateway/single/ spring-cloud-gateway.html#_gatewayfilter_factories
  251. 251. Allows you to modify requests and responses.
  252. 252. After predicate.
  253. 253. Cookies!
  254. 254. Path Route Predicate.
  255. 255. Multiple Route Predicate Factories can be combined.
  256. 256. Logical and.
  257. 257. AddRequestParameter GatewayFilter.
  258. 258. Hystrix GatewayFilter Factory.
  259. 259. The Hystrix filter can also accept an optional fallbackUri parameter.
  260. 260. RedirectTo GatewayFilter.
  261. 261. RewritePath GatewayFilter.
  262. 262. Filters are distinct.
  263. 263. Single responsibility principal.
  264. 264. Add multiple filters to Route.
  265. 265. Global filters.
  266. 266. Spring Cloud LoadBalancerClient.
  267. 267. WebSocket, Netty, Gateway Metrics.
  268. 268. You can mix and match.
  269. 269. Make it as complicated as you’d like!
  270. 270. Fluent Java Routes API if you prefer programmatic approach.
  271. 271. Very powerful, very useful!
  272. 272. Microservices are a useful architectural pattern.
  273. 273. Like any design decision, there are consequences.
  274. 274. But you knew that ;)
  275. 275. Gateways are useful.
  276. 276. Doesn’t have to devolve into a blizzard of tickets!
  277. 277. Good luck!
  278. 278. September 24–27, 2018
 Washington DC
 Gaylord, National Harbor Discount Code
 S1P200_NSchutta Register Today & Save!
  279. 279. Nathaniel T. Schutta @ntschutta ntschutta.io Thanks! I’m a Software Architect, Now What? with Nate Shutta Modeling for Software Architects with Nate Shutta Presentation Patterns with Neal Ford & Nate Schutta

×