Fear of Flying: Exploring the myths, fears, and preparing for crash landing when going serverless

You own your availability but when is it better to leave your infrastructure primarily in the hands of AWS by building a serverless system? We’ll explore this question using the analogy of flying versus driving to your destination. Flying requires you to put your safety in the hands of a pilot, flight crew, and airline and is routinely a safer form of transportation. Yet, many are still wary and prefer to drive which enables them to own their travel.

We’ll start by covering why people prefer to drive over fly even though flying is safer. The reasoning often involves the discomfort over lack of control and memories of spectacular disasters. We’ll relate that back to the discomfort people have over owning less of their infrastructure and their memory of large AWS outages as they forget the many ones that already occur in their own environment.

Next we’ll explore the right mode of transportation for a trip. Not all trips are the same and the right mode of transportation is dependent on balancing factors like cost, time, and safety. Similarly, what workloads belong being serverless and what ones do not?

Once you’ve decided to book your flight, what do you need to know? You’ll encounter many of the same issues as driving but in new and unique ways. Traffic gridlock at toll booths is similar to the gridlock at the airport security gate… What are the sort of load and scaling issues to be prepared for with serverless? Your car can’t leave without you but your flight can… How do you work within the newly imposed limits of AWS services?

Finally, cars and airplanes are architected for the unique set of issues they may face. How do you architect serverless systems to better withstand failures or even survive a crash?

The audience should come come away with a decreased fear of serverless, and maybe even flying, as well as practical understanding for ways to build reliable serverless systems.



Tom McLaughlin


Tom is the founder of ServerlessOps and an experienced operations engineer. He started ServerlessOps after he asked the question, what would he do if servers went away? At a loss for an answer and