Who needs containers in a serverless world
0 likes266 views
The document discusses the interplay between serverless computing and containers, emphasizing their roles in modern development workflows. It outlines the characteristics of serverless architecture, the developers' workflow, and DevOps responsibilities, while highlighting the advantages of both approaches. Key insights include the economic benefits of serverless and the operational freedom provided by containers, leading to versatile architectural possibilities.
Who needs containers in a serverless world
- 1. Who needs containers in a serverless world? @RedHatNews & @InstanaHQ Vašek Pavlín & Matthias Lübken @vpavlin & @luebken
- 2. Agenda for 23 min ● Intro ● Focus on developers ● What is serverless ● A serverless example ● Containers? ○ Developers Workflow ○ Architectural Considerations ○ DevOps responsibilities ● Opinions See Slides: bit.ly/containers-serverless
- 5. What this talk is not about You need servers for serverless You need containers to run serverless
- 6. Open Source
- 9. Terms ● FaaS: Function-As-A-Service ● Event driven ● BaaS: Backend-As-A-Service
- 10. Are PaaS & CaaS serverless?
- 11. 5 common traits of serverless 1. Does not require managing a long-lived server or application instance 2. Self auto-scales and auto-provisions, based on load 3. Offers costs based on precise usage up from and down to zero usage 4. Has performance capabilities defined in terms other than host size / count 5. Has implicit high availability http://bit.ly/symph-defining-1 by @mikebroberts
- 13. A typical serverless architecture on AWS user client S3: static artefacts Cognito User Authentication API gateway S3: cache Lambda function Cloud Watch Logs / Metrics SNS Event Lambda function External APIs Route 53 DNS
- 14. Error response Triggered by an (HTTP) event Try to get data from cache Publish event for missing data Return JSON payload
- 15. And containers?
- 16. Containers are Versatile Containers Serverless
- 17. Serverless & Containers Developers’ workflow
- 19. Developers’ Workflow - Write Code ● Use IDE of choice ○ You can try VS Code with plugins (interesting links: debugging, another debugging, docker plugin)
- 20. Developers’ Workflow - Build ● Ideally “one click” solution Containers ● Dockerfile ● Source To Image ● Ansible Container ● Draft ● ... Serverless ● Zip:)
- 21. Developers’ Workflow - Run ● Locally or Remotely? Containers ● docker run … ● docker-compose up ● oc cluster up && oc new-app ... Serverless ● serverless invoke local ● serverless offline (for AWS) ● Azure local ● OpenWhisk on OpenShift
- 22. Developers’ Workflow - Test ● Unit? Integration? Acceptance? Local? Remote? Automated? Containers ● There are projects ● Unit testing is simple ● Integration testing can be done locally ● Acceptance testing should be done in production-like environment anyway Serverless ● Unit testing is important ● Integration & Acceptance testing over unit testing
- 23. Developers’ Workflow - Deploy ● Automate the hell out of it! Containers ● Build is the same as in dev or test ● You’ll need orchestration ○ Kubernetes ○ OpenShift ○ Mesos ○ Swarm ○ … ● There are CI integrations Serverless ● Serverless Framework ● Matthias uses Apex ● Now
- 25. The “serverless architectural style” ● Currently serverless is limiting: ○ Ephemeral application logic ○ Limited compute options ○ Short life span ○ State in backing services ○ Distribution by default ○ Cold vs Warm start ○ Latency between components ● Less is more. Limited options drive new architectures. ○ Makes you think in APIs ○ Buy vs build ○ ... Can your FaaSdo better?
- 26. Paper: Serverless computing: economic and architectural impact Gojko Adzic, Robert Chatley http://www.doc.ic.ac.uk/~rbc/papers/fse-serverless-17.pdf ● Removing economic incentives for bundling ● Removing components like gatekeeper due to request level authorization ● Removing Barriers to Versioning Implicit within the system
- 28. DevOps responsibilities change ● DevOps? What is your definition? ● Even with serverless, there are still many OPs topics to be taken care of around: Security, Performance, Tooling, CI/CD, (Distributed) Monitoring, ● But with serverless there is operability from the start ● DevOps promotes collaboration. Serverless mandates it. => Roles, responsibilities & teams evolve.
- 29. Managed vs Control ● You can host your own serverless platform but note serverless leverages economy of scale ● Most orgs will choose some cloud vendor and give up control So, how important is control to you? ● Ops is different with serverless
- 30. So ? Opinions
- 31. Matthias: “Serverless is the greatest enabler” ● No costs for not running code is just mind blowing ● Serverless made me think differently: ○ APIs ■ What other APIs are others providing? ■ What can I expose as an API? ○ Modular ■ Does my function do too much? ○ Event driven ■ What are good domain events? And it’s fun.
- 32. Vašek: “Containers give you freedom” ● Containers give freedom ○ Have you ever given freedom to developers? ;) ● You need to think on scale ● Orchestration is king ● It does not take traditional “ops” tasks away ● It was fun last 3 years, now it’s just work...
- 33. What if you could have both?
- 34. Apache OpenWhisk ● http://openwhisk.org/ ● GA : Feb 2016 from IBM ● Red Hat joined June 2017 ● License : ASL v2 ● Polyglot : NodeJS, Swift, Python, Java, PHP + Docker ● Event Sources : BlueMix services, Watson, Cloudant, other SaaS ● BlueMix Cloud Functions Pricing : $0.000017 GB-s ● Event Sequencing, Parameter Binding
- 35. ● serverless = faas & event driven & backend services ● pro container: ○ you can achieve similar characteristics with containers ○ containers & development are more versatile ○ they enable different architectures: monolith, µservices, faas ○ BTW containers are the enabling infrastructure ● pro serverless: ○ opinionated architecture ○ focus on writing application logic ○ precise cost based pricing powers new architectures ● OpenWhisk to the rescue tl;dr
- 36. Thanks for listening @vpavlin @luebken