Hacker News Reader

Comment by tedk-42 | Hacker News Reader

I disagree with all the comments posted so far.

This should be a perfect use case for lambda, not "oh you're API is receiving more than 10M req/day? Use Elastic Beanstalk instead with an EC2 instance and ELB". This kind of comment is just to abuse the free tier that AWS provide you with.

The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route. Is it worth 8x the cost and 15% reduction in performance? The article argues no. If anything, AWS should price API GW and Serverless more competitively.

It's nice to see though that the Firecracker implementation savings has been passed down to AWS Customers.

If the article saw a 1.5-2 times increase in cost, the debate would be much more interesting.

I'm in the container camp because serverless isn't cheap and you can't have long running processes.

View on HN

Exactly. Like anything, right tool for the right job.

I was hosting my personal website on EC2 with an RDS instance and it cost around $20/month. But since the site gets little-to-no traffic and I got sick of EC2 upkeep, I switched S3 & Cloudfront: now my bill is $0.80/month.

Another example: at work we inherited an old EC2 instance that was set up solely to run cron jobs on other servers. Occasionally it would lock up or go down, for whatever reason, creating chaos for the servers that needed specific jobs run frequently.

We switched to AWS Lambda functions for those cron jobs and they've never failed once.

If you're running a games website that gets pinged 24/7, don't use Serverless. But the notion that it's slow and overpriced is misguided if you're applying the wrong use case.

I wonder if it's a generational thing but it seems to me that people nowadays have forgotten that you can host more than one site or database per server. Failing that shared hosting still offers amazing value if you don't need anything to weird e.g. someone like Bluehost or Hostgator offers unlimited* sites + databases for about $5/month

>you can host more than one site or database per server

I'm fully aware of this but never do it because I'm pretty much incompetent as a sysadmin. I don't want to be in a position where I can break an existing project while trying to configure something new I don't understand yet. Nor do I want to run security updates for a blog I setup 5 years ago.

I'm not 100% thrilled with going serverless because it makes debugging awful, but it has saved me money and it makes most things easier. If I went back to shared hosting, I'd just be paying for the privilege of getting to shoot myself in the foot.

I have a t2.micro that runs several things:

- Mumble server for my wife's WoW guild (They don't use Discord because some of their peeps are running on really dated hardware that can barely handle WoW, let alone an Electron app running concurrently with WoW)

- Taiga.io task tracker

- Dev server for a web game I'm working on (If I ever decide the game is good enough to publish, obviously I'd run dev and prod servers on separate instances)

- IRC bouncer

- Pi-hole DNS for my phone

Containers? Don't need 'em. And each process requires next to no CPU time, so I always have nearly full CPU credits. RAM is enough unless I'm building the latest version of my IRC bouncer, but hitting the paging file for a few minutes is no big deal.

I host a site on S3, CloudFront, and Lambda and I'm always looking at the billing to see when it's time to graduate to a normal server setup. It's not going to be a huge project to switch from the existing setup to a docker style setup on one server. So, I'm keeping the site on S3 until it becomes favorable to move it.

Since the organization only has the one site, there's not enough usage to warrant $5 a month for even a tiny a virtual server.

I can also vouch for this. I run a low traffic website on S3 and Coudfront. And Lambda is perfect for handling the small amount of dynamic content or form processing that it requires. It costs cents a month to run and doesn't need any maintenance.

How did you replace a site that needed rds with s3? Was it a blog that you moved to Jekyll or something?

If you are comfortable with React, look at GatsbyJS. It is pretty amazing what you can build into a static site.

They may have used S3 Select: https://aws.amazon.com/blogs/aws/s3-glacier-select/

S3 is just slower but in theory you can do everything you can with rds.

So e.g. if the queries you are making aren't time sensitive or are easily cached switching to s3 can be okay.

most likely either Jekyll or Gatsby

Some tools are't the right one for any jobs we actually have.

>The whole idea of serverless is so you don't have to manage infrastructure

That's one of the ideas. Serverless shines for burst-y traffic where the traffic timing is unknown. If I had known static high loads I wouldn't use serverless.

Serverless works great for my apps. My traffic is driven by hourly notifications so I get 100x more traffic on the hour than the rest of the hour. I could write a bunch of ML to figure out load scaling but that is code I don't want to focus on.

Bursty or not, if the aggregated number of requests per day is in millions not hundreds, AWS API Gateway & Lambda is significantly more expensive than the more traditional options.

Not if you have to serve 1 million requests in one second (with low latency) and then don't get any requests for the rest of the day. On the contrary, traditional options will probably end up costing a lot more since you'll need to have them ready in advance to serve the requests instantly and so you could be paying for the entire day of capacity or at least several hours.

Low latency for 1m requests in one second? Yeah, Lambda won’t help you with that. Their cold starts will stop you dead. Particularly if you’re in a VPC and they have to allocate servers with the appropriate ENI. Not to mention, you’ll be hitting concurrency limits.

Sure, if you ping your lambdas frequently to keep them from having cold starts, and you’ve worked with Amazon to increase your concurrency limits 100 fold, you might be able to handle 1M requests in a second. But then you’re being charged a lot more than just for those 1M requests.

Cold starts for node are ~500ms.

Add a couple of seconds when spinning up an ENI. New nodes in a VPC are around 3 seconds (and our last EBC with Amazon indicated that it won't get lower than that for awhile). It's worth noting that this impacts ECU scaling for Aurora Serverless as well.

Why would you need to put a Lambda in a VPC? For access to a database, other EC2 bound resources, or overall network security reasons (such as outbound network monitoring).

You may be interested in the latest news re: allocating ENIs in VPCs for Lambda[1]. They've finally got the cold-start situation a little more under control in that scenario.

Here's the meat, to save you a click:

> AWS says that the one-time setup of the shared network interface can take 90 seconds to complete. But because the network interface gets created when Lambda functions are first created or VPC settings updated, the connectivity-related latency during cold start approaches zero. The same goes for function scaling, which no longer requires new network interfaces for each new execution environment.

[1]: https://www.infoq.com/news/2019/09/aws-lambda-vpc/

I did not know this. Thank you.

All Lambda does is spin up a bunch of containers to handle that. Why is that any different than traditional options? You would just horizontally auto scale in the exact same way. You don't HAVE to pre-provision anything.

Plus, receiving 1 million requests in one second, you'll have cold starts for every new container that gets created for you, so achieving consistent low latency would be impossible since you don't control that.

Does AWS let me spin up containers as fast as it lets me spin up lambda processes? I've never seen that but then they do add things regularly.

So possibly a good fit for IoT.

No. It depends on the IoT application. The one I'm involved with (smart metering) produces data at regular 15 minute periods 24/7.

This is a very predictable and constant traffic load and not at all suitable for serverless/lambda.

In fact, its the complete opposite.

Many IoT applications are very predictable (anything with regular sensor-readings for example or with repeatable patterns such as people returning from work and turning things on).

People 'returning from work' and 'turning things on' are exactly the kind of situation where serverless/lambda shines.

See also: traffic jams and people switching on their electric kettles en-masse during intermission of major soccer matches. The first disrupts whole economies and the second has given rise to 'fast pumped storage' at the electrical grid level.

Just because you don't see the accumulated effects does not mean they aren't there.

What you need to consider [is] that there are a lot of applications like yours hosted by an IoT SaaS. (I work on one.)

So the patterns are (obviously) predictable, but the 'dynamic range' of the load is extremely wide, ranging from stampedes on the cardinal points of the clock face (0/15/30/45 min) to crickets the rest of the time. Some form of elasticity is required unless you are willing to pay for idle servers sized for the episodic peaks.

Thats not really true as generally IoT nodes will manage the traffic they generate to avoid synchronisation with other nodes.

For example, to avoid the 00/15/30/45 issue you offset yourself randomly over a few minutes within that range to avoid overloading mesh & cellular radio networks.

This has a smoothing effect on the traffic as a whole (as seen from the server) which reduces the "dynamic-range" as you're terming it.

> generally IoT

What you propose is one way of doing so. Again, I remind you that an IoT SaaS has multiple tenants and these tenants can't be expected to collectively coordinate. And in certain domains, it is not possible to dictate timing requirements to the client tenant and thus enforce the (SaaS) providers traffic requirements.

I don't know the specifics of your architecture, but if your (multiple) tenant applications are sharing code on the node-side, then it follows that they can self-organise in a similar manner.

Yes.

Specially considering the staggering effect due to predisposition to picking a cardinal direction - 0/15/30/45 minute - in the clock. This is a real issue specially for SaaS offerings in the IoT space.

But if your hosting costs are a round-off on your budget that might not be an issue.

isn't that just a limitation of the current incarnation of serverless systems? ie. serverless is only effective for burst traffic because it's expensive.

You would think that after you tailor the code to the platform and make it stateless, it would cost less for the cloud provider and not more.

If Amazon has to dedicate a full server permanently to your applications, I don't see why it would cost them more or less depending on the statelessness of your application.

Are you sure your assumption that Amazon still has to dedicate a full server permanently to the application is correct?

If you application, due to the requests it receives, consumes enough CPU time to occupy all the cores available in a server and/or most of its RAM, how can they not?

Burst traffic with high writes? --> Use a stream. Burst traffic with high reads? --> Use a cache.

Large compute and memory intense stuff isn't suitable for serverless

What kind of stream do you have in mind? I don’t follow.

Kafka, Kinesis, Cloudwatch events - any light message bus that can decouple a HTTP POST/PUT method that might have a write lock downstream.

I see, thank you.

Exactly. This guy nails it. The serverless paradigm is a managed service, so you are paying extra for that management. Serverless also is built for automated connectivity within the AWS ecosystem, i.e. as a nerve center for all of AWS's nifty gizmos. This is why Amazon places such an emphasis on training certified solutions architects who know what works best for each situation.

Amazon puts emphasis on "certifying" solutions architects to turn them into marketing mouthpieces and AWS proponents.

Source: Seen it happen, am certified.

>The whole idea of serverless is so you don't have to manage infrastructure

Is this even achievable with Lambda though? Even with Lambda, you still have to configure your "infrastructure", just that instead of ELB and EC2, you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed.

All in all, I can't really say Lambda is really all that "easy" considering options like AWS EB/ECS can be setup relatively easily.

> you now have to manage APIGW and Lambda, and any other "wiring" that you need to put in to do what you needed.

You know those url.py files in a django install? Those are the equivalent of ELB/APIGW thing. You don't manage those, you make them once.

Not sure where you personally draw the line between app development and infra work, but for me "request that comes on this path, calls this function", either via ELB -> backend or APIGW -> lambda, or you know, whatever you use for your django app -> a function defined in a view.py, is app, not infra.

For the record, you can easily abstract that away or include it in your own code with frameworks like Chalice [0]

[0] https://github.com/aws/chalice

There are definitely still things you need to think about with Lambda, like how much memory you want to allocate etc.

Agreed, let me add my 2cts :

>The whole idea of serverless is so you don't have to manage infrastructure.

...when you are validating your product/market (100 request/day is a success here).

Not everyone on HN is a core dev, tech is getting democratised. So 1 week of time dealing with servers and accounts and infra is a week not asking the right questions.

It really depends what you're doing. I've been trying out serverless on-and-off for weeks now and still don't have a basic two tier application going the way I want. I'd have been substantially better off dropping $5/month on a DigitalOcean droplet and running PostgreSQL and Rails on it. DigitalOcean even has really helpful templates to start up basic servers.

This may be a specific criticism of AWS Amplify, but all I've been doing is trading off some arcane knowledge in open source software for arcane knowledge in some vendor-specific system. Most of my time has been spent searching for answers to Amazon-specific issues that haven't been solved in any of their SDKs. Or I wind up walking through their SDK code trying to figure out how to metaprogram my way around it.

Perhaps if I used the web UI to stand everything up, it would have gone a lot smoother. I'll admit I'm a sucker for infrastructure as code. But, as it stands, I can't see how this really saves anyone any time. It's still an incredibly manual process without much in way of help or support the moment you veer off the one path Amazon has decided you should be on.

(To make things more concrete, I still don't have Cognito working with optional TOTP 2FA. The withAuthenticator component apparently only renders the TOTP setup if 2FA is required. I've spent hours trying to work this one out, including spending time on the Amplify Gitter channel.)

> DigitalOcean even has really helpful templates to start up basic servers.

> I'll admit I'm a sucker for infrastructure as code.

... which you have to maintain, which probably means Ansible/Chef/Puppet/Salt/etc scripts. Which is fine, it's just a trade-off. I've spent weeks maintaining those kinds of things though, and inevitably when you come back in a year, something's broken.

CloudFormation isn't great, but it usually gets the things provisioned - CF Cognito support sucks though, and haven't been impressed with Cognito at all. Seems too enterprise-y. Like e.g. CodeBuild, which supports 0 open-source use-cases. IDK what some of those teams are doing, but even Azure Pipelines is years ahead.

I think that's a general problem with AWS at the moment. Too many sub-par offerings. Still worth it for S3, DynamoDB, SQS, and Lambda or EC2 (just, the EC2 UX is awful). And those are huge time savers.

I guess my point is I'm going to have to maintain something, it's more useful for me to know how to maintain a PostgreSQL installation than it is some custom Amazon framework or tool. Serverless certainly hasn't been the "fire and forget" system I was sold on. And for just starting up, I can stage an Ubuntu server and set it to auto-update and really not have to touch it for quite a while. I happen to have extensive sysadmin experience and authored a reasonably popular provisioning tool, but I can appreciate not everyone wants to learn it. However, getting AppSync with its Velocity templates talking to DynamoDB and authenticating with Cognito requires quite a bit of knowledge as well. And time spent learning that only benefits you if you never leave the AWS ecosystem.

I suppose I could look at Aurora instead, although Amplify only supports MySQL Aurora, so no luck with Postgres again. Likewise, the price advantage goes away. And now I'm stuck figuring out a wildly convoluted TCO calculator. I could look at another hosted DB solution, but now I either need to move everything to a new provider or find a way to deal with WAN latency for simple DB operations. Moving means learning yet even more otherwise useless knowledge about a single provider.

I'm sure a lot of this is just growing pains. But as a lone dev just poking at something in his spare time, all these "get running in 30 min. or less" tutorials fall apart the moment you try to do something outside that tutorial. And the number of services available, their weird pricing structures, their implicit deficiencies and explicit limitations, just mean I'm still wasting time not building software :-/

Counterpoint to that though: "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc. None of that is particularly "accessible" for someone trying to get running ASAP.

I agree tech is getting democratised, but when talking about products that allows it, I'm thinking of products like Firebase or the recent darklang, not AWS Lambda. From all the Lambda usage that I've encountered so far, they are still very much in the domain of a "sysadmin".

> "Serverless" isn't all that much "easier" to setup compared to traditional server setup. You still need to know how to wireup your request gateway to the correct service, you need to write your app for a serverless setup, setup security groups, etc.

You only have to setup security groups if you are running lambda's in a VPC, which in the simple case (e.g., not running a cloud extension of an internal corporate network) you probably don't.

https://lumigo.io/blog/to-vpc-or-not-to-vpc-in-aws-lambda/

And, yeah, its a lot simpler than a traditional server setup without that. And even with it.

Agreed, AWS lambda is still (very) scary. To me, serverless is more glitch.com [1] than AWS.

When there is is no infra to deal with, U/DevX becomes much easier. "Remix this" is pure product joy

[1]: https://glitch.com/~mapbox-demo

I've found https://github.com/Miserlou/Zappa to be super useful for simple Lambda deployments. It's only for python, but I am pretty sure you have other solutions for node, ruby...

We use http://apex.run/ but mainly because that’s what we started with and it hasn’t given us a reason to look around yet.

I think this is an important consideration that a lot of people miss. One of the trends of both serverless and containers it that compared to older models they are allowing smaller and smaller teams to do bigger and bigger things.

So, in certain respects it's an enabler. Context always matters.

Learning how to setup everything will be too much for you. Use Hostgator and you can start marketing immediately.

If they had used an ALB instead of API Gateway, the cost might well have been a 2x increase, especially given that would replace the ELB they're already using. The ALB option has it's own caveats though...

Yeah, that would have been a much better fit. I just didn't know you could put ALB in front. (Also, a "load balancer" in front of serverless... , and yes I know load balancer do more than load balance.)

I mainly went with API Gateway since that's the default setup the serverless framework uses.

For AWS it was november 2018 when it was annanced. Still a pretty new thing if you ask me. Many Cloud Architects still dont understand all pros and cons of this solution.

One con is that using an application load balancer with lambda restricts you to 1MB requests (and responses?) as opposed to 10 with APIGW. Lambda itself has a 6Mb limit.

One frustrating caveat of the ALB approach is there is a hard 1 MB limit on both the request and response size, while APIGW has a hard 6 MB limit.

The whole idea of serverless is so you don't have to manage infrastructure

That's the selling point of AWS in general, but I wouldn't be surprised if (non-tiny) companies are still spending at least as much on AWS/etc. as they would on in-house infra. That is, they're paying for it anyway, and possibly at a premium.

> I'm in the container camp

Can anyone explain to me why there's "camps" to this debate?

I'd say modern API deployments are either containerised or go the serverless route.

On one hand you have a docker image with your source code/static binary baked in. The other you have your source code/binary encapsulated in a serverless framework (with an Event handler of sorts as your input).

The container doesn't lock you into a particular ecosystem, but hasn't solved how you deploy and run your container (Heroku, managed k8s, AWS ECS/EKS/Fargate). Serverless on the other hand will give you a runtime for your API and allow you to go live (assuming you've setup an account or whatever).

To migrate something that already works to serverless is a bad idea. Maybe if you're pretty comfortable with serverless frameworks and you like to hack a lot of projects up quickly, sure serverless might be a good fit. But why not instead start off with a container? At least you have the flexibility to run that on whatever you damn want - Even a t2.small instance with a docker daemon running.

Heroku gives you a runtime environment also, using Buildpacks. In that respect it's already "Serverless".

What do you mean by "modern"? Expensive and poorly understood?

Because most people with strong opinions aren't experienced enough to justify them from direct experience. Instead we have religions, tribal affiliations, camps.

Docker can also be serverless and gets rid of all the limitations of lambda - Fargate.

I tried using google cloud run, with a rust web server. I think google only counts request processing time and rounds up to the nearest 100ms.

All i had to do was provide a container with a web service that reads a environment variable to listen to a specific port.

I am considering using g cloud run for my next project. How did you like it ?

Too be honest it was really just a small project to get used with Actix web a rust web frame work and to setup a google cloud build ci/cd that would build a container i could host somewhere. I only used cloud run because i saw a youtube suggestion about it xD So there was no load except me and some friends pushing f5 a couple of times.

You can create a web service in whatever language and framework you want, all you need to do is read a PORT environment variable for incoming messages. The freedom was really awesome, instead of being confined to supported languages and frameworks you get in the functions landscape. Only confinement was that you're pretty much limited to HTTP calls, unless that has changed.

Personally i find the freedom of pick your own language and framework a big positive, and billing is finer on cloud run compared to AWS Fargate(rounded up to next sec) if im not mistaken. I do wish they would make billing even more finer instead of rounding up to the next 100 ms, rounding up to the next 10ms would be nicer when you use non GC or Runtimed languages, like Rust.

Fargate is not a replacement for Lambda. While there's some capability overlap, each have their own respective niches.

There is no reason that Fargate can not be a replacement for lambda.

There are three use cases for lambda:

1. Event based triggers where something happens externally that you want to process. You can do the same thing with Fargate by either having a continuously running process that reads from a queue or responds to an API request (AWS Event -> SNS -> API).

2. Timed events. You can do this with Fargate directly (https://aws.amazon.com/about-aws/whats-new/2018/08/aws-farga...)

3. APIs. Fargate supports autoscaling.

Fargate can do anything that lambda can do without the limitations - request and response payload size, a 10GB temporary storage drive instead of a half megabyte, and no 15 minute runtime limit. Of course no cold start times since you can have a minimum number of instances always running without Ping hacks.

Fargate is slow to spin up and can only run 50 simultaneous instances. But they can run "forever" and have much higher memory constraints.

Lambdas relatively fast to spin up and thousands instances can be run at once. But they are time limited running for at most 5 minutes and using 3GB of RAM.

You can do most of the same things with either (after all, they just execute code), but you cannot ignore their very different limitations and that they are conducive to different workloads.

The limit of 50 is a soft limit - you can send a support request to get it raised and they usually respond within a half an hour. Lambda also has a default soft limit of 2000.

But, also you can have up to 4 vCPUs with Fargate as opposed to one with lambda.

And bare-metal servers can do everything Fargate can without limitations.

The point of both is to sacrifice some capabilities in order to remove operational complexity. Lambda just goes farther along that spectrum than Fargate does.

How so? With lambda you give AWS a zip file with your code in it and with Fargate you give AWS a Docker Container. The only difference is that AWS doesn’t support the event triggers with Fargate out of the box.

A docker container is not just your code. It's basically the entire userspace portion of an OS plus your code.

It’s not any more “operationally complex”. The fact that Docker containers include the OS doesn’t make it more complex to run.

My Docker file that I used to convert my Node/Express API that was running in lambda consisted of...

- setting environment variables (I had to do the same thing in my CF template for lambda)

- retrieving the Node Docker image (one line of code - I had to specify one line of code in my CF template with lambda to specify that is was using the Node runtime)

- copying the files from the directory to the container (as opposed to specifying the locsl path of the source code in the CF Template)

- Specifying the Docker Run command (as opposed to specifying the lambda handler).

- running “Docker build” as opposed to “CloudFormation package”.

How it does it is an implementation detail.

In fact, if you use lambda layers, it’s almost equivalent to building Docker images.

There's already serverless where you don't have to do anything with OS/servers/infra: PaaS, like Heroku.

But no, that's not Amazon, so no one cares either way (pro/contra, cheap/expensive, fast/slow, easy/hard) :|

Heroku is not Serverless in the modern definition of the word and doesn’t Heroku run on AWS?

> Heroku is not Serverless in the modern definition of the word

Heroku seems to be serverless in the way cloud vendors, including Amazon, have been using it recently; it's not serverless in the sense that Amazon first introduced it, which was a synonym for Lambda. It's pretty similar to GAE, which is definitely within the current usage of “serverless”.

Heroku is just an easier way to deploy to servers. It doesn’t scale down to zero, scale up as needed, etc. You still have distinct servers that you know about, can manage. S3, Fargate (Docker), DynamoDB, even SNS/SQS are considered Serverless by AWS’s nomenclature.

It doesn't scale to zero, but the article was about how much more it costs running only serverless 0-24, but how hard it is to fiddle with Linux/deployment/CNAMEs/etc. (Especially that they have constant load, 10+M req/day.)

And so it seems to miss the obvious middle ground between raw EC2 (or Elastic Beanstalk managed EC2) and full on-demand Lambda, which is modern managed hosting (PaaS, Deis/Dokku/Heroku).

i'm not sure Fargate is considered Serverless.

“What is Serverless Architecture”

https://aws.amazon.com/lambda/serverless-architectures-learn...

https://aws.amazon.com/fargate/

AWS Fargate is a compute engine for Amazon ECS that allows you to run containers without having to manage servers or clusters. With AWS Fargate, you no longer have to provision, configure, and scale clusters of virtual machines to run containers

Sure, it's not FaaS, but it fits the "you don't have to care for OS and servers" criteria, and it's always on (and auto-scalable).

Running FaaS on AWS without knowing anything about servers and "OS stuff" screams like building the roof without the foundation. And I know that it sounds convenient to run everything as isolated little abstract functions, and ... it works, but it's pricey. But you can do it for cheap, you can deploy Kubless or OpenFaaS (or OpenWhisk or whatever is Apache's equivalent). Naturally AWS exploits this knowledge gap for a lot of their managed services.

It’s not a “knowledge gap”. I know how to set up databases, queueing/messaging servers, software load balancers, etc., but maintenance takes time and companies pay to save time.

That's true. And that's one of the things that a FaaS/PaaS gives you. Heroku's 24 time limit is perfect for eliminating the problems with starting the environment for each request, but still completely absolves the client from doing the grunt OS maintenance.

> I'm in the container camp because serverless isn't cheap and you can't have long running processes.

Do you think you'll have the same opinion in five years time? Or how about three years?

Containers will be around for at least another 5 years.

If you look at where AWS makes most of their money, it's selling EC2 hardware.

Containers have been around for decades in many forms (chroots, vserver ...) and will live for other decades because they are much more resource efficient than VMs while allowing immutable image deployments.

> The whole idea of serverless is so you don't have to manage infrastructure. OS patching, mucking around with Docker and and port fowarding rules are all removed once you go down the serverless route.

If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.

The reasons to use Serverless is the same as everything else in the cloud: 1) fast scaling, 2) sometimes it is cheaper depending on X, and finally 3) you don't have to think about where to run it.

> You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.

You can consider it so theoretically, but for many teams, especially small teams, OS-level systems admin is a different skillset and non-trivial burden that they are glad to pay a premium for, which is why offerings like heroku are successful.

It may work that way for you, but it definitely does not for many many teams.

"You already have to walk to the store, so hiking the appalachian trail is just another part of your walking strategy" -- this is an exageration, the difference between walking to the store and hiking the trail is probably larger than adding OS-level maintenance, but it shows "you already have to do X so doing anything else that I can also call 'X' should be trivial" is a flawed form of analysis, it tells us nothing that you can call all of it "walking" or all of it "patching strategy".

>If this were the reason to use Serverless, it doesn't buy you much. Ports? You set that up once and you're done forever. OS patching? You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy.

This is "you'll always have to do X, so might as well do 10x" argument...

Who would argue that? Why would you ever want to do 10 times something just because you do it once?

Well, the "You already have to manage patches for your app and its libraries, so OS (really container) patching is just another part of your patching strategy." is close to making that argument.

Just because I have to manage patches for 'my app and it's libraries' doesn't mean also handling the OS and everything else that would already be covered by the serverless service is no biggie...

Literally the only other thing to maintain with a Fargate service is what container you run your tasks with. If you have a Nodejs app, use the public Nodejs container. If the container version ends up with a vulnerability, bump the version in the task definition, and do a rolling restart. This isn't some onerous, complex task that only the most cunning sysadmin can fathom. If that alone is what causes somebody to run Serverless I don't think they understand all the other complications that come with it.

>Literally the only other thing to maintain with a Fargate service is what container you run your tasks with. If you have a Nodejs app, use the public Nodejs container. If the container version ends up with a vulnerability, bump the version in the task definition, and do a rolling restart. This isn't some onerous, complex task that only the most cunning sysadmin can fathom

If you're doing a toy demo app, or a website for your local flower shop, yes...

Any non trivial company's systems are not just some random container with a "Nodejs app" inside. They need to keep state, handle caching, redundancy, global CDNs, and lots of other layers.

You either build all those and full ops on top of containers (or whatever), or you get them off the selves and ready to play with a serveless service and their state solution, plug-and-play ready-to-use caching layer, and so on...

Maybe I'm not patching correctly, but I never found keeping an LTS OS up to date to add a significant amount of work over keeping frameworks up to date, let alone 10x.

Reply on news.ycombinator.com