Save money! Vendor lock-in! Autoscale! High latency!
The rallying cry around serverless computing is loud, but not particularly clear. Ever since the cheer-inducing promises of having to run "no servers! no instances! nothing!" at AWS re:invent's introduction of the Lambda platform in 2014, the development community has been debating the value of serverless.
What is serverless computing? The term "serverless" has been around much longer than Lambda. For years, serverless simply described applications that partly or completely incorporated third-party services to manage server-side logic. Today, serverless computing is the process by which developers write small pieces of stateless code and the serverless platform manages the complexities of scalably executing the function. To put it simply, it is an event based system for running code. Developers to upload their code to a cloud provider (with some running parameters) without managing their own server systems. The platform handles everything: scaling, resource provisioning, etc. Well, not everything. Teams still have to incorporate alarms, log statements, test cases, metrics gathering, and more into the code itself or else they have no visibility. Overall, though, the burden on developer organisations is significantly reduced.
The initial response to AWS Lambda, Google Cloud Functions, and others was overwhelmingly positive. Steve Faulkner, a senior software engineer at LinkedIn and former director of engineering at Bustle, explained how his team at Bustle completely re-architected their platform around serverless, shared responsibilities across their team, and cut their costs by 40%. Netflix gushed that Lambda allowed them to replace inefficient procedural systems with declarative rules based systems, making processing and deploying media files much more efficient. And Airbnb celebrated how serverless allowed them to build a real-time data analysis tool that existed nowhere else.
Now, serverless computing was never meant to solve all problems. Cold starts result in high latency, which makes this suboptimal for any realtime applications. Platform constraints such as the 15-minute timeout on Lambda reinforce that long-running, predictable workloads are better off managed on one's own server. Serverless adds the most value when there are a lot of small, event-driven workloads.
Yet even then, detractors have said serverless has not delivered on its promises, and will remain relevant for only a narrow set of use cases. One UC Berkeley study, for example, states that serverless' benefits are "directly at odds with modern computing." When the researchers tried training a machine learning model on Lambda, for example, they found that Lambda's data-shipping architecture caused their algorithm to run 21x slower and cost 7.3x more than if they had run it on EC2. Why did that happen? Serverless functions run on isolated VMs away from the data, so data is pulled to the code rather than visa versa, despite the code being much smaller than the data. Improvements in network speeds, they argued, would do little to change that result, and we are better off focusing on more monumental innovations in cloud computing.
So the question for investors and founders is: should we invest our money and time into an ecosystem that, in the end, may not save money, reduce complexity, or speed up deployments?
If you inherently believe that platforms improve over time, then the answer is yes, of course.
But we believe the reason to focus on serverless computing today is all about usability. Serverless deserves our attention and our capital now because, above all, it enables an improved developer experience. More than cost or some other operational factor, serverless is worth the investment because it allows computer scientists to focus on what they enjoy: building.
Twilio, Stripe, Shopify, Segment - some of technology's greatest successes have been driven by developer-led sales. While serverless has the potential to benefit organisations in far greater ways than producing more productive engineers, investors and founders need not wait for these to materialise.
One last anecdote:
Only three months after launching their first serverless application, Coca Cola presented at AWS re:invent about implementing serverless computing within the enterprise.
Their cloud migration lead highlighted the significant cost savings serverless provided compared to IaaS for their long-tail systems. An AWS solutions architect then discussed how serverless would drive a "paradigm shift" in security and networking. And the Coca Cola solutions architect that concluded the presentation? Well, he got most excited about how he could change a file, commit it, and watch its build server update automatically.
How did he describe this process?
If you are exploring or building around serverless, microservices, and/or k8s, we at Mosaic would love to hear from you.