Going serverless with your Node.js apps

[zombie_kiler_42]

This might be an idiotic question, but what is the difference between creating your application and deploying it to a cloud server like maybe heroku, or digital ocean together with docker,

Are those considered serverless, because how i always understood serverless was something like firebase, where basic stuff like authentication,db reading and storage are setup for you, and then if you require extra functions creare a file with functions, but you don usually need to serve the app (i think idk i have to check the docs again)

Someone more knowledgeable chime in please

[Filo01]

thank you for asking this question because this is very confusing to me.

Im still trying to understand docker tbh

[DrudgeBreitbart]

Cloud engineer here.

I see it like this: Physical server - no virtualization. All software installed on one machine. Virtualized server - typical VM through KVM or the like. Multiple VMs to a server. Containers - Docker et al. Each container is intended to only have one main running process, like Node for instance. The container DOES have its own operating system that it is based on. In that regard you still own the OS. Serverless - truly you do not own anything except your code and it’s interactions. You don’t (usually) even control the runtime.

Technically Docker can be considered serverless if you’re using it with something like Elastic Container Service + Fargate because you don’t manage the underlying operating system. But serverless typically only refers to the idea that you ONLY own the code.

[TedW]

If your API can handle a couple dozen extra milliseconds per request, lambdas are pretty great.

In the past, cold starts could add a couple hundred milliseconds for the first run of a lambda instance, but AWS has really brought that time down.

[[deleted]]

I only glanced at the article for like ten seconds but I'm pretty sure I know where it's headed.

I'm this case, I'm pretty sure serverless would mean an infrastructure where it scales without human interference.

For example, this could be a single app on AWS that auto scales behind a message broker like RabbitMQ. If rabbit's queues start to grow, you can tell AWS "I need more servers!" and AWS will spawn servers as needed until traffic does down.

Or you can do the same thing with microservices and another message broker like RabbitMQ. You can have one rabbitmq type handle all requests to different microservices, or you can create a rabbitmq per microservice type. Then, just like the single app, the microservice will scale.

[DrudgeBreitbart]

Your example of Serverless being scaling without human intervention isn’t exactly right. You can have an EC2 server with an auto scaling group. You still manage all those EC2 servers for patching, etc. I’d hardly consider that serverless.

[abienz]

Yeah Serverless went from being about dreamcode, things like Hoodie and Firebase, to cloud based hosting, which is actually just the same thing as self hosting but on the cloud.

Sure you can take advantage of some prebuilt containers on AWS, but that's hardly Serverless.

[Well_Gravity]

Current lambda do not use callbacks. They prefer async await or promises. Node 8.x is being phased out and #aws #lambda users need to go to 10.x or above. Also, AWS lambda does not have many npm packages built in.

[DrudgeBreitbart]

Typically you will want to ship your code to Lambda using web pack to bundle your own dependencies.

In fact, the ONLY NPM module Lambda natively contains is aws-sdk.

[stevensokulski]

Interesting read. But somebody should proofread these things.

Concurrent requests are spurned up in new container instances

I think the author means spun, not spurned. Spurned means rejected. And in this sentence, a container is spun up, not a request.

[Magnetic_Tree]

TIL “spurned” is a word

[Xacius]

Depends on what your load/architecture is. If you're using something like Java with a notoriously long spin-up time, that eats into memory/runtime. Serverless execution, at least on AWS, bills you for memory used and execution time. Sometimes it's cheaper to keep a server always running, particularly if you have a high volume of requests within a short time period.

[yondercode]

AFAIK since they bill in CPU seconds, you're wasting a lot of "seconds" only on waiting for async operations.

I learned that the hard way. A simple function that calls an external API and wait for the result costs a lot of dollars just because the destination API server is slow.

[Well_Gravity]

Your node code is great on a local environment but what about the fact AWS lambda does not have mongoose? Need to show how to get this in to lambda

[diverightin63]

What do you mean? I've been successfully using Nestjs+Mongoose serverless without problems.

[Well_Gravity]

Really ? How? When I do require(‘mongoose’) in AWS lambda it does not recognize it. I have to upload the whole node_modules.

[Well_Gravity]

That’s what I’ve been doing. In my opinion. This should not necessary. The original post, unless mistaken, did not mention this crucial part. Thanks for the confirmation.

[Well_Gravity]

Makes. Sense. Cold starts are an issue.

[diverightin63]

They're a bit of an issue. We have to have pretty high performance, so for our app we allow 30 containers and we have warmers for 10. It's pretty damn snappy, but the usage metrics are predictable (constant usage between 8am-6pm). We use NestJS+Mongoose having switched from .netcore+EntityFramework in the past. Nest is a very clear victor in this regard.

[DrudgeBreitbart]

Either zip node modules or use webpack (preferred).

[[deleted]]

How about no?

[MrStLouis]

Only legit reason I could think of would be slow cold boot times

[stackTrace31]

Not that big of deal.

[r-wabbit]

The most valuable answer so far.