Tom McLaughlin
The last two weeks of April I went to both DevOpsDays Denver and DevOpsDays Seattle. Not only did I attend but I also spoke at each conference! I feel its import for us to discuss what “serverless ops” is in these early days to help people better understand not just what their role tomorrow may be, but also what their role really is today.
The talk I gave was a departure from previous talks I’ve done in both style and delivery. The title of it is “Flying v. Driving: Myths, fears, and opportunity when going serverless”.
In it I analogize the question of whether to go serverless with a decision we commonly make when we travel which is “How do we get there”? What’s fun about this talk is I change it for each city I give it. Because of the different tradeoffs between getting from Boston to different cities it forces me to potentially come to different conclusions depending on where I’m speaking. I find questions where there is no one right answer to be very interesting because I enjoy the process of understanding a problem, combining the context of the current situation, and making a decision. The are the most interesting interesting engineering problems in my mind.
Let’s jump into the talk and what we covered!
Accidents And Failure
I don’t like flying. I’m left with a bit of unease at relying on air and a pilot and crew whom I do not know. Every time there’s an accident the knowledge of it stacks out in my head. Yet, flying is a safer form of transportation than car travel and the numbers prove that out. I may feel safer when driving but I’m actually at a higher risk of injury.
Similarly, this same sentiment comes up when talking about not just serverless but public cloud and AWS in general. “The cloud is unstable. We can do it better ourselves!” However, can you? How often do you hear people point to an AWS service issue from years ago while failing to mention their own service outages over the past few months? And not just that, but when there is an issue in AWS, they have an entire team to address the problem. To the contrary for many of us, when there’s an issue in your environment who’s there to solve it? Is it just you?
When an accident is rare, but also dramatic, they tend to stick out in our head. But accidents we see everyday are commonplace and accepted. AWS doesn’t make determining failure rates easy but major failures are still rare and minor failures can typically be handled with grace. Also, be sure you’re evaluating your own current failures accurately.
Cost
One issue when discussing cost is we’re not very good at estimating it because we’re not very good at finding all the costs related to our decision. I already own a car, but that doesn’t make my trip from Boston free. To start with there’s gas. But that’s only one piece of the cost of driving. If the trip is multiple days there’s hotel costs. There’s meals on the road as well which often come at a premium over a home cooked meal. Even the cost of coffee alone would be noticeable for me.
When it comes to your cloud costs, you probably need more than a single t2.nano at $4.25 a month to run a production service at scale. You also potentially have additional costs such as monitoring and security on each EC2 instance. And lastly, there’s the personnel required to manage the environment. As for AWS Lambda pricing, your bill scales with your usage and some workloads will perform better cost wise than others.
Finally, for all the case studies and anecdotes about cost savings by going serverless, the following seemingly contradictory statements can both be true.
"AWS Lambda costs 2X compared to running on EC2."
"Serverless saved a company 84% on their cloud bill."
You can’t cargo cult other people’s accounting estimates or results. Always remember that and do your own analysis. Even the company we received the 2X cost estimate from gave the caveat that most of the cost difference they calculated on paper was eaten up by over provisioning and other operational inefficiencies, ancillary costs, and the workforce required to manage the infrastructure. In production they found the cost difference small enough to justify moving to serverless by default.
The Road There
The highpoint of your travel shouldn’t be the car ride or flight there. It should be your destination. I wanted to enjoy the cities of Denver and Seattle, enjoy two conferences, and meet new people as well as see friends. I didn’t travel so I could enjoy the airport or stare out the car window. We need to keep this in mind when we plan. Why are we traveling?
Serverless provides us a chance to offload undifferentiated work so that we can focus on more important work to our organization, our users. Let’s spend less time looking at CPU, memory, and disk dashboards and spend more time looking at application response times. We can even go a step further! Look at optimizing application response times in a manner that drives user NPS ratings higher and understand the impact response time has on revenue generation. This is another way of saying:
“9s don’t matter if user are unhappy.”
Don’t go serverless because you think it’s the next big thing or because you find it interesting. Go serverless because it will let you focus on new problems higher up the value chain and has a more direct impact on your organization.
Going Serverless To Reach Your destination
As always, if you’re starting your DevOps transformation, or looking to improve your current state, talk to us at ServerlessOps about our DevOps consulting and advisory services. We specialize in serverless because we see it as the best way to minimize technical concerns and let you focus more on the people and process in your organization that will have a far greater effect on reaching your organization’s goals.
If you’re interested in our talk, have a watch here!