Presentation: Serverless Patterns and Anti-Patterns

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 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.

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.