Although Serverless has become a bit of a buzzword recently, Steven Faulkner, Director of Platform Engineering at Bustle, disagrees that it is just a fad. In his talk at Node.js Interactive, he points out that much of the faults that people find in Serverless — that it doesn’t scale, that it is not production ready, that it’s too slow and expensive — are provenly false.
Faulkner has made Serverless the backbone for Bustle’s content since it became a thing a couple of years ago. This means he is in charge of all things back-end, but does a lot of front-end work, too. At Bustle, one of the largest women’s media properties online, they use serverless for 99 percent of the requests. This translates to between 10 and 20 million calls per day. Serverless has a latency of less than 200ms average, and it costs less than than their EC2 (Amazon Elastic Compute Cloud) base setup.
Serverless 101
Faulkner also addresses some of the misconceptions surrounding Serverless. The first is, admittedly, down to the name of the concept itself. Serverless is a misnomer because, clearly, there are still servers deep down somewhere.
However, Serverless is the result of answering the question “What if we abstracted all the servers away?” — that is, what happens when you create a service that relieves the developers and admins from having to worry about the underlying server? Serverless implements “anything and everything as a Service,” which is not a new concept.
Faulkner says Serverless is really about Functions as a Service (FaaS). The core tenants of FaaS are that code is only run when needed, you only pay when code is run, and you are not bothered with the details, in fact, your app is a function that sits between the request from and the response to the user:
request
yourApp()
response
There are several providers offering Serverless-Function as a Service. For example, Microsoft Azure has Azure Functions and Google has Cloud functions. IBM has an open source service called OpenWhisk. Faulkner, however, Faulkner thinks Amazon Web Services is ahead of everyone else in this arena and described some examples in his talk.
Why Use Serverless
Faulkner says there are several advantages to deploying web apps to a Serverless service. Despite what many think, Serverless does not mean NoOps; it means Less Ops. Serverless also scales, in the sense that fewer things change between when you have 1 request per second, and when you have 1000 requests per second.
Price is another factor. You only pay when somebody is using your code. This means you can maintain legacy services that you are not sure you should turn off quite yet, or you can deploy services you are not sure will be successful at zero cost.
But even when your code is running, it is still cheaper. Faulkner says that an API he uses to trail all the user tracking and event tracking on the Bustle website and then route it where it’s meant to go costs $2500 month on EC2. On Lambda/API Gateway only $400 month.
For developers, it is easier to iterate at function-based level rather than on your whole application, and Serverless allows for single function deployments. This means you can do things very quickly by re-writing one single function and you can deploy it without affecting the whole. Amazon’s service also makes for quicker deployments because you can deploy 50 functions and alias them all at once.
Why Not Use Serverless
There are, however, also several reasons why you may not want to use a Serverless service like Amazon’s. There is, for example, the risk of becoming locked in. Migrating from a Serverless FaaS can be a minefield, but, according to Faulkner, from Amazon it is not that hard. He has a chunk of code 9 lines, an Express server, that calls the Lambda functions if you have to migrate.
Another problem is running cold functions. If you’re doing something outside the function, like loading a bunch data before the first time your function runs, this can delay the first run an unacceptably long time. Amazon solves the problem by running all your functions within 3.5 hours of the upload.
Testing is yet another area that can cause problems. Testing individual functions is not too difficult according to Faulkner. But when you want to do integration testing across all of your functions, that is still painful.
Serverless at Bustle
At Bustle, the front-end serves up HTML and JavaScript through the API gateway. The application reads some static assets through S3 and uses Lambda for SSR (Server Side Rendering) to generate the actual pages.
On the back-end, Bustle uses GraphQL to fetch most of the data. The JSON generated by GraphQL is processed through API Gateway and Lambda, which are talking to dynamodb or redis, with some PostgreSQL thrown into the mix.
Tools
Despite all its advantages, if you are deploying more than two functions, it is very painful to deploy your stuff manually. That’s where the tooling comes in. Faulkner mentions Serverless Framework, node-lambda, apex, claudia.js as tools to check out. But, he also recommends his own open source tool, shep, which will allow you to build and deploy your serverless applications to Amazon’s Lambda with a few simple commands.
For more examples and details, watch the complete presentation below:
If you are interested in speaking or attending Node.js Interactive North America 2017 – happening in Vancouver, Canada next fall – please subscribe to the Node.js community newsletter to keep abreast with dates and time.
