Live data from Hacker News

Serverless: I'm a Big Kid Now

simplethread.com

51–60 of 71 posts

Re: Serverless: I'm a Big Kid Now

#51

> Nobody wants to manage servers. Managing servers is a nasty side effect of wanting to execute code. Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app. You know how I would replace all that stuff? 1 single VM. (Alright, maybe 2, 1 for the database.) A server buys you ea…

It's not just "1 single VM" though, as you'll have to configure the applications on top of that. Configuring/installing a Postgres instance on a VM, nginx for your load balancers, iptables for your firewall, user accounts, an application server (could be as simple as forever for a NodeJS app, or Gunicorn or something for Python, etc). And if you want to automate that (as it sounds like you do), you're still writing a…

You don't have to throw out the baby with the bathwater. You can still use AWS firewall, RDS, S3 and ELB with a VM/EC2 instance.

Re: Serverless: I'm a Big Kid Now

#52
post #18
post #14

Earlier quoted context omitted.

I don’t dispute that serverless deployments are a mess. But I look at it the other way: they make you deal with scaling up front, whether you need it or not. RDS, S3, all that... it scales to huge volumes. Your single VM will not. You can set up auto scaling with multiple VMs but by that point you’re going to be dealing with a lot of the issues you have with serverless deployments. Now, could a lot of serverless depl…

Right, I’m a big fan of the monolith, but that doesn’t preclude anything you just described. Absolutely use RDS. Absolutely use S3. Even on a low traffic app. But what I see a lot of is engineering teams making sweeping consistency judgements. RDS and S3 are great as services, everything should be a (micro)service. Our calendar feels amazing as a React SPA—everything should be built in React. No. 90% of a product is…

This right here. As a less experienced engineer in the past I once made the unfortunate call to go all in on a JavaScript SPA to replace the simple server rendered rails views because it was “correct” and we should have “modern” code.

It’s been many years since then and all this really did was bloat the client with metric tons of business logic, punch inconsistent holes through the API layer, and cause the entire web product to have abysmal load times (normal is somewhere in the 5 second range IIRC).

I think it’s understated how much damage the young technical leaders typically employed by early stage startups can really do. I can tell you this because I was exactly this person, and I got to see what following hype without doing actual mature research leads to.

Re: Serverless: I'm a Big Kid Now

#53
post #37
post #30

I feel we need to move beyond the "serverless" nomenclature. Although, what would be better? Remote Lambdas ?

Lambda is a "Function as a Service" product and FaaS is (usually) serverless in nature. S3, DynamoDB, AppSync, API-Gateway, and Faregate are also serverless, but not FaaS products.

[deleted]

Re: Serverless: I'm a Big Kid Now

#54

One thing that bothers me about serverless functions is that there is virtually no concurrency. Once you return you have no assurance that your code will keep on working. If you want to perform actions that might be throttled (cloudwatch for example) and are not critical for the response, you cannot have a singleton processing them after you return, because they might not be processed.

How could it be orchestrated by the cloud if there's no clear end to your workload?

Re: Serverless: I'm a Big Kid Now

#55
post #29

Is it really that expensive to keep a server running 24/7 vis a vis the development complexity of lambdas? It depends on your work load. And your trust level in Amazon of course.

No it isn't expensive to keep a server running 24/7. It's expensive to keep that server maintained.

Updating a typical linux server can seem daunting, but it is not complex. For example to update a centos linux system:

rpm -qa | grep -i kernel && yum -y update && reboot && ..... After system comes back online, ensure the kernel is a newer version rpm -qa | grep -i kernel

Other utilities like ukuu for debian or ubuntu systems make updating the kernel a breeze.

If you're worried about specific packages, sure that can be daunting, so avoid updating software you are concerned about breaking ( keep an eye on security alerts for that software, which you should be doing anyway if you are using it on a VM container, or serverless... none are immune to vulnerabilities! ) and do not install unnecessary software.

Re: Serverless: I'm a Big Kid Now

#56

> Nobody wants to manage servers. Managing servers is a nasty side effect of wanting to execute code. Actually, I am setting up a serverless app now. 4-5 lambdas, s3 buckets, RDS, IAM roles, and 6 weeks (easily) getting everything into CFT's and Ansible so that I can deploy this relatively small app. You know how I would replace all that stuff? 1 single VM. (Alright, maybe 2, 1 for the database.) A server buys you ea…

This.

I now work in a company where they do things themselves, bare metal, and use ansible, ssh, etc pretty much basic stuffs.

I like this way more than my AWS/kubernetes insanity that my previous company had. It was so hard to debug, and everything needs a ticket.

Re: Serverless: I'm a Big Kid Now

#57
> Nobody wants to manage servers. Managing servers is a nasty side effect of wanting to execute code.

I'll take issue with this one. I'm fully aware I'm weird, but I do actually enjoy managing servers. And with that effort spent managing servers, I buy the ability to actually create the environment in which my code runs, and interact and improve it over time, rather than relying on someone else's idea of what's good for my code. Moreover, I get the ability to dictate the security environment in which my code runs, instead of hoping my cloud provider is doing it properly enough for me (and not busy snooping on what I'm doing in the process).

I think what the poster means is "I don't want to manage servers, I want to write code." Which: fine. The world needs people who focus on writing good code. But I'm sick and tired of this attitude that coding is somehow more noble or better than the important work of building and maintaining the environment in which the code runs. You don't like it? Awesome, don't do it. But stop spitting on people who do, and who legitimately enjoy doing it.

Re: Serverless: I'm a Big Kid Now

#58

Earlier quoted context omitted.

> 23 microservices he had carved up out of a Java Spring app. A small change anywhere in the code meant he had to redeploy all of it, Those aren't microservices, by definition.

> not because of how the code was structured but that was the only way the build tools allowed him to do it Pretty sure that's the point OP was trying to make - they put in the effort to build microservices, and crappy tooling means they are instead stuck with an mangled over-engineered monolith

Microservices are by definition stand-alone, independent, and self-contained. That's the whole point of microservices, and one of the reasons why people tolerate the pain that goes with a distributed system.

If your application does not meet any of those requirements then call it something else, as it clearly isn't a microservice.

Re: Serverless: I'm a Big Kid Now

#59
post #29

Is it really that expensive to keep a server running 24/7 vis a vis the development complexity of lambdas? It depends on your work load. And your trust level in Amazon of course.

No it isn't expensive to keep a server running 24/7. It's expensive to keep that server maintained.

Not really. We have about 20 servers. We spend around one person-day per month maintaining them.

Re: Serverless: I'm a Big Kid Now

#60
post #10

> Serverless container services such as Heroku, Netlify, AWS ECS/EKS Fargate, Google Kubernetes Engine, and Azure Kubernetes Service IMO I don't think Heroku and others fit the serverless paradigm. To me serverless is about automatic scaling of performance and cost. With Heroku you need to provision capacity in advance, and you pay for it whether you use it or not. Heroku doesn't scale automatically either, you do th…

Heroku does have autoscale capabilities based on avg response time. You set a min and max dyno count and off you go. It's as simple as it sounds but for run of the mill, follow-the-daytime apps it works.
Post reply on HN