All About Serverless
6 minutes read
So maybe you heard stories of a guy serving 30k pageviews for $0.21, or people reducing their hosting costs by two orders of magnitude and you want to know what all the fuss is all about. What is this Serverless thing and is it for me? How about security and maintainability?
In this blog post I want to talk about the current state of serverless and if it's the correct choice for your business.
What is Serverless?
It's a kind-of-badly-named new paradigm of using servers in the cloud. Of course there are still servers involved in Serverless. But just as WiFi is only wireless until it hits your router, Serverless has servers, it's just the cloud providers' job to provision them. You pay for exactly the resources you consume.
Serverless is closely connected to, but not the same as, Functions-as-a-Service (FaaS). In FaaS functions are called in response to an event, for example a request to your API endpoint. Other possible events could be a video file upload to a specific S3 bucket that triggers a transcoding job and the upload of the transcoded video to another bucket.
When not to use it
Let's get this out of the way early: If you're doing heavy, cpu-intensive computations you're probably better off with dedicated servers. Since FaaS is usually charged per GB-second, the longer the function runs and the more memory it consumes the costlier it will be.
Also, long-running tasks or tasks that can be batched and possibly processed later can be solved more effectively with provisioned servers (take a look at EC2 spot instances for this scenario).
The promises of Serverless?
As someone said on-stage at re:invent 2017: "Serverless is about maximising elasticity, cost savings and agility".
So while cost savings are one major draw, it's not all. Let's go through these points one by one.
Your website gets featured in the news and you get hit with 100x your usual traffic. Your provisioned servers are overloaded, the website goes down and once you notice it's too late and the people are already gone.
Serverless promises to handle cases like this like a champion. You get 100x the traffic? No problem, your cloud provider scales it for you. Get a fraction of the traffic for a time? You automatically save on your hosting costs because there are no idle servers that cost money.
The cost saving aspect is the one you're probably already most familiar with. Paying as good as nothing for your MVP (on each of the three big cloud providers you get at least the first million invocations for free each month), switching internal functionality over to Serverless to remove servers
If you're working in an agile environment and getting new features to market is important, Serverless might be for you. There is less operations work and configuration, no server patching, no disk-space or memory management and easier versioning of your code. No trying to keep your servers busy by throwing decoupled services all on the same server to save on instances.
Serverless encourages the microservice approach: keep your functions small and compose them.
To get features developed and tested quickly you shouldn't re-invent the wheel and Serverless encourages this approach. Using third-party tools and APIs for everything that is not your core business and is not making you money is easy with Serverless: Use Auth0 or Cognito for user authentication, Stripe for payments, Intercom for customer service, S3 and CloudFront for storing data and CDN, etc.
There's more to Serverless than saving money, as Pete Johnson writes here: Serverless Isn’t About Cost Savings, It’s About At-Bats. In the end it's all about delivering real business value not just code.
Who uses Serverless?
It's not just small startups moving fast and breaking things.
A 135 year old shipping company does it as well as a bank from the netherlands. Autodesk does it and Bustle handles 52 Million visitors with Serverless technology.
Of course Serverless is not the panacea some people make it out to be. Here are some areas that might raise concerns:
If this is a concern to you, definitely read Stressed about serverless lock-in? Don't be by Matt Asay as well as Why vendor lock-in with serverless isn’t what you think it is by Paul Johnston. Serverless is still young and Open-Source solutions are already being built. Also, if you use the excellent Serverless framework your code can be quickly changed to accomodate other vendors. All the other services your vendor provides will be more difficult to recreate but that's what you pay your vendor for.
In Serverless Security implications—from infra to OWASP Guy Podjarny, co-founder of security firm Snyk talks about what the differences are in securing Serverless apps vis-a-vis traditional apps. Some things are easier to manage (no more unpatched or compromised servers, Denial of Service attacking your wallet), some stay the same (your code, vulnerable dependencies, your database) and some get worse (more third-party code involved, security harder to monitor).
If you are interested to see how someone might go about attacking a serverless application, give Gone in 60milliseconds a watch. Very interesting stuff.
I'd definitely trust Amazon and Google with securing their part more than some random small company. Just be sure to take care of your side of the equation.
Debugging and Tooling
The tools to troubleshoot are still in an early stage and often you're flying pretty blind, especially if you don't know what to look for.. This is something that definitely has to improve in the future.
Serverless definitely has very interesting advantages to the Serverful paradigm. If you want to get your feet wet, try converting an existing, internal tool that might already be event-driven and see how that goes.
Getting Started with Serverless
Okay, so where do I start?
The main players providing Serverless FaaS solutions are Amazon Web Services (AWS) with Lambda, Google with Cloud Functions and Azure with Azure Functions. While I focus on AWS because they have been in the Serverless field the longest and have an excellent ecosystem of services, all of the platforms are worth trying out.
I hope I was able to give a good first overview of the technology and where it might lead in the future. If you have any questions or comments shoot me an email.
Thanks for reading!