Presentation: Serverless Patterns and Anti-Patterns
Share this on:
What You’ll Learn
-
Learn pragmatic approaches to architecture that allows developers to focus on business logic and not infrastructure.
-
Hear stories of achieving high reliability and scale without a lot of undifferentiated heavy lifting.
-
Understand approaches you can take today to improve development velocity.
Abstract
Serverless has amazing potential to increase organizational agility and decrease operational costs, but realizing those benefits requires proper implementation. In this talk, we will cover the ideal patterns for serverless applications, anti-patterns for both greenfield applications and migrations, and real-world unexpected consequences of running serverless applications in production. Presented by Joe Emison, who has architected and deployed multiple serverless applications serving millions of users on both the Google and AWS clouds.
What’s the structure of this talk?
I strongly believe in getting the definition right and also talking about what I’m optimizing for. I will start with when I say serverless what do I mean. It’s about achieving business goals. It’s about not doing the undifferentiated heavy lifting. It’s about spending 95% (or more_ of your in-house developers time on customer-facing interactions.
I love this quote by Warren Buffet that says “I only invest in companies that can be run by idiots because eventually, they will.” To me, there’s a software developer version of this that says you should develop your code so that it can be maintained by let’s say average developers because it will be. So we need to be cognizant of making maintainable code. To me, there is a strong corollary to that which is ‘less code is more maintainable always’.
With that framing in mind, I talk about the patterns and the anti-patterns. So, for example, one anti-pattern I’ll talk about is around developers who are used to taking frameworks/languages like Ruby on Rails, Django, or .NET (or something that has these thick middle tiers) and just moving them over. That’s an antipattern. As is functions calling functions. Functions are glue. Functions as a service are great, but to view serverless as a series of connected functions that exist in a backend is to miss the massive business and organizational gains you can get back by thinking about this pattern where functions exist to glue things together from largely leveraging services that already exist.
This sounds like you’re talking to leadership. QCon is a very technical audience. What do you feel the audience will glean from the talk?
This is all incredibly practical for a technical audience.
If you're an architect, I'm laying out for you that when you're architecting your application, you should leverage services. Services are a key part of your architecture. Instead of saying here’s all the code we’re going to write, how can you design the architecture so that we can take our developers time and put it towards developing features. From an architecture standpoint, this is largely a talk about (if you design applications) you should take an approach to your applications that is service-centric and that builds on these backend middle tier services as opposed to writing and running them yourself.
From a developer standpoint, I mean if you’re a line developer who is being assigned stories and you have to implement those stories in a certain way, this talk may not be for you. I’m talking to people who have a choice in how they can implement things.
Can you elaborate a bit more?
Let’s say you’re a developer who’s being asked to implement something and you’re in the planning meetings. You have the ability to suggest why don’t we use this technology. Being able to guide a team towards something like Firebase or an AppSync or one of the Parse replacement services (especially, as you startup new greenfield projects or prototypes) is hugely beneficial for a technical audience.
One of the examples that I’ll share is we launched a Zillow for a commercial real estate that got to about half a million monthly uniques that we ran on Firebase and Algolia with no uptime or scaling problems and with very low cost. With that example, I’ll discuss some specific metrics on how long certain things took and problems we did run into that we just didn’t expect.
Similar Talks
Tracks
-
Microservices: Patterns & Practices
Evolving, observing, persisting, and building modern microservices
-
Developer Experience: Level up Your Engineering Effectiveness
Improving the end to end developer experience - design, dev, test, deploy, operate/understand. Tools, techniques, and trends.
-
Modern Java Reloaded
Modern, Modular, fast, and effective Java. Pushing the boundaries of JDK 9 and beyond.
-
Modern User Interfaces: Screens and Beyond
Zero UI, voice, mobile: Interfaces pushing the boundary of what we consider to be the interface
-
Practical Machine Learning
Applied machine learning lessons for SWEs, including tech around TensorFlow, TPUs, Keras, Caffe, & more
-
Ethics in Computing
Inclusive technology, Ethics and politics of technology. Considering bias. Societal relationship with tech. Also the privacy problems we have today (e.g., GDPR, right to be forgotten)
-
Architectures You've Always Wondered About
Next-gen architectures from the most admired companies in software, such as Netflix, Google, Facebook, Twitter, Goldman Sachs
-
Modern CS in the Real World
Thoughts pushing software forward, including consensus, CRDT's, formal methods, & probalistic programming
-
Container and Orchestration Platforms in Action
Runtime containers, libraries, and services that power microservices
-
Finding the Serverless Sweetspot
Stories about the pains and gains from migrating to Serverless.
-
Chaos, Complexity, and Resilience
Lessons building resilient systems and the war stories that drove their adoption
-
Real World Security
Practical lessons building, maintaining, and deploying secure systems
-
Blockchain Enabled
Exploring Smart contracts, oracles, sidechains, and what can/cannot be done with blockchain today.
-
21st Century Languages
Lessons learned from languages like Rust, Go-lang, Swift, Kotlin, and more.
-
Empowered Teams
Safely running inclusive teams that are autonomous and self-correcting