Why you should stop running your own node server

Severless

 
Simply put, running a server is a time consuming and seriously stressful task. You constantly have to check to make sure it’s not down, overloaded, or under a DDoS attack. Every function execution can potentially crash your entire service. And you need to make sure you are not running different versions of your application in the same auto-scaling group – if there is a miss matched version it’s not easy to change.
 
Therefore, when running your own server, you’ll find yourself being able to relate to the proverbial expression ‘The Sword of Damocles’.
 
 
Sword
 
As the above image shows – can you spot the hanging sword? It was also said to be hanging by a single hair – it’s what’s known as being in a precarious position. But it doesn’t have to be that way…
 
 

The future is serverless…

 
‘Serverless’ doesn’t mean there are no servers required; it just means you wont have to be the one dealing with them. One way of doing this is:
 
RestfulAPI: AWS Api gateway with lambda
 
You can find most of the information on the official documentation (here), but here is a small summary of what I believe is important to know when building a RestAPI.
 
Pros:

  • Pure Javascript functions
  • Awesome framework available, here
  • Theoretically capable to scale to “infinite”
  • Some features come out of the box so you can concentrate on your code (DDoS protection, throttling, etc.)
  • A Lambda function can call another lambda function (be careful with infinite loop)
  • Super easy to test (it’s just a function)
  • You can do server side rendering

 
Cons:

  • If not called within 5 min, a function gets longer to execute as it went “cold”
  • Connecting to an external mongodb is probably not the best option since it will have to reconnect all the time (you better use SimpleDB or DynamoDB).


Limitations

  • You are limited to 100 functions running at a time by default
  • You are losing the existing tooling made by the community so far. (Express, PassportJS, etc.)

 

Realtime communication: Pusher

Pros:

  • You can set a webhook to an event. Point it to one of your API gateway endpoints and handle it with a lambda function.
  • Private channel authentication out of the box by calling your own endpoint.
  • A large set of library to make your life easier

Cons:

Gets expensive at scale
 
 

Conclusion

 

Peace of mind

Clearly you will become completely dependent on an external service. But given this is their area of expertise; I trust them to do a better job than I ever could.
 
No more “x micro service is down” or “why is this endpoint not consistent“. You don’t have to think about memory leaks, scaling, versioning and so on. It’s data in/ data out, if it worked once, it will work all the time. So that sword hanging precariously above your head will no longer be there, and as a result, you’ll have more time to focus on what’s really important – writing code to build a great product.
 
Furthermore, while you’re busy developing your own product, so too are others with theirs. The services you are using will keep getting better over time and you will benefit, without the need for any extra work.
 

Cost

Calculate the cost of an engineer spending time developing and maintaining a server and you will suddenly realise what I am suggesting is actually cheaper.
 
Also, your tech team should be spending their time and resources building the core product and to be honest, that’s the only thing that should really matter.
 

Choose it carefully

There are some case scenarios where Lambda is not the best option. Once a function goes “cold” it will have to load all of your dependencies again. If you are working with big libraries, this will have a massive impact on performance.
 

It’s the future

Serverless application is clearly one of the options I see for backend development in the future. Although there is a lack of libraries at the moment, I am convinced the community will soon bring up some amazing projects. The serverless Framework is a fairly good example.
 
Cheers
 
Florian
 

0 Comments
Previous Post
Next Post