You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!
The Register published an article right before Christmas 2018. It had a somewhat provocative title, and somehow it ended up in my inbox from a few different sources.
I felt the whitepaper the article refers to provided some interesting analysis. But the case studies it used to make its point are not representative of what most developers do. Model Training, and Low-Latency Prediction Serving via Batching might be representative of what the academia researchers do. But they are not typical of the industry at large. It’s easy to blow the limitations out of proportion when you only look at workloads that highlight its weaknesses.
I have written plenty of articles on the limitations with AWS Lambda myself. I also have shared many of my workarounds and hacks. Indeed, plenty of developers who have worked with serverless in production would tell you that it has many limitations. There are workloads that are not a good fit with serverless right now. But then again, there are plenty of workloads that work great with serverless. When used correctly serverless puts a lot of power in the hands of developers.
Think TCO, not just Lambda cost
I’d like to focus on one of the points the article and whitepaper touched on – cost.
Again, the paper looked at the AWS Lambda service cost with workloads that don’t go well with the pay-per-invocation model. It’s no surprise that they arrived at the conclusion they did.
But when AWS Lambda is used to solve the right problems, others have found cost saving of up to 90% in the real world!
If I wear my shoes on my hands, should I really be surprised that my feet is cold?
Furthermore, for the workloads discussed in the paper, there are other more pressing costs to consider. Most companies would hit these issues long before they see the inflated Lambda costs. The cost of hiring people with ML experience has gone crazy. Big tech companies are paying PhD Machine Learning graduates (!) hundreds of thousands dollars a year in salary and stocks.
Most companies won’t have the luxury of worrying about the cost of using AWS Lambda to train their ML models. They can’t even hope to compete for the engineering talents they need to design these workloads in the first place. Which brings me to the biggest cost saving from serverless that has been barely talked about. The saving in personnel cost.
Let’s take a moment to consider our Total Cost of Ownership (TCO).
There are the charges that go into your monthly AWS bill. Service costs, data transfers, etc. This cost is easy to measure, and is too often the only thing we measure when it comes to cost.
Yet, it often pales in comparison with engineer salaries. On average, a software engineer in London can earn around £80,000 a year, which is roughly $100,000. For sought-after skills such as AWS and DevOps you might even have to tap into the contractor market. A contractor with AWS and DevOps experience can set you back anything between £550 and £800 per day!
With serverless you can delegate even more ops responsibilities to your cloud provider. Patching OS, provisioning and scaling servers, setting up load balancers, etc. This frees your developers from many undifferentiated heavy lifting. It allows them to better focus on building the things that matter to your customers.
In general you don’t need as many specialised tools. Deployment and CI/CD becomes simpler, and you get basic monitoring and logging support out of the box. When you outgrow the native tools such as CloudWatch Logs, it’s easy to integrate with external solutions. While there is still a learning curve involved, it’s a much shallower than the alternative. Mastering Docker, Kubernetes, Istio/Linkerd as well as related DevOps tools is no small feat. Many startups won’t have DevOps expertise from day 1. Having the cloud provider take care of most of the plumbing means they can defer hiring a DevOps specialist. As mentioned earlier, that is a huge cost saving, in the order of $100,000+ per year per engineer!
At Yubl, as we migrated most of our services to serverless, we were able to disband the DevOps team. The developers were more than capable of taking on the remaining ops responsibilities.
As the paper discussed, the pay-per-invocation model doesn’t fit some workloads. In these cases, you can end up paying a lot more with Lambda than with containers or VMs. However, when you calculate the true cost of a solution, you need to factor in the cost of engineers you need to support the solution. At the risk of generalising, I would wager that for 90% of companies, the balance is heavily tipped towards the cost of engineers.
Then there’s the matter of opportunity cost.
While the first-mover advantage is not a guarantee for market success, the ability to iterate faster than your competitors is certainly a business advantage. Freeing your developers of the undifferentiated heavy lifting of managing the underlying compute infrastructure lets them move faster. Which in turn means you as a business can test your ideas against the market quicker, and iterate faster.
It also means you can get more done with fewer developers. Which means less organizational communication overhead. And it means less time and money spent on recruitment, and more time spent on the product.
In startups, and perhaps in life in general, time is the most scarce resource.
– Yevgeniy Brikman, co-founder of Gruntwork
The pay-per-invocation model is new to many, and it’s right that we talk about its potentials. But I can’t help but feel that we are only thinking about it in a limited way – how much money it can save us when our code is not running.
Understanding the true cost of our decisions is complex. With this post/rant I want to make you think about less obvious elements that contribute towards our TCO. Elements that are usually far more significant than the headline number we see in our AWS bill each month. Elements that we, as developers, are not accustomed to think about.
And we haven’t even touched on the idea of FinDev, which was coined by Simon Wardley. The pay-per-invocation model allows cost to be allocated on each user transaction. It gives you true visibility into the return-on-investment (ROI) of different features, and allow businesses to make informed decisions based on that. But that’s another post for another time.
Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Skill up your serverless game with this hands-on workshop.
My 4-week Production-Ready Serverless online workshop is back!
This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.
We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.
If you enrol now you can also get 15% OFF with the promo code “yanprs15”.
Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.
Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!
Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- All you need to know about caching for serverless applications
- Lambda optimization tip – enable HTTP keep-alive
- You are wrong about serverless and vendor lock-in
- You are thinking about serverless costs all wrong
- Just how expensive is the full AWS SDK?
- Check-list for going live with API Gateway and Lambda
- How to choose the right API Gateway auth method
- CloudFormation protip: use !Sub instead of !Join
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- Guys, we’re doing pagination wrong
- Top 10 Serverless framework best practices
- How to break the “senior engineer” career ceiling
- My advice to junior developers