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.

RedisConf18 - Common Redis Use Cases for Cloud Native Apps and Microservices

191 views

Published on

Breakout Session

Published in: Technology
  • Be the first to comment

  • Be the first to like this

RedisConf18 - Common Redis Use Cases for Cloud Native Apps and Microservices

  1. 1. Cloud Native 101 @ntschutta ntschutta.io Nathaniel Schutta
  2. 2. Ah “the cloud!”
  3. 3. So. Many. Options.
  4. 4. Microservices. Modular monoliths.
  5. 5. Container all the things?
  6. 6. What about serverless?
  7. 7. Functions. As a Service.
  8. 8. Is that cloud native?
  9. 9. How do we make sense of all this?!?
  10. 10. What is cloud Native?
  11. 11. Applications designed to take advantage of cloud computing.
  12. 12. Fundamentally about how we create and deploy applications.
  13. 13. Cloud computing gives us some very interesting abilities.
  14. 14. Scale up. Scale down. On demand.
  15. 15. Limitless compute.*
  16. 16. * Additional fees may apply.
  17. 17. Cloud native isn’t just an architectural pattern.
  18. 18. Combination of practices, techniques, technologies.
  19. 19. Agile development.
  20. 20. Continuous delivery.
  21. 21. Automation.
  22. 22. Containers.
  23. 23. Microservices.
  24. 24. Functions.
  25. 25. Changes our culture.
  26. 26. DevOps.
  27. 27. Infrastructure is a different game today isn’t it?
  28. 28. We’ve seen this massive shift.
  29. 29. Servers used to be home grown.
  30. 30. Bespoke. Artisanal.
  31. 31. Spent days hand crafting them.
  32. 32. Treated them like pets…
  33. 33. Did whatever it took to keep them healthy and happy.
  34. 34. Servers were a heavily constrained resource.
  35. 35. They were really expensive!
  36. 36. Had to get our money’s worth…
  37. 37. Thus was born app servers.
  38. 38. Put as many apps as possible on a server.
  39. 39. Maximize the return on investment.
  40. 40. But that has some unintended side effects.
  41. 41. Shared resources.
  42. 42. One application’s bug could take down multiple apps.
  43. 43. Coordinating changes hurts.
  44. 44. “Your app can’t get this feature until all other apps are ready.”
  45. 45. Currency === 18 months of freezes, testing, frustration.
  46. 46. Organizations ignored currency issues…pain wasn’t “worth it”.
  47. 47. –Yoda “Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.”
  48. 48. #YodaOps
  49. 49. Move code from one server to another…
  50. 50. Worked in dev…but not test.
  51. 51. Why?!?
  52. 52. The environments are the same…right?
  53. 53. “Patches were applied in a different order…”
  54. 54. Can I change careers?
  55. 55. Things started to change.
  56. 56. Servers became commodities.
  57. 57. Linux and Intel chips replaced custom OS on specialized silicon.
  58. 58. Prices dropped.
  59. 59. Servers were no longer the constraining factor.
  60. 60. People costs eclipsed hardware costs.
  61. 61. Heroku, AWS, Google App Egine, Cloud Foundry, Azure.
  62. 62. Redis is available on all of those BTW.
  63. 63. Shared servers became a liability.
  64. 64. Treat them like cattle…when they get sick, get a new one.
  65. 65. New abstractions.
  66. 66. Containers and PaaS changed the game.
  67. 67. Package the app up with everything it needs.
  68. 68. Move *that* to a different environment.
  69. 69. Works in dev? You’re testing the exact same thing in test.
  70. 70. So. Much. Win.
  71. 71. Your app needs a spiffy new library? Go ahead!
  72. 72. It doesn’t impact any other app because you are isolated.
  73. 73. Moves the value line.
  74. 74. Less “undifferentiated heavy lifting”.
  75. 75. https://mobile.twitter.com/onsijoe/status/598235841635360768?lang=en
  76. 76. Changes development.
  77. 77. Always be changing.
  78. 78. Run experiments. A/B testing.
  79. 79. Respond to business changes.
  80. 80. Deliver in days not months.
  81. 81. https://mobile.twitter.com/ntschutta/status/938109379995353088
  82. 82. Speed matters.
  83. 83. Disruption impacts every business.
  84. 84. Your industry is not immune.
  85. 85. Amazon Prime customers can order from Whole Foods.
  86. 86. Some insurance companies view Google as a competitor.
  87. 87. We’re all technology companies today.
  88. 88. 12 factors
  89. 89. Twelve Factor App. https://12factor.net
  90. 90. Characteristics shared by successful apps.
  91. 91. At least at Heroku.
  92. 92. 1. One codebase in version control, multiple deploys. 2. Explicitly define your dependencies. 3. Configuration must be separate from the code. 4. Backing services are just attached resources. 5. Build, release, run.
  93. 93. 6. Stateless - share nothing. 7. Export services via port binding. 8. Scale via process. 9. Start up fast, shut down gracefully. 10.Dev/Prod parity. 11.Logs as event streams. 12.Admin tasks run as one off processes.
  94. 94. Your legacy apps will violate some factors.
  95. 95. Maybe all 12!
  96. 96. In general…
  97. 97. II. Explicitly define your dependencies.
  98. 98. Probably one of the harder ones to satisfy.
  99. 99. Do we really need this library?
  100. 100. “It works, don’t touch it.”
  101. 101. III. Configuration must be separate from the code.
  102. 102. Many an app has hardcoded credentials.
  103. 103. Hardcoded database connections.
  104. 104. VI. Stateless - share nothing.
  105. 105. Also can be challenging.
  106. 106. Many apps were designed around a specific flow.
  107. 107. Page 2 left debris for Page 3!
  108. 108. “Just stash that in session”.
  109. 109. IX. Start up fast, shut down gracefully.
  110. 110. Many apps take way too long to start up…
  111. 111. Impacts health checks.
  112. 112. X. Dev/Prod parity.
  113. 113. Environments should be consistent!
  114. 114. Shorten code to prod cycle.
  115. 115. “It worked in test…”
  116. 116. Do your applications have to be fully 12 factor compliant?
  117. 117. Nope.
  118. 118. Is it a good goal?
  119. 119. Sure.
  120. 120. But be pragmatic.
  121. 121. Certain attributes lessen the advantages of cloud.
  122. 122. Long startup time hurts elastic scaling & self healing.
  123. 123. Think of it as a continuum.
  124. 124. 12 Factor Compliance Benefits of Cloud Deployment
  125. 125. Developers also talk about 15 factor apps.
  126. 126. aka Beyond the Twelve-Factor App. https://content.pivotal.io/blog/beyond-the-twelve-factor-app
  127. 127. However you define it…
  128. 128. To maximize what the cloud gives us…
  129. 129. Applications need to be designed properly.
  130. 130. Legacy applications will fall short.
  131. 131. Opportunistically refactor!
  132. 132. Building greenfield?
  133. 133. Go cloud native!
  134. 134. Don’t build legacy.
  135. 135. Microservices
  136. 136. Reaction to monoliths and heavy weight services.
  137. 137. As well as cloud environments.
  138. 138. Monoliths hurt.
  139. 139. Developer productivity takes a hit.
  140. 140. Hard to get your head wrapped around a huge code base.
  141. 141. Long ramp up times for new developers.
  142. 142. Small change results in building and deploying everything.
  143. 143. Scaling means scaling the entire application!
  144. 144. Not just the part that needs more capacity.
  145. 145. Hard to evolve.
  146. 146. We’re all familiar with the second law of thermodynamics…
  147. 147. Otherwise known as a teenagers bedroom.
  148. 148. The universe really wants to be disordered.
  149. 149. Software is not immune from these forces!
  150. 150. Modularity tends to break down over time.
  151. 151. Over time, takes longer to add new functionality.
  152. 152. Frustration has given birth to a “new” architectural style.
  153. 153. Enter the microservice.
  154. 154. No “one” definition.
  155. 155. In the eye of the beholder…
  156. 156. https://mobile.twitter.com/littleidea/status/500005289241108480
  157. 157. Anything that can be rewritten two weeks or less.
  158. 158. Think in terms of characteristics.
  159. 159. Suite of small, focussed services.
  160. 160. Do one thing, do it well.
  161. 161. Linux like - pipe simple things together to get complex results.
  162. 162. Independently deployable.
  163. 163. Independently scalable.
  164. 164. Evolve at different rates.
  165. 165. Freedom to choose the right tech for the job.
  166. 166. Built around business capabilities.
  167. 167. High cohesion, low coupling…
  168. 168. Applied to services.
  169. 169. It is just another approach. An architectural style. A pattern.
  170. 170. Despite what some developers may have said.
  171. 171. Use them wisely.
  172. 172. Please Microservice Responsibly. https://content.pivotal.io/blog/should-that-be-a- microservice-keep-these-six-factors-in-mind
  173. 173. –Simon Brown “If you can't build a monolith, what makes you think microservices are the answer?” http://www.codingthearchitecture.com/2014/07/06/ distributed_big_balls_of_mud.html
  174. 174. Sometimes the right answer is a modular monolith… https://www.youtube.com/watch?v=kbKxmEeuvc4
  175. 175. Redis & Microservices
  176. 176. Redis - Swiss Army Knife of Microservices Architecture.
  177. 177. It isn’t just for breakfast!
  178. 178. It is more than just a cache.
  179. 179. Application Server Authentication Site Pages Customer Profile Management Search and Discovery Product Catalog Session Store/ Shopping Cart Order Processing Fulfillment Analytics Product Catalog Manager Site Manager Order Fulfillment Application Business Intelligence Message Queue
  180. 180. • Session store • Cache server • Search engine • Time-series database • Analytics database • Message Broker
  181. 181. Top Use Cases.
  182. 182. • User Session Store • Cache • Translytics • API Rate Limiting • Message Broker/Queues • Blog Posts • Tags
  183. 183. • Instant Messaging / Chat • User On/Offline Status • Followers • Mutual Friends • User Comments • User Ratings • P2P Games • Leaderboards
  184. 184. Manage Session Stores with Redis Hash.
  185. 185. At one time, we could just use a database.
  186. 186. It was a simpler time.
  187. 187. Internet Server Database Traffic Grows… Struggles
  188. 188. Internet Server Database Store Session state on server!
  189. 189. Internet Server Database Ephemeral
  190. 190. Internet Server Database
  191. 191. Maintain session state across multiple servers.
  192. 192. Can you say hash?
  193. 193. HSET lets you save session variables as key/value pairs.
  194. 194. HGET to retrieve values.
  195. 195. Managing Queues with Redis Lists.
  196. 196. Lots of items to be worked on!
  197. 197. Asynchronous processing
 reduces block/wait times.
  198. 198. Hello lists!
  199. 199. LPUSH, RPUSH add values at beginning or end of queue.
  200. 200. RPOPLPUSH – pop from one queue and push it to another.
  201. 201. Managing Tags with Redis Sets.
  202. 202. So. Many. Tags.
  203. 203. How do we find items with a particular tag?
  204. 204. Sets are unique collections of strings.
  205. 205. SISMEMBER to check if an article has a given tag.
  206. 206. SMEMBERS to get all the tags for an article.
  207. 207. Also useful for recommending similar things.
  208. 208. Managing Leaderboards with Redis Sorted Sets.
  209. 209. But my enterprise app isn’t a game…
  210. 210. What is your top error message?
  211. 211. Error message leaderboard!
  212. 212. Did someone say sorted sets?
  213. 213. ZADD to add/update.
  214. 214. ZRANK will get any users rank instantaneously.
  215. 215. Unified Logs with Redis Streams.
  216. 216. How do we share state in distributed systems?
  217. 217. Needs to be durable.
  218. 218. Ordered data structure.
  219. 219. Acts like a master ledger.
  220. 220. Streams to the rescue!
  221. 221. XADD to append, XRANGE to read a set of records.
  222. 222. So much more than a cache!
  223. 223. Technology changes. Feature, not a bug.
  224. 224. We need to evolve along with it.
  225. 225. The more things change, the more they stay the same.
  226. 226. Apply the right technology to solve your problems!
  227. 227. Good luck!
  228. 228. 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

×