Serverless Computing: Promises & Pitfalls Jonathan Schellack @schellack / sal.us Serverless Computing: Promises & Pitfalls

Why are we here? Technology is the means, not the end Business Problems > Buzzwords How many of you are paid to play with technology? As much as we might like to pretend otherwise, we aren’t paid to play with technology. We are paid to solve problems. Thankfully we get to do that with technology. The point of all this isn’t to define buzzwords. It’s to help us all focus on why we are here, which is to SOLVE BUSINESS PROBLEMS. A great thing about this “serverless trend” is that it allows us to focus more on solving business problems. Today I’m going to show you more of how that works.

Defining a negative Missing servers Focus on what’s missing Do only what you must Disown everything else Serverless computing is probably a poor term to define what we actually are describing, because it’s a negative term. It defines what we are doing as a lack of something else: namely as a lack of servers. And it does so in a way that’s actually a big lie. There are still servers. We all know this; the servers are still there when we do serverless computing, we just don’t have to manage them anymore. We should be writing less code and only running business critical systems.

Constraints Freedom Limited resources Finances Time Attention But moving beyond quibbles with the terminology, this idea that we don’t have to manage a certain thing is worth dwelling on. Because when do focus on what do don’t have to do, which is another way of talking about how we set certain constraints when we design system, and those constraints focus us, they free us up to focus on other things. What other things? Solving business problems, hopefully. I mean, we could instead focus on playing with other new, shiny technologies like blockchain and VR, but that’s not really the subject of this talk. So we know that serverless computing has something to do with us not having to manage servers, which means we have one less thing to worry about now, but we also are smart enough to know that there are usually downsides to balances out the upsides in this equations. The big question for us, then, is what are the upsides and downsides, and which outweigh the other? I think what you’ll find today is that the upsides outweigh the downsides so much, that we will all be required to actively move toward a future where we focus more on what we actually need to focus on, which is solving the problems we are paid to solve.

So what is serverless?! “Serverless is an event driven, utility based, stateless, code execution environment.” – Simon Wardley “Serverless architectures are application designs that incorporate third-party ‘Backend as a Service’ (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a ‘Functions as a Service’ (FaaS) platform.” – Mike Roberts

So what is serverless?! “Serverless is an event driven, utility based, stateless, code execution environment.” – Simon Wardley Event-driven Utility-based Stateless Code execution environment

Event Driven Publish/subscribe CQRS Backend-as-a-service Rethink how we design applications

Utility Based Compute = commodity Scale to zero Performance (suddenly?) matters IT + Finance

Stateless Global state was already bad, before serverless Incompatible with serverless (mostly) Global state meant side effects, difficulty unit testing, poor code readability, cache contention / performance problems, etc.

Code execution environment Where are the functions? Someone else’s environment Functions! Databases! …-as-a-service

Promises Manage what matters Autoscaling Elastic Scale to zero Excellent fit for one-off compute tasks Environment-enabled DRY

Pitfalls No state Idempotency Autoscaling (connections) Difficult to cache Difficult to coordinate between components You have to plan and estimate 🔮

Pitfalls Security 👮🏽‍♂️ Public Internet Common vulnerabilities (see top 10 guide) Environment separation

Pitfalls Snowflakes ❅ ❆ Test automation Deployment automation

Pitfalls Black Box 📦 Traceability Observability End-to-end Build systems that allow us to see (from outside) what is actually going on (inside) without shipping new code We can’t monitor everything. Observability “aims to provide highly granular insights into the behavior of systems along with rich context, perfect for debugging purposes. Since it’s still not possible to predict every single failure mode a system could potentially run into or predict every possible way in which a system could misbehave, it becomes important that we build systems that can be debugged armed with evidence and not conjecture.” -Cindy Sridharan

Let’s solve problems

Let’s solve problems Automation Web apps Analytics Batch processing Internet-of-things - Scheduled and event-triggered jobs Web apps API gateway GraphQL Host web site on a CDN Analytics / BI / Data Lakes Collect events, store for cheap, create an analytics pipeline without managing servers Batch processing Message queues Event streams

Session evaluations are ONLINE ONLY http://j.mp/SSBREVAL