Serverless Ops

Preface

The dominant way we deployed and ran applications over the past decade was machine-centric. First, we provisioned physical machines and installed our software on them. Then, to address the low utilization and accelerate the roll-out process, came the age of virtualization. With the emergence of the public cloud, the offerings became more diverse: Infrastructure as a Service (IaaS), again machine-centric; Platform as a Service (PaaS), the first attempt to escape the machine-centric paradigm; and Software as a Service (SaaS), the so far (commercially) most successful offering, operating on a high level of abstraction but offering little control over what is going on.

Over the past couple of years we’ve also encountered some developments that changed the way we think about running applications and infrastructure as such: the microservices architecture, leading to small-scoped and loosely coupled distributed systems; and the world of containers, providing application-level dependency management in either on-premises or cloud environments.

With the advent of DevOps thinking in the form of Michael T. Nygard’s Release It! (Pragmatic Programmers) and the twelve-factor manifesto, we’ve witnessed the transition to immutable infrastructure and the need for organizations to encourage and enable developers and ops folks to work much more closely together, in an automated fashion and with mutual understanding of the motivations and incentives.

In 2016 we started to see the serverless paradigm going mainstream. Starting with the AWS Lambda announcement in 2014, every major cloud player has now introduced such offerings, in addition to many new players like OpenLambda or Galactic Fog specializing in this space.

Before we dive in, one comment and disclaimer on the term “serverless” itself: catchy as it is, the name is admittedly a misnomer and has attracted a fair amount of criticism, including from people such as AWS CTO Werner Vogels. It is as misleading as “NoSQL” because it defines the concept in terms of what it is not about.¹ There have been a number of attempts to rename it; for example, to Function as a Service(FaaS). Unfortunately, it seems we’re stuck with the term because it has gained traction, and the majority of people interested in the paradigm don’t seem to have a problem with it.

You and Me

My hope is that this report will be useful for people who are interested in going serverless, people who’ve just started doing serverless computing, and people who have some experience and are seeking guidance on how to get the maximum value out of it. Notably, the report targets:

• DevOps folks who are exploring serverless computing and want to get a quick overview of the space and its options, and more specifically novice developers and operators of AWS Lambda

• Hands-on software architects who are about to migrate existing workloads to serverless environments or want to apply the paradigm in a new project

This report aims to provide an overview of and introduction to the serverless paradigm, along with best-practice recommendations, rather than concrete implementation details for offerings (other than exemplary cases). I assume that you have a basic familiarity with operations concepts (such as deployment strategies, monitoring, and logging), as well as general knowledge about public cloud offerings.

Note that true coverage of serverless operations would require a book with many more pages. As such, we will be covering mostly techniques related to AWS Lambda to satisfy curiosity about this emerging technology and provide useful patterns for the infrastructure team that administers these architectures.

As for my background: I’m a developer advocate at Mesosphere working on DC/OS, a distributed operating system for both containerized workloads and elastic data pipelines. I started to dive into serverless offerings in early 2015, doing proofs of concepts, speaking and writing about the topic, as well as helping with the onboarding of serverless offerings onto DC/OS.

Acknowledgments

I’d like to thank Charity Majors for sharing her insights around operations, DevOps, and how developers can get better at operations. Her talks and articles have shaped my understanding of both the technical and organizational aspects of the operations space.

The technical reviewers of this report deserve special thanks too. Eric Windisch (IOpipe, Inc.), Aleksander Slominski (IBM), and Brad Futch (Galactic Fog) haven taken out time of their busy schedules to provide very valuable feedback and certainly shaped it a lot. I owe you all big time (next Velocity conference?).

A number of good folks have supplied me with examples and references and have written timely articles that served as brain food: to Bridget Kromhout, Paul Johnston, and Rotem Tamir, thank you so much for all your input.

A big thank you to the O’Reilly folks who looked after me, providing guidance and managing the process so smoothly: Virginia Wilson and Brian Anderson, you rock!

Last but certainly not least, my deepest gratitude to my awesome family: our sunshine artist Saphira, our sporty girl Ranya, our son Iannis aka “the Magic rower,” and my ever-supportive wife Anneliese. Couldn’t have done this without you, and the cottage is my second-favorite place when I’m at home. ;)

¹ The term NoSQL suggests it’s somewhat anti-SQL, but it’s not about the SQL language itself. Instead, it’s about the fact that relational databases didn’t use to do auto-sharding and hence were not easy or able to be used out of the box in a distributed setting (that is, in cluster mode).