Exploiting Serverless - DevOps Conference Sydney 2018
•Descargar como PPTX, PDF•
2 recomendaciones•227 vistas
As an enterprise the thing you should care about is not the hype about serverless, it is the billing model shift it brings. If you are starting out on your DevOps journey in the enterprise, look to skip the complexity and costs of Containerisation and go straight to Serverless. This is a talk I presented at the DevOps sydney conference in 2018. It focuses on the cost benefits of serverless and why your organisation should care.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Similar a Exploiting Serverless - DevOps Conference Sydney 2018
Similar a Exploiting Serverless - DevOps Conference Sydney 2018 (20)
Más de Nigel Fernandes
Más de Nigel Fernandes (18)
Último
Último (20)
Exploiting Serverless - DevOps Conference Sydney 2018
- 1. Exploiting Serverless Or why DevOps has moved on.
- 2. About me The views and opinions expressed in this presentation are my personal ones, and do not represent my employer. Nigel Fernandes Head of Strategy & Architecture
- 3. Mental model check Increasing level of expertise
- 4. DevOps Increasing level of expertise
- 5. Serverless Increasing level of expertise
- 6. “At its essence, DevOps is a culture, a movement, a philosophy.”
- 7. Structure Introduction Serverless in the Enterprise Serverless Economics Serverless meets DevOps Wrap up
- 9. Yet Another Definition: Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. Wikipedia
- 10. Serverless Offering (circa 2017)
- 11. Needs an ecosystem to be practical & useful.
- 15. Exploiting the serverless design model Serverless computing: economic and architectural impact Adzic et al., ESEC/FSE’17
- 17. But what about <insert hated system>
- 18. An Evented approach Dumb Pipes, Smart Endpoints Events not Commands Events named in the past tense Create copies of the data you need
- 19. ThoughtWorks Technology Radar - 2011 Choreography over Orchestration
- 20. You can do public APIs. Here be Dragons. Cold Starts bite hard in public APIs Caching is non deterministic (at least on AWS) Timeout design needs special attention Slow client networks can affect pricing API Gateways add cost and complexity. Watch out for payload limits.
- 21. Normal Timeout Design From: Yan Cui https://theburningmonk.com/2018/01/aws- lambda-use-the-invocation-context-to-better- handle-slow-http-responses/
- 22. Better Timeout Design From: Yan Cui https://theburningmonk.com/2018/01/aws- lambda-use-the-invocation-context-to-better- handle-slow-http-responses/
- 23. But we have containers... A PaaS that auto-scales to zero and has a pay-per-request pricing model can be considered Serverless. Azure AKS with ACI Google Kubernetes Engine
- 24. Better than VMs, not as good as FaaS Economics Scaling Patching Availability & fault tolerance Concurrency & Contention Serverless Functions Pay per request/ Invocation in ms Scale by events Code level Built In Minimal contention Managed Container Services Pay per provision and per second Scale by policy Patch at the container OS + Code Has to be designed Contention at the process/thread level
- 25. Simon Wardley (@swardley) speaking to Forrest Brazeal “Containers are a smaller educational jump; plus, they offer things like portability that people, particularly vendors, really want to talk about. It gives them a counter-story that somewhat ignores the whole platform shift to code execution environments. Containers don’t force you to re-architect, or discover that most of your code has already been written by other people.”
- 26. Point #1 Get moving towards PaaS and FaaS
- 30. Which combined with a “pay per request” model for serverless, allows for incredibly accurate provisioned capacity. I.e. Provisioned capacity almost exactly matches demand. Images via CloudFlare.
- 31. Where costs come from: Things to consider: ● Double the time & memory: Costs increase 4 times. ● Processing delays can be expensive. 200ms with 2sec of latency increases cost 11 times. ● Spot pricing (capacity) or Spark on EMR (concurrency) might be more cost effective. ● Leverage the free tiers ● Configuration growth with scale.
- 32. Understanding Hidden Costs - 2 OS level patching, monitoring and management. Technology complexity of CI/CD in building fault tolerant, concurrent with isolation systems. Organisational complexity of IaaS in the enterprise.
- 34. Cost of the idle system is zero Serverless computing: economic and architectural impact Adzic et al., ESEC/FSE’17 The use of event driven architectures can move the cadence of your IT systems closer to your business cadence. This architecture has the side effect of driving up the idle time in the overall production system, which lowers the overall cost.
- 35. Remember the Non-Prod Environments Cost: $ + $ + $ + $$ + $$ + $$ > $$$ Idle Time: High Low
- 36. Point #2 Exploit the serverless billing model
- 38. Ops and Infra aware design Architecture / Technical Design leadership is evolving into a vertical discipline. Infrastructure is a strategic consideration. NoOps is a lie. Ops is now diffused across the team. Biz-Strat-Arch-Dev-Sec-Data-Ops is a thing?
- 39. CI/CD is changing. Rethink software delivery programmes Machine Images versus Template + Code Zip Rethink the pipeline for speed over insurance. Reconsider Blue/Green and Immutable Infrastructure
- 40. New tooling needed. Managing fragmentation. Debugging distributed workflows. Authentication must be levelled up Careful design of API gateways within the enterprise Monitoring is on different dimensions Security needs to be reconsidered for the flat tiers. Serverless computing: economic and architectural impact Adzic et al., ESEC/FSE’17
- 41. “The collaboration between dev & ops is now extended to external 3rd parties” Patrick Debois http://www.jedi.be/blog/
- 42. Point #3 Serverless is changing DevOps
- 43. Point #3 Serverless is changing DevOps Point #2 Exploit the serverless billing model Point #1 Get moving towards PaaS and FaaS Recap
- 44. A final thought.
- 45. A joke that’s too close for comfort Created by Simon Wardley (@swardley)
- 46. Reed Hastings is on a Charlie Rose interview, and Charlie says, “Reed, what do the people in Palo Alto know that everyone else doesn’t know?” And he said, “Moore’s Law.” And Charlie goes, “Well, I know what Moore’s law is.” And he goes, “Yeah, but Charlie, you don’t understand. We’re designing for the next iteration now.” Jim Hackett Talking to Stephen Dubner in the Freakonomics Podcast
- 47. We’re designing for the next iteration now.
Notas del editor
- Audience participation activity. Gauge the level of understanding and experience in the room.
- https://www.atlassian.com/devops
- Lambdas, Functiosn and GCPs thing Business value - billing model - cost of the idle system Drive production with business cadence Unleash the savings in non prod Patterns Enrichment pipelines Evented Architectures APIs - latency, cold starts and always on. Coming back to DevOps Designing with Infra and Operations together Micro fragmentation of business logic
- Perhaps the most obvious thing about the PaaS+Serverless approach is the division of the system logic into a collection of independent functions/operations. Since billing is proportional to actual usage, there is no penalty for creating many small units. Contrast this with server-based designs, where you pay per (long-running) instance. In such a world it is hard to justify having a dedicated service instance for infrequent but important tasks (let alone two if you have a primary and fail-over). You have a strong economic incentive to bundle responsibility for many tasks into the same instance. For this architecture, the billing is proportional to usage, not reserved capacity. This removes the economic benefit of creating a single service package so different tasks can share the same reserved capacity. The platform itself provides security, fail-over and load-balancing, so all benefits of bundling are obsolete. Without strong economic and operational incentives for bundling, serverless PaaS open up an opportunity for application developers to create smaller, better isolated modules, that can more easily be maintained and replaced. In other words, with a serverless approach we have a platform and billing model which actually works with the desire to split a system up into independently delivered units, rather than fighting against that trend at some level. And of course, we get all the benefits of fault isolation and independent scaling that we hoped for in the first place before resorting to bundling.
- Image license : http://turnoff.us/geek/enterprise-vs-startup-journey-to-cloud/
- The smell to watch out for is the copy of the data is the whole data set
- Image license https://pixabay.com/en/dragon-metallizer-art-glass-1791614/ RequestEntityTooLargeException - * byte payload is too large for the Event invocation type (limit 131072 bytes) Eni attachment issues and time delays
- https://theburningmonk.com/2018/01/aws-lambda-use-the-invocation-context-to-better-handle-slow-http-responses/
- https://www.cloudflare.com/learning/serverless/what-is-serverless/
- Suppose that a Lambda function uses 512 MB of memory and executes in slightly less than 200 milliseconds. After a code change, the function now needs 400 milliseconds to run (double), and 1024 MB of memory (double). The total compute cost increases 4 times. If the memory requirement is instead tripled to 1536 MB, the total cost increases 6 times. If both the memory requirement and execution time are tripled, the total cost increases 9 times Suppose that a 512 MB Lambda function executes in slightly less than 200 milliseconds, with a hard limit of 5 seconds. As part of its processing, the function calls an external service over HTTPS and waits for a response before ending. Suppose that network congestion or an external service degradation adds a spike of 2 seconds to each network call. For the duration of the latency spike, the extra 2 seconds of Lambda running time will increase cost 11 times,
- I.e when your business picks up, more change is pushed into the system, and more work is performed.
- Unleash the savings in non prod
- Image license : http://turnoff.us/geek/monolith-retirement/
- http://freakonomics.com/podcast/ford/