A few days ago I took part in a lunch & learn session at work, where we discussed the paper Serverless Computing - One step forward, two steps back. It was an excellent discussion, and if there weren't any time constraints I'm sure we could have talked about it for the rest of the week, not just our lunch hour.
Note: In my eyes, serverless is not just AWS Lambda functions. Or Azure, Google, or IBM/Apache Openwhisk. It's all the other technologies that work well alongside it - databases, queues, event-driven computation, and technologies that make it super easy to configure and deploy new services in code.
What made it such a great discussion is the fact that while most technologies are polarizing, only a few are as deeply polarizing as serverless.
The Serverless Hater's greatest hits include:
- serverless has servers
- I can't use it for machine learning or [insert obscure academic research topic here]
- It's more expensive than renting your own EC2 instances and running your own servers!
- Vendor lock-in!
- It's slow!
- I can't run it on custom hardware!
All of these… are true in their sense. Not all use cases are well supported by serverless technologies (or at all).
My argument is just that… it doesn't really matter. There are two main reasons for it.
Reason 1: The new liberal computing 🗽
Most profoundly, serverless is just a marketing name (yet a pretty good one - it certainly has that Marmite quality…) for a new computing paradigm - an idea.
It's the idea of writing some code and letting the vendor deploy it anywhere without worrying too much about the where, how, or how much maintaining it is going to cost you, as you only pay per invocation. Serverless is about making it simple and fun to experiment. It's what Heroku was, but more.
The Serverless framework (with a capital S) makes most of your configurations portable between vendors, and opinionated frameworks like Architect make it great for quick productivity.
Tools like Glitch, in addition to being beautifully weird, lets you tinker with deployed code from users of the whole platform, directly in your web browser, like GitHub without any of the git.
To paraphrase Paweł Ledwoń, our CTO at Pusher - "Serverless might be this generation's PHP".
That's awesome. PHP made a whole generation build things.
Just like PHP did back in the day, serverless is opening doors to programming to the new generation of app developers (also known as "kids these days").
Returning to my earlier point, as of why the arguments against serverless (mostly) don't matter? As long as serverless (or any technology, or computing paradigm) is able to lower the barrier to entry to, the playing field has expanded enough, so that it has free rein to take up a bunch of new market share. As the market grows, the earlier arguments merely become fringe or niche concerns.
And the kids? They are the ones who are going to build the future - The kids are alright.
Reason 2: Birth of an ecosystem (of ecosystems), and mash it like it's 2005 🕺
The idea of "just" liberalizing computing was mostly true for the first generation of serverless, way back when Lambda was new. In 2019, serverless is also liberalizing how easy it is for services to interact with one another. It's increasingly being used to extend the functionality of existing services with whatever you really wish to create - flows, extended logic, you name it.
Webhooks are everywhere, and let you integrate and glue services together, with ease.
Zeit Now lets you make any app serverless, and deploy it in seconds, with one command. They have also launched an integration marketplace, that lets developers connect other services, and manage them from Zeit.
The good people at Zeit are also running a global hackathon with some cool prizes between 1 and 2 June 2019, and Pusher is one of the sponsors. If you're building something with Pusher APIs, please come talk to me.
We also we have Netlify Functions -they let you add dynamic components to otherwise static sites that deploy in seconds.
Or Github Actions, to create complex flows based on what's going on in GitHub, taking ops to the next level.
Or Auth0 has their rules that extend the log in functionality of their services.
Cloudflare workers deploy and execute anywhere in the world - and execute nearest to your request.
We're seeing an ecosystem of ecosystems emerge. Want to handle a webhook? Build a chatbot, even? Serverless makes that really, really easy. Just add JavaScript ✨.
What the new generation of serverless reminds me of is actually fulfilling the promise of API mash-ups.
For the younger generation, API mash-ups were the idea from circa 2005 (or when Twitter wasn't a thing yet) - of making dynamic and fully-featured websites by calling on different APIs and connecting their results on your own site.
API mash-ups never really took off in the mid noughties, because the tech just wasn't there at the time. The ecosystem wasn't there. But now, I believe it is here, and serverless is the glue. The JAMstack (JavaScript, APIs, Markdown) is a prime example of where we currently are, and it's amazing.
To summarize, I am a huge fan of Serverless. I believe serverless is a paradigm that greatly lowers the barriers for getting into software programming, and will see serious adoption and development in the next few years.
It's also showing itself as a great "glue" technology, connecting various service ecosystems, and making them work well together. These two benefits greatly outweigh any naysayer arguments.
More, and together - that's progress, and I'm sure that amazing things will happen. 🚀
Top comments (4)
One thing I would love to do is set up my own Azure-like system with webhooks that I could customize. That way I don't have to rely on third-party systems which come and go, especially given Google's recent A.D.D.
Thanks for the explainer! My colleagues have been talking a lot about all things Serverless lately and I haven't had the bandwidth to research what that meant. This post is incredibly helpful :)
I'm glad it was helpful! 🙌
Great post - definitely hearing many find value in serverless being service-ful