#serverless = compute + patterns
2 weeks ago we ran the first ServerlessConf… a conference dedicated entirely to serverless technologies, architectures & use-cases.
The conference was hugely popular, and was such an incredible mix of bright and talented people. For a couple of days the #serverless hashtag trended on Twitter… and a lot of people in the tech community took notice. There was a lot of curiosity and even a little backlash about the serverless “hype”.
So I want to dig into the question: What’s this #serverless thing anyway?
serverless = compute + patterns
The rise of the term serverless can be attributed to the growing popularity of compute technologies like AWS Lambda that are often described as serverless. There are a couple of parts to this:
- there are serverless compute technologies:
like AWS Lambda, IBM OpenWhisk, Azure Functions, Google Cloud Functions and webtask.io
- and there are serverless architectural patterns:
patterns for crafting systems without traditional back-end servers… generally this includes integration with 3rd party services, whether they be native cloud services (such as the rich array of services in AWS), or 3rd party web services.
Serverless compute technologies on their own are useful, but the real power comes from integration with other services — hooking lambda functions into AWS services & 3rd party services to orchestrate rich & powerful event driven pipelines.
This has been referred to as a “servicefull” approach — where cloud services are heavily leveraged, and serverless compute technologies are used as “the last mile” to weave the custom components and 3rd party services together.
With a serverless + servicefull approach, you can compose complex applications with a minimal amount of custom back-end code.
Let’s dig into each concept a little more…
Serverless Compute Technologies
A lot of people (including myself) refer to AWS Lambda, IBM OpenWhisk, Azure Functions and similar technologies as “serverless compute services”… and sometimes even just “serverless”.
There’s a lot of debate as to whether serverless is the best term to apply to these technologies. AWS Lambda is basically a fleet of servers provisioned to execute functions on your behalf. Calling it a serverless compute service perhaps muddies the waters… It’s kind of like calling EC2 a hardware-less compute service. It makes sense in one way (hey, don’t worry about setting up hardware!), but confuses in another (but isn’t there still a LOT of hardware!??).
During ServerlessConf, Patrick Debois suggested that we refer to these technologies as “function-as-a-service” (or FAAS)… I like that this term is a little more explicit, but I think that serverless moniker is here to stay.
Honestly… it’s just a term… As Paul Johnston has said: “Serverless” is just a name. We could have called it “Jeff”. We use terms to establish shared contexts between parties to facilitate communication about concepts/ideas… so as long as we all pretty much agree on what serverless means, it doesn’t really matter what it’s called.
Serverless Architectures —and going Serverless but Servicefull
Engineers who build serverless systems aren’t just replacing traditional back-end servers with function-level compute services like AWS Lambda — they are leveraging a vast array of 3rd party services & cloud services to orchestrate powerful, complex systems with a small amount of glue code.
As you pick apart a traditional monolithic back-end codebase into discrete functions, you realise that a whole raft of responsibilities can be outsourced to a specialist service provider — saving you time and money. This has been referred to by Patrick Debois as building “servicefull” systems.
Many services nowadays are designed to be accessed directly from web application running in the user’s browser — cutting out the need to develop custom back-end components for a whole range of things.
Joe Emison wrote a great article a year ago about how “the middle tier is being abstracted by cloud services”.
In our serverless web-based platform (A Cloud Guru), here’s a few services that we invoke directly from our web app in the browser:
- Auth0 for authentication. Our user’s browsers talk directly to Auth0 for login and signup. Our web application gets a JSON web token from Auth0, which can then be passed to other services such as Firebase, or our lambda functions to perform protected actions.
- Firebase for our database. User’s browsers talk directly to Firebase to read data, and in many cases, write as well. We don’t run or manage any database servers, or any intermediate servers to manage data access.
- Imagefly for image resizing and optimisation. This is done on-request from user’s browsers, and resized images are cached.
In fact, in many entirely serverless platforms, the amount of code residing in a function-level compute service like Lambda is actually very small.
No, this does not solve all your problems.
As with any architectural choices, there are trade-offs. In serverless architectures you are trading control for speed. And as with anything, you have to identify whether this is the right trade-off for your business.
3rd party services offer rich feature sets out-of-the-box that you can start leveraging right away. They keep the service running & are responsible for meeting SLAs. They add more features over time, offering you new capabilities that you didn’t need to invest in yourself. You can build powerful and complex systems very very quickly.
But you do give up control of these parts of your system.
Want a feature that isn’t there? You can ask, but it may never be added.
Is there a bug? You are at the mercy of the service provider’s fix/release cycle and you’ll probably have to find some hacky workaround in the meantime.
Has the service gone down? You have to wait for them to fix it. And in many cases, you are a little screwed until they do.
So, the term serverless encompasses both compute service technologies and broader architectural principles which can be used to compose systems.
It isn’t magic and it won’t solve all of your problems — but it does allow you to build rich, complex applications and platform at rapid pace… which is why we build this way and why we love #serverless 😉
A Cloud Guru
The mission of A Cloud Guru is to engage individuals in a journey to level-up their cloud computing skills by delivering the world’s leading educational content designed to evolve both mindsets and careers.
“Let no man in the world live in delusion. Without a Guru, none can cross over to the other shore.“ — Guru Nanak
Our courses are delivered by industry experts with a shared passion for cloud computing. We strive to serve our growing community of cloud gurus, who generously contribute their insights in our forums, workshops, meet-ups, and conferences.
Keep up with the A Cloud Guru crew @acloudguru.