Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Serverless Functions For Kubernetes With Fission
Similaire à Serverless Functions For Kubernetes With Fission (20)
Dernier
Dernier (20)
Serverless Functions For Kubernetes With Fission
- 1. Fission: Serverless Functions For Kubernetes Soam Vasani, Platform9 Systems
- 2. Serverless, adj.: Using someone else’s Kubernetes cluster. @ggreer on twitter https://twitter.com/ggreer/status/839171195920498688
- 3. Containers • Uniform • But also: heavy!
- 4. Resource Allocation • Rarely used services still need minimum resource alloc • Cluster capacity as function of deployment size vs. actual usage
- 5. What if? • What if we had the power of containers but very light dev workflows? • What if we could have cluster capacity as a proportion of actual service usage?
- 6. Functions as a Service • Short-lived stateless “functions” • Source / function / module level • Associated with an Event / HTTP / other trigger; activated on request only • Fast on-demand start (“cold start”)
- 7. Fission: FaaS on Kubernetes • Functions • Environments: “Generic” containers • Triggers
- 8. Fission: how it works • Pool of “generic” containers for each environment • Functions loaded on demand
- 9. Fission: how it works
- 10. Fission: how it works
- 11. Fission: how it works
- 12. Fission: how it works
- 13. Fission: how it works
- 14. Fission: how it works
- 15. Fission: how it works
- 16. Fission: how it works
- 17. Fission: how it works
- 18. Fission: how it works
- 19. Use cases • ~Small REST APIs • Web hooks • Kubernetes watch event handlers
- 20. Demos
- 21. Project Status • Open sourced Nov 2016 • Currently alpha; beta mid-late this year • Healthy community! • 1600 Github stars, 25 contributors, active Slack channel • Go, C#, PHP, Java support; Log aggregation/search, Web UI, many bug fixes
- 22. Roadmap • More powerful environments (packages, compile step) • Event queues • Better Kubernetes API & ecosystem integration • Observability: metrics, tracing, … • Kubernetes Volumes support • Secrets, Config maps • Unit testing • Debugging • Autoscaling
- 23. Thanks! Github: https://github.com/fission/fission Web: http://fission.io Slack: http://slack.fission.io Twitter: @fissionio @soamv
- 24. Roadmap — Environments v2 • Problems with single-file-loaded-at-runtime: • Multiple files, modules etc. • Compiled languages • Syntax errors in interpreted languages • Source and deployment packages; separate storage service • “Build” step — check syntax errors / gather deps / compile
- 25. Roadmap — API • Use ThirdPartyResources for state • Version-controllable specs • No extra DB to manage • Label-based route->function mappings (idiomatic Kubernetes) • Ingress • Hide TPRs and YAML files from users (as much as possible)
- 26. Roadmap — Ingress integration • Create ingress resources for HTTP triggers (optionally) • Allows fine-grained control over what routes are visible • Allows integrating with richer API gateways (e.g. traefik)
Notes de l'éditeur
- This definition makes sense! If you have someone managing a cluster and you can deploy anything you want, isn’t that serverless? What else do you want?
- Containers solved the problem of heterogenous packaging formats. No more worrying about virtualenv or ruby versions in production. But they also added a certain weight to our dev workflow: registries, docker builds, build versioning, CI integration etc. Today most of us build container images on every deploy. We manage container registries etc. Do we really need that, is that the only way to use containers? Can we have a lighter weight process but also have the benefits of containers?
- To have low resource usage, we must start functions on-demand. -> needs to be fast enough, otherwise you’d want them to be running at all times. These properties are the minimal set of things that makes a FaaS.
- 3 core nouns: Functions ; Environments - language-specific customizable containers; the only lang specific thing Triggers