Democratizing Serverless: the New Open Source, Cloud Agnostic Functions Platform - Matthew Gilliard - Codemotion Amsterdam 2018
Download as PPTX, PDF0 likes230 views
The document outlines the general direction of the open-source serverless compute platform, Team FN, emphasizing the benefits of serverless architecture for developers, managers, and function-as-a-service operators. It details how to use the platform, including the deployment process and development aids like function development kits, while also discussing the potential for future enhancements and community involvement. The content serves primarily as an informative overview and is not legally binding.
Democratizing Serverless: the New Open Source, Cloud Agnostic Functions Platform - Matthew Gilliard - Codemotion Amsterdam 2018
- 1. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. All rights reserved. Timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle
- 2. Democratizing Serverless Open-Source is for everyone! Matthew Gilliard @MaximumGilliard
- 3. Team
- 4. Fn is an Open-Source Serverless Compute Platform
- 5. What even is an Open-Source Serverless Compute Platform
- 7. Why Serverless? Answers for developers: ● Easier: Just code, not infrastructure ● Powerful: Transparent and limitless* scaling ● Faster: Code, Test, Deploy, Iterate ● Cheaper: Try stuff out for microdollars * limits may apply
- 8. Why Serverless? Answers for managers: ● Cost Reduction: Pay according to demand. Reduce op-ex. ● Agility: Dev teams get faster with less fewer dependencies ● Reliability: is a platform responsibility ● Innovation: easy and cheap to try things out
- 9. ● Higher density: That hardware was *expensive* ● Security: User has fewer responsibilities ● Economy of Scale: We centralise a lot of things ● Marketplace: users actually want it! Why Serverless? Answers for FaaS operators (i.e. ):
- 10. -flavoured FaaS ● Deploy to any cloud, or on-premise, or... ● Containers are primitives ● Independent yet vendor backed (by us) ● Strong enterprise focus
- 11. Containers vs Functions Function is a container with a set of known traits: ● Short running ● Ephemeral / event-driven ● Stateless
- 12. How does one use Fn?
- 14. Anatomy of an Fn Function ● Some code wrapped into a container image ● Gets input via STDIN and environment ● Produces output to STDOUT ● Logs to STDERR
- 15. Input format Currently looks like this:
- 16. Input format JUST ANNOUNCED HOT NEWS EVERYONE:
- 17. Fn CLI ● fn init --runtime go ● fn run ● fn deploy --app myapp ● fn call myapp myfunc or: curl -v ${FN_API_URL}/r/myapp/myfunc
- 18. fn deploy 1. Builds container (multi-stage) + bumps version 2. Pushes container to registry 3. Creates/updates function route (servers lazy load images) MyFunc:0.0.2 MyFunc:0.0.2 MyFunc:0.0.2 Your code Fn Service myfunc → /r/myapp/myfunc:0.0.2 1 2 3
- 19. Function Development Kits (FDKs) ● Used to help with parsing input and writing output ● Familiar syntax for Lambda developers ● Simply write a `handler` function that adheres to the FDK’s interface and it will parse STDIN and provide the input data to your function and deal with writing the proper output format. ● Makes it a lot easier to write hot functions
- 20. Small images are better. Read up on “multistage builds” if you don’t already know about that. Support for languages So long as you have: ● a func.yaml ● a Dockerfile you’re good to go.
- 21. Request Flow
- 23. Kubernetes ● Fn is does not *require* K8S, but lots of optimization work optimiz for it ● Helm chart available at https://github.com/fnproject/fn-helm ● Investigating deeper Kubernetes integrations including CRD’s to model functions
- 24. Why not K8S ALL THE THINGS!? 1. Speed a. Pod launch time is too slow/unpredictable for synchronous requests b. STDIO is not easily accessible from container in a k8s pod 2. Scale a. Runs out of addressable network space quickly b. Functions easily scale to the hundreds of thousands / millions
- 25. What’s next for Fn? 1. Hosted Fn-as-a-Service 2. More contributors (could it be you?) 3. More collaboration and standardization
- 26. Thank you! 1. Star the project: github.com/fnproject/fn 2. Join the conversation: slack.fnproject.io 3. Learn more: fnproject.io I’ve been Matthew Gilliard Get Involved!
Editor's Notes
- #4: Who are the Fn team? 30-ish ppl Most are <2 years at Oracle. Several from Iron Functions, whose codebase we forked. Fn gets around 10x effort compared to Iron Mostly Oak/Bris but some remote (the long green thing isn’t on the team)
- #6: Open-Source: Yeah, github etc. Apache 2 license. Fight the vendor lock-in. Serverless: As in, you don’t get to care about the servers. Is DBaaS “serverless”? i.e. is “serverless” particularly novel? Maybe compare with “wireless” (which uses a LOT of wires). Or mention “Jeff” conf Compute platform: Runs user-submitted code in a safe sandboxed environment, on demand This makes us a “FaaS” -
- #7: Functions are small Single-purpose Independent easy to understand and maintain As a service means no plumbing service takes care of provisioning, scaling, patching, maintaining, etc. Each function scales independently.
- #8: *limitless: Well, up to a point. You can set limits because a DOS attack would otherwise be a denial of wallet
- #9: Dependencies here in the Conway’s Law sense. Organi{s,z}ational dependencies
- #10: Density. Succinctly - all the things we need to do to get higher density are under *our* control Security: More charitably, *we* can take some actions which the users can’t, and we are *highly* incentivised to do them quickly. All these things conspire to MAKE MONEY which is what Oracle’s ultimately about after all. The technical challenges are interesting too, though.
- #11: KubeCon demo is showing Fn on GKE, AWS Enterprise focus = (security, scalability, observability, etc.) It’s rather easy to make a FaaS, really, but to make a *good* one is harder Have to walk a line between vendor-agnostic and “works reaaaallllly well on OCI”
- #12: How are “Function” containers different from “regular” containers? Ie jetty-in-a-container or whatever...
- #13: Demo is: Install cli tool Watch docker ps Fn start In a new directory: fn init --runtime=java See what files are generated Fn run Echo -n “yeah” | fn run Fn deploy --app foo --local Curl -v Check fn-lb-wait-header Curl again Check fn-lb-wait-header explain about hot functions
- #14: Demo is: Install cli tool Watch docker ps Fn start In a new directory: fn init --runtime=java See what files are generated Fn run Echo -n “yeah” | fn run Fn deploy --app foo --local Curl -v Check fn-lb-wait-header Curl again Check fn-lb-wait-header explain about hot functions
- #15: “Some code” could be anything that is containerizable. Environment dependency is a PITA and we’re moving away from it STDOUT/ERR easy to write to
- #16: “Some code” could be anything that is containerizable. Environment dependency is a PITA and we’re moving away from it STDOUT/ERR easy to write to
- #17: Cloud events is going to be the main event format in the future. Possibly the only one. Common question: How to do streaming data in a JSON object? Well, you can’t but one good way is to pass a URL which the function can retrieve the data from. We may support other streaming formats.
- #18: Don’t use --local in the hackathon….
- #19: Lazy or maybe not so lazy
- #20: These are our supported languages. Exact functionality depends on the style and conventions of the language, eg node is v. simple, Java does type coercion by reflection, etc
- #21: Small images rule, of course, so look into Multi-stage docker builds
- #22: Based on available memory. Everything else is scaled proportional to memory so there is only one degree of freedom for sizing your function.
- #23: “Let me introduce you to my 7-sided friend”
- #24: So, at the moment we don’t let k8s manage the function containers But all the control-plane stuff can be installed using the Helm chart
- #25: That said, these are technical problems not philosophical. As k8s gets more adoption and becomes (a) better (b) more pluggable we will revisit.