Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless: slower and more expensive

einaregilsson.com

Post reply on HN
Print view View original

181–190 of 733 posts

Re: Serverless: slower and more expensive

#181

Post by k__ »

LunaSea wrote: post #170
k__ wrote: post #161

Earlier quoted context omitted.

I think you are right with your assumption that Docker images that don't resemble the production environment aren't sufficient to test. But isn't the idea of Docker that you can recreate the production environment? If you can't why use Docker in the first place?

You are absolutely right that you could recreate a similar environment to Lambda in Docker. But you would first need to reverse engineer Lambda's environment to discover how it is actually configured and the limits that are set. Even if you did find a way, you would still need to keep it up to date in case AWS decides to update that environment.

At least the Docker image used by AWS SAM CLI is created by AWS.

Also, you compile before packaging, so you dev/CI system already has to be able to compile for Lambda, independenly from testing/debugging with Docker.

Re: Serverless: slower and more expensive

#182

Post by 1337shadow »

tedk-42 wrote: post #154
dunk010 wrote: post #28

Earlier quoted context omitted.

> 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.

Re: Serverless: slower and more expensive

#183

Post by jrochkind1 »

peterwwillis wrote: post #56
tedk-42 wrote: post #12

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 fo…

> 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 con…

> 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".

Re: Serverless: slower and more expensive

#184

Post by dragonelite »

scarface74 wrote: post #119
tedk-42 wrote: post #12

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 fo…

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.

Re: Serverless: slower and more expensive

#185

Post by nirvdrum »

lucasverra wrote: post #15
tedk-42 wrote: post #12

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 fo…

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.)

Re: Serverless: slower and more expensive

#186

Post by jtdev »

TazeTSchnitzel wrote: post #145
LunaSea wrote: post #143

Earlier quoted context omitted.

Lambas are not simple functions because your environment is different in local compared to production. If I run a Node.js function in AWS Lambda, my Node.js version might be different, my dependencies might be different, the OS is different, the filesystem is different, so I or one of my node_modules might be able to write to /tmp but not elsewhere, etc. It's the reason people started using Docker really. If you don'…

It is far too easy to have all the tests pass locally and be completely broken in production for this reason.

As with any compute environment...

Re: Serverless: slower and more expensive

#187

Post by 1337shadow »

deif wrote: post #112
joelthelion wrote: post #31

Earlier quoted context omitted.

Is there any fundamental reason for this, apart from AWS' pricing model? It seems to me that ideally, serverless should scale from extremely small to very big without too many problems.

You're basically hiring an AWS devops position since you don't need to manage anything yourself. Great for the small startup but not so great for the already established enterprise that has some devops guys anyway.

Actually you still need to hire your own AWS DevOps certified engineer: https://aws.amazon.com/fr/certification/certified-devops-eng...

Re: Serverless: slower and more expensive

#188

Post by bluGill »

I'm one person: I cannot make all possible mistakes on my team. Eventually I have to let someone else on my team innovate make those decisions without me second guessing this.

You could also call the above management, and second guessing micromanagement. Even as a senior engineer who has been around a while there is a lot I don't know, and some of that I need to be content to leave to the other engineers to make the mistakes and do the learning not me.

Re: Serverless: slower and more expensive

#189

Post by marvindanig »

tus88 wrote: post #164
cryptica wrote: post #17

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assess…

This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

Not a strawman, nope. Please put the React salesmen on this list of bogus hype as well. It’s all projection and propaganda—zero substance.

Here’s the proof of evil intent behind React, for example:

https://news.ycombinator.com/item?id=20711598

Re: Serverless: slower and more expensive

#190

Post by SQLite »

filleduchaos wrote: post #43
AndrewDucker wrote: post #24

Earlier quoted context omitted.

"Serverless" is "I don't have to provision a server, or worry about where it is, or maintain it, or what OS it's running, or any of the other fiddly details." You define a function, you hand that function to a company, and they make sure it runs when certain conditions are met. You then don't have to worry about the server.

I think the problem is that these terms had meanings before the last five or so years. There are setups that are actually accurately describable as "serverless" - for example, SQLite is called a "serverless database" because it's an embeddable library that just operates off a file as opposed to client-server DBs like Postgres or MySQL.

Yeah. See https://www.sqlite.org/serverless.html
Post reply on HN