Why #serverless is the new black?
For a while now there’s a lot of hype about serverless (sometimes referred to as FaaS — Function as a Service), nobody seems to talk about IaaS (Infrastructure as a Service) anymore it’s yesterday’s news.
You might be wondering why is everyone so excited about it and what does it even mean?
First things first — serverless doesn’t really mean there are no servers.
I know, I know it says server-less but what it really means is that servers are unimportant in this context.
Obviously the code has to run somewhere and this means there is a server (probably a farm of servers) running it, but we do not want to be bothered about this — this is a detail, commodity it should just be there and do it’s job without our involvement.
What we really care about is our code, our business logic, performance, cost etc.
Hold on you’re thinking how is that different from a PaaS (Platform as a Service) then?
Serverless is a next step after PaaS — I think this diagram below shows very well how it’s positioned in relation to other technologies.
As you can see the major difference between PaaS and Serverless is that the latter has one less box you manage leaving just your application’s code.
Sure your code needs data and sure it can use it but it will get it passed in with request or request it from another service and will return result to another service for processing or storage it will not store data locally (no more sneaky SQLite).
This is how serverless really encourages you to embrace microservices architecture — it would be pretty awkward to build huge monolith using this.
When you build your application using this model you’ll find yourself having many services / functions each performing very specific tasks and piping output from one function to another or using message bus eg. receive image, create thumbnail, resize image, add watermark, add metadata etc.
The amount of code in each function will be very small, deployment model will encourage separation thus enabling you to evolve and release these independently of each other.
Many vendors already offer serverless options in their cloud portfolio to name the big ones you have Amazon Web Services Lambda, Microsoft Azure Functions, Google Cloud Functions, IBM OpenWhisk.
Still not convinced?
The real beauty of this is that most cloud providers allow you to setup your functions for common execution patterns eg. per request, on event, on timer with appropriate pricing structure where you get charged in relation to performed work.
For example if you have to aggregate some data once a day and it takes 10 minutes to complete — your function will only run for 10 minutes each day giving you immediate cost saving as this will be all you pay for (check with your cloud provider on exact pricing structures).
In a per request example if your function doesn’t receive any requests on the weekend you will not pay for it. No need to come up with complex autoscaling rules as the cloud will simply spin up your code if it’s required (even if you get one odd request on Sunday).
Real time stream processing, mobile events, bot messaging, builtin and 3rd party connectors for many data sources, SaaS applications and services will greatly reduce (in some cases eliminate) the need for boilerplate code and will accelerate your time to market.
On top of all that you will get lower cost of operations as you have much less of the stack to manage yourself (see the diagram above showing who manages what).
It also makes it much easier to embrace true DevOps approach.
Less infrastructure and configuration to manage, developers can focus on business logic, pay only for what you use.
Who would say no to that?
It’s as good time as any to start — so go on login to your favorite cloud provider and create your first #serverless function now!