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, Functions, Serverless and You

60 views

Published on

SpringOne Platform 2018
Spring, Functions, Serverless and You - Nate Schutta, Pivotal

Published in: Software
  • Be the first to comment

  • Be the first to like this

Spring, Functions, Serverless and You

  1. 1. Nathaniel T. Schutta @ntschutta ntschutta.io Spring, Functions, Serverless and You
  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.
  8. 8. As a Service.
  9. 9. I hear that is *the* in thing now.
  10. 10. But we just refactored to cloud native microservices…
  11. 11. 😡
  12. 12. (╯°□°)╯︵ ┻━┻
  13. 13. Don’t throw that code away just yet!
  14. 14. We can leverage a lot of that hard earned knowledge.
  15. 15. Key - knowing when to use each tool.
  16. 16. Why serverless?
  17. 17. First things first. There are still servers.
  18. 18. We are just (further) abstracted away from them.
  19. 19. We don’t have to spend time provisioning, updating, scaling…
  20. 20. In other words it is someone else’s problem.
  21. 21. https://mobile.twitter.com/samnewman/status/952610105169793025
  22. 22. https://mobile.twitter.com/starbuxman/status/959366771462496256
  23. 23. IaaS Containers Container Container Scheduling Primitives for Networking, Routing, Logs and Metrics Platform Application Container Images L7 Network Logs, Metrics, Monitoring Services Marketplace Team, Quotas & Usage Container Serverless Function Function Execution Function Scaling Event Stream Bindings Container Developer Provided Tool Provided
  24. 24. Different levels of abstraction.
  25. 25. Hardware IaaS Containers Platforms Serverless More Flexibility Fewer Standards Lower Complexity Operational Efficiency Push as many workloads up the stack as feasible.
  26. 26. Some argue it is the new PaaS. http://redmonk.com/sogrady/2018/01/26/serverless-is-the-new-paas/
  27. 27. Veritable plethora of options.
  28. 28. AWS Lambda, Azure Functions, Google Cloud Functions…
  29. 29. riff, OpenWhisk, Kubeless, Fission…
  30. 30. Definitely suffers from the shiny new thing curse.
  31. 31. And everything that entails.
  32. 32. Fair to say FaaS is a subset of serverless.
  33. 33. Though many use the terms interchangeably.
  34. 34. There *are* very good reasons to utilize this approach!
  35. 35. Some relate specifically to a platform.
  36. 36. Perhaps you already have data with a provider.
  37. 37. Using Amazon S3 for example.
  38. 38. You might want to tap into particular services offered by a provider.
  39. 39. Perhaps you want to utilize Google Cloud Machine Learning Engine.
  40. 40. But it isn’t just a new a way to cloud.
  41. 41. There are serious efficiency gains to be had with this approach!
  42. 42. Development efficiencies.
  43. 43. Functions push us further up the abstraction curve.
  44. 44. Allows us to focus on implementation not infrastructure.
  45. 45. Do you know what OS your application is running on?
  46. 46. Do you care?
  47. 47. What *should* you care about?
  48. 48. Where is the “value line” for you?
  49. 49. We want to get out of the business of “undifferentiated heavy lifting”.
  50. 50. Focus on business problems, not plumbing problems.
  51. 51. Resource efficiencies.
  52. 52. Function hasn’t been called recently?
  53. 53. Terminate the container.
  54. 54. Request comes in? Instance springs into existence.
  55. 55. Functions aren’t free however.
  56. 56. Well, ok, once you get beyond the free tier at least…
  57. 57. Then some fractional cost there after.
  58. 58. First million (or two) requests are free*.
  59. 59. * Additional fees may apply.
  60. 60. For example: data transfer fees or other services you leverage.
  61. 61. Charged based on number of requests, run duration and resource allocation.
  62. 62. Can be challenging to determine just how much it will cost…
  63. 63. But for certain workloads, it is very cost effective.
  64. 64. Operational efficiencies.
  65. 65. Serverless ops?
  66. 66. Again, less for us to worry about.
  67. 67. Rely on a platform.
  68. 68. What use cases fit well with functions?
  69. 69. Rapidly evolving business requirements…
  70. 70. Stateless workloads.
  71. 71. Infrequent (or sporadic) requests.
  72. 72. Variable scaling needs.
  73. 73. Asynchronous workloads.
  74. 74. Easy to parallelize.
  75. 75. IoT, machine learning, log ingestion, batch processing, stream processing.
  76. 76. “Conversational UIs” aka digital assistants like Alexa.
  77. 77. CI/CD automation, chat integration.
  78. 78. Website back end services such as logging, post handlers, authentication.
  79. 79. Event processing, monitoring, notifications, alerting, security scanning.
  80. 80. Very valuable tool.
  81. 81. It isn’t a good fit for every workload.
  82. 82. But you knew that.
  83. 83. Spring Cloud Functions.
  84. 84. A Spring take on functions!
  85. 85. Abstract away the runtime target.
  86. 86. Same code can be an endpoint, a task, a stream processor…
  87. 87. Provide a unified programming model across serverless providers.
  88. 88. Multicloud for the win!
  89. 89. As well as running locally or on your PaaS of choice.
  90. 90. Gives you choice.
  91. 91. You can make the strategic/tactical decision that is right for your situation.
  92. 92. Bring the Spring Boot features you know and love to serverless!
  93. 93. Focus on writing the business logic.
  94. 94. Utilizes core abstractions from java.util.function.
  95. 95. Function, Consumer, Supplier.
  96. 96. Can optionally use Reactor’s Flux as parameters and return types.
  97. 97. Meaning you can use reactive approaches like non-blocking IO.
  98. 98. Supports compiling String based lambdas into function instances.
  99. 99. If this is just based on standard Java classes, why should I use it?
  100. 100. Inversion of control.
  101. 101. Allows you to decouple the code from the deployment profile.
  102. 102. Just add the right dependency.
  103. 103. Do you want to deploy your function as a REST endpoint?
  104. 104. spring-cloud-function-web
  105. 105. Need that function to be a stream processor instead?
  106. 106. spring-cloud-function-stream
  107. 107. Goal - remove the boilerplate.
  108. 108. Developers focus on the function. Let the framework handle the rest.
  109. 109. Implement (and test) the code apart from the target environment.
  110. 110. riff fundamentals.
  111. 111. riff is for functions. https://projectriff.io
  112. 112. FaaS for Kubernetes.
  113. 113. Executing functions in response to events.
  114. 114. Developers focus on two things:
  115. 115. The function itself.
  116. 116. And the topic that triggers the function.
  117. 117. Event stream might be low frequency, might be continuous.
  118. 118. Or unpredictable.
  119. 119. Built on the experience of Spring Cloud Streams and Data Flow.
  120. 120. Functions can be polyglot.
  121. 121. Java, JavaScript, shell, Go and Python.
  122. 122. Just a container running on K8s.
  123. 123. Scale up and down as needed.
  124. 124. riff function controller monitors event broker for lag.
  125. 125. Once it sees a certain amount of lag, will scale up.
  126. 126. By default, single instance scales down to zero after 10 seconds idle time.
  127. 127. Yes, it is configurable.
  128. 128. ICE - CAP for serverless.
  129. 129. Immediate. Consistent. Efficient.
  130. 130. Pick two.
  131. 131. What are your concerns? Resource utilization? Immutable containers?
  132. 132. Set of comprises.
  133. 133. If we keep containers running, we’re paying for idle resources.
  134. 134. If we inject code into a container, we lose immutability.
  135. 135. If we launch containers on demand, we have slow startup experience.
  136. 136. Many platforms use dynamic loading.
  137. 137. But the goal with riff is to give *you* control over the tradeoffs.
  138. 138. Functions are packaged as containers.
  139. 139. Functions and topics are just K8s resources.
  140. 140. In other words, managed via kubectl just like a pod.
  141. 141. riff is thin.
  142. 142. Relies on Kubernetes Custom Resource Definition extension.
  143. 143. riff function controller monitors event lag, scales as necessary.
  144. 144. Event broker is Kafka, pluggable event brokers are on the roadmap.
  145. 145. riff init - initialize a funtion.
  146. 146. riff build - creates the Docker image.
  147. 147. riff apply - deploy the function on Kubernetes.
  148. 148. Or riff create to init/build/apply.
  149. 149. Invokers are now installable resources.
  150. 150. Install the ones you need.
  151. 151. Generate the Dockerfile and yaml by specifying the invoker.
  152. 152. riff create node riff init java
  153. 153. Just an instance of inversion of control. Don’t call us, we’ll call you.
  154. 154. Sidecar contains the binding to the event broker. Aka proxy pattern.
  155. 155. Multiple implementation of the function containers…
  156. 156. But only one implementation of the sidecar.
  157. 157. Can communicate to the function invoker over HTTP, stdio, gRPC…
  158. 158. Event Broker Function Pod Function ContainerSidecar Container invoker function dispatcher binder broker API HTTP gRPC stdio
  159. 159. Functional YAML • name • input/output topics • artifact/params Topic YAML • name • params Topic YAML • name • params HTTP Gateway Function Controller Topic Controller Pod Sidecar Container Function Container Pod Sidecar Container Function Container Pod Sidecar Container Function Container Kafka Functional YAML • name • input/output topics • artifact/params Functional YAML • name • input/output topics • artifact/params Topic YAML • name • params
  160. 160. Very new, evolving rapidly.
  161. 161. Agnostic layer for FaaS. Run it on premise or public cloud.
  162. 162. riff under the hood.
  163. 163. Kubernetes. https://kubernetes.io
  164. 164. K8s - deploy, scale & manage containers.
  165. 165. Built from lessons learned at Google.
  166. 166. They have experience.
  167. 167. Has many of the features you would expect.
  168. 168. Self-healing. Scaling. Service discovery. Load balancing.
  169. 169. Automated rollouts and rollbacks.
  170. 170. kubectl
  171. 171. kube control, kube CTL, kube cuddle, kube cuttle….
  172. 172. K8s command line interface.
  173. 173. You describe your desired state, Kubernetes makes it so.
  174. 174. (insert your favorite Captain Picard reference here).
  175. 175. Number of abstractions: pod, service, volume, namespace…
  176. 176. Pod houses one (or more) containers.
  177. 177. Also storage, unique IPs.
  178. 178. Pod is fundamental unit of deployment.
  179. 179. An instance of an application.
  180. 180. Typically Docker containers but K8s supports others.
  181. 181. One container per pod is common, but some containers are tightly coupled.
  182. 182. Pods can contain multiple containers that then share resources.
  183. 183. “Helper” containers are often referred to as sidecars.
  184. 184. Docker. https://www.docker.com
  185. 185. Docker is, well a box.
  186. 186. Put whatever you want in it.
  187. 187. Includes everything needed to run.
  188. 188. Your code, system libraries, executables, settings, etc.
  189. 189. Your code is isolated from the environment.
  190. 190. How often does your staging app server actually match production?
  191. 191. Instead of copying the code from one environment to another…
  192. 192. Just define the entire environment.
  193. 193. Similar to virtual machines.
  194. 194. Containers virtualize at the OS level, not the hardware level.
  195. 195. You have to tell Docker what you need.
  196. 196. Create a Docker image which is often stored in a registry like Docker Hub.
  197. 197. An image is a template or recipe for building a container.
  198. 198. Images often customize existing images.
  199. 199. Parent image acts as a starting point for further customization.
  200. 200. But again, *you* are responsible for what goes in the box!
  201. 201. — Uncle Ben “With great power comes great responsibility.”
  202. 202. Don’t forget to stay current…
  203. 203. https://xkcd.com/1938/ Randall Munroe
  204. 204. Kafka. https://kafka.apache.org
  205. 205. “Distributed streaming platform.”
  206. 206. Message queue. Publish and subscribe.
  207. 207. Real time stream processing.
  208. 208. Records are published to a topic.
  209. 209. Records consist of a key, value and a timestamp.
  210. 210. Kafka clusters maintain a partitioned log of the topics.
  211. 211. These are ordered and immutable.
  212. 212. Records assigned an offset - unique identifier used by consumers.
  213. 213. Every record is retained based on the configured retention setting.
  214. 214. Consumers can come and go.
  215. 215. Consume the records in whatever order they wish using the offset.
  216. 216. Can go back to older offsets to reprocess or skip ahead…
  217. 217. In a nutshell, Kafka is the best of publish-subscribe and queues.
  218. 218. Multi-subscriber with the ability to split processing over multiple consumers.
  219. 219. riff in action!
  220. 220. Write a function, a Dockerfile and configure riff with some YAML.
  221. 221. Hello World anyone?
  222. 222. Configure the container.
  223. 223. Get the riff node function invoker image from Docker Hub.
  224. 224. Set an environment variable - the node invoker looks there for your code.
  225. 225. Copy your function to the image…
  226. 226. At the directory named in the environment variable.
  227. 227. Configure our function and our topic.
  228. 228. Build the function.
  229. 229. Creates our function image as described in our Dockerfile.
  230. 230. Essentially a wrapper around Docker cli.
  231. 231. Runs docker build and (optionally) docker push.
  232. 232. “Apply” our configuration.
  233. 233. Make it so K8s.
  234. 234. Essentially a wrapper around kubectl.
  235. 235. Calls kubectl apply.
  236. 236. Now we can call our function!
  237. 237. Rinse, repeat!
  238. 238. Which approach should *you* choose?
  239. 239. https://twitter.com/KentBeck/status/596007846887628801
  240. 240. There is no one right answer here.
  241. 241. && ! ||
  242. 242. Not all workloads fit in each bucket.
  243. 243. There are tradeoffs!
  244. 244. But you knew that.
  245. 245. — Uncle Ben “With great power comes great responsibility.”
  246. 246. Development complexity.
  247. 247. Do you want developers thinking about OS patches?
  248. 248. Or just pushing apps?
  249. 249. Operational efficiency.
  250. 250. How many operators does it take to manage a bespoke environment?
  251. 251. Flexibility vs. standardization.
  252. 252. Guardrails aren’t shackles.
  253. 253. They are designed to protect you.
  254. 254. How do you want to allocate *your* resources?
  255. 255. Choose the option that fits the problem.
  256. 256. Push as many workloads as you can up the abstraction hierarchy.
  257. 257. Evolving space.
  258. 258. Life Functions move pretty fast…
  259. 259. riff is *really* new.
  260. 260. Want more?
  261. 261. Riffing on Project riff. https://soundcloud.com/pivotal-insights/riffing-on-project-riff-ep-56
  262. 262. Serverless Spring. https://www.youtube.com/watch? v=mPOl3024R4s&index=73&list=PLAdzTan_eSPQ2uPeB0bByiIUMLVAhrPHL
  263. 263. riff is for functions. https://www.youtube.com/watch? v=mlRSp9Z3zwY&list=PLAdzTan_eSPQ2uPeB0bByiIUMLVAhrPHL&index=14
  264. 264. Good luck!
  265. 265. Questions?
  266. 266. 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

×