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

Going Serverless with AWS Lambda and API Gateway

blog.ryankelly.us

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Going Serverless with AWS Lambda and API Gateway

#51

Post by kuschku »

runako wrote: post #49
kuschku wrote: post #48

Earlier quoted context omitted.

Well, there was a host – they shut down years ago, though – which did it. And there were always the kind of hosts which had no quota, and no fee, but where you’d pay based on how much you wanted to in a given month, but you’d be expected – honor system – to pay more the more you used, with a rough formula how much would be expected from you (but you’d never be terminated).

With business models like those, it's not surprising they are not still around.

Oh, the honor model one is still around. The other one, which actually billed you, isn’t.

Then again, here a lot of things are honor model or volunteer based, and society still works.

Re: Going Serverless with AWS Lambda and API Gateway

#52

Post by bni »

justinhj wrote: post #50
cweagans wrote: post #45

Lambda seems like a neat concept, but is it really worthwhile? Conceptually, an infinitely scalable backend for whatever thing I'm working on sounds great, but in practice, there are some downsides. For instance, your client requests hits the API Gateway, which then initiates another HTTP request to whatever Lambda is supposed to be called, at which point, a container is started to run your code. By this point, you'v…

The idea is that containers are started to support the load of your application. If the load of your application is so low you have zero containers running most of the time you're not the target audience for this kind of service.

If you have zero containers running most of the time, AWS Lambda is attractive because it costs $0 when there is no activity, unlike instances that costs all the time even when idling.

Re: Going Serverless with AWS Lambda and API Gateway

#54

Post by akvadrako »

collyw wrote: post #30
akvadrako wrote: post #21

Earlier quoted context omitted.

In my experience, they are steps towards the future. VM's are now the baseline; containers are better; server-less is even more so; something like Urbit is a step further. However, the level of maturity is reversed. Docker is usable now, but you will run into many quirks and inefficiencies. On top of that, it's not standardised in a meaningful way. Only starting this year would I choose it for a new project. Server-l…

Why do you define containers as better? Server-less even more so?

In my ideal situation, if I write a function, it's immediately usable wherever I want. As long as it's fast, reliable, scalable, inexpensive and all that jazz, I don't want to think about support infrastructure. Doing the infrastructure yourself has no benefit if it's done right - it's not the end goal.

So server-less is closest to that ideal. Containers are better than VMs because they are faster and lighter weight. So much so, that people develop new ways of working that would be cumbersome with VMs.

Re: Going Serverless with AWS Lambda and API Gateway

#55

Post by cweagans »

justinhj wrote: post #50
cweagans wrote: post #45

Lambda seems like a neat concept, but is it really worthwhile? Conceptually, an infinitely scalable backend for whatever thing I'm working on sounds great, but in practice, there are some downsides. For instance, your client requests hits the API Gateway, which then initiates another HTTP request to whatever Lambda is supposed to be called, at which point, a container is started to run your code. By this point, you'v…

The idea is that containers are started to support the load of your application. If the load of your application is so low you have zero containers running most of the time you're not the target audience for this kind of service.

Sure, but even if your traffic is bursty, this would be a problem, no? If one container is already running and you suddenly need ten containers, that delay is still present.

Also, I'm not sure your assertion is accurate. Amazon's entire selling point around Lambda is that you don't pay for the time that your code isn't running, which implies that the service was built around not having code running sometimes. If my code was going to be running all the time anyway, why not just run an EC2 instance?

Post reply on HN