Hacker News Reader

Comment by ezekiel11 | Hacker News Reader

serverless environments do not carry the devops overhead involved with kubernetes or other container orchestration.

For non-trivial workloads serverless does still require a lot of orchestration and domain knowledge of cloud-specific features and constraints. Kubernetes is for sure its own beast, but its a ton of work regardless (for gains that at the end of the day aren't what you thought they would be...).

Serverless is amazing when you use it the way its intended. Its not there to replace your entire ec2 workload.

your assessment would've been correct 3 or 4 years ago but there's just no need to scaffold ec2, mysql db inside a vpc. You can upload your environment via docker and start serving serverless. You can then use serverless db that is 90% cheaper and far less hassle than scaling up or down ec2 instances/rds, configuring vpc, setting up nat gateways etc

my view is that if you are not on serverless, you are wasting resources that could otherwise been dedicated to building out domain knowledge

our team focuses on optimizing each function and less on devops/scaling. the plumbing work is gone and all we do is now translate business requirements. security concerns are also largely removed.

its a great time to be on serverless, it had to overcome lot of doubt but it is here to stay. no need to pay $5 / month either for your weekend projects. even if your project hits front page, it will still work, the billing is not even that bad for what you are getting.

> serverless db that is 90% cheaper

> building out domain knowledge

What about all the knowledge that is contained in applications, services and libraries that run on RDBMs?

I'm serious, one of the reasons I shy away from serverless is I want to put together components at a higher level than functions. But maybe I'm missing something?

What serverless hosting are you using? What tech stack do you run on it?

> configuring vpc

What advances in Serverless platforms like AWS Lambda prevent the need for configuring VPCs?

I do like me some serverless.

That said, for my own projects I don't go that route because when it is my own money I need the certainty of cost that something like a $10 droplet gives.

I know serverless will be much cheaper (probably almost free) for most likely loads, but if I'm hit with the extremely unlikely loads I'd rather a small droplet that struggles and dies than a performant serverless system that spins up my bill as well as my resources.

How do you configure your serverless environment? I set up my company with ECS a while ago, and in order to get the config into version control I had to put together a somewhat messy collection of bash scripts that use the AWS CLI to push up JSON config files. I couldn't find any standardized way to configure the whole environment: at least at the time, it wasn't possible to do everything in CloudFormation.

I haven't gotten into Kubernetes at all, but from what I've heard the bespoke-bash-scripts problem is largely solved in that world, so I've been toying with exploring it for our next project (still hosted on Fargate).

ECS fargate is a great platform but the API interface to it is pretty bad. It's such a shame.

Terraform or Pulumi? Using CloudFormation or APIs directly is an exercise in frustration IMO.

True, although there is a dev overhead and there are other issues (cold starts, unpredictable bills, zero control of the runtime, vendor lock-in, etc).

Serverless is not a silver bullet.

As a person running a service, I only care about fairness of resource allocation if my service isn’t getting at least its fair share. As an ops person, you know that if I am not getting my fair share it’s because someone else is misbehaving. As a functioning adult, you understand that if you are getting more that you should, it’s coming at someone else’s expense. Because fairness isn’t being enforced.

A lot of complexity we add to these systems is about fairness. Fair is always about narrowing the gap between best and worst case run times and trying to keep the result close to expectations, and being able to defend it when they don’t match.

coldstarts - not an issue anymore

unpredictable billing - this is why you setup billing alerts and not an issue unless you hit HN front page

vendor lock in - you can take your functions and upload it to google, azure, cloudflare

This is why I hate articles that justify the lack of scalability with their execuses to justify complacency.

Reply on news.ycombinator.com