Live data from Hacker News

Going Serverless with AWS Lambda and API Gateway

blog.ryankelly.us

41–50 of 55 posts

Re: Going Serverless with AWS Lambda and API Gateway

#41

How in the world is this considered something new? It was in fact the default mode of operation for small to midscale webhosting that rendered pages dynamically in the dotcom bubble burst era (late 1990-ies). You'd upload your HTTP attached executables to cgi-bin or similar, register other stuff in crontab and usually also got access to a MySQL or PostgreSQL. Some hosters were actually fancy and deploy your stuff on…

Load balancing? Heh, that's a good one.

My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php.

Generally if you were in a shared hosting environment, your DB and webapp lived on the same physical server (Probably a Cobalt RAQ or Netra T1, but maybe a Sun Ultra AXi in an ATX case on a bread rack). Rarely was there any form of multi-host redundancy for a given application. If something broke, you're down while the hosting company swaps disks to a new chassis, and down even longer when the disks die and you need to reproduce the app config/state changes that happened in the 2 days since the last server backup happened.

So yeah. This is a slightly different model.

Re: Going Serverless with AWS Lambda and API Gateway

#42
I recently threw together a benchmark to measure latency with different requests per second and request concurrency. It bypasses API gateway and just calls the lambda directly. The p50 is very close to the minimum latency I can see to US-WEST-2.

https://github.com/spullara/lambdabenchmark

Re: Going Serverless with AWS Lambda and API Gateway

#43
post #2

Are serverless and container based architectures really that popular in the real world, or is it yet another HN bubble? I'm still happy using virtual/cloud servers for anything/everything.

Won't setting up good auto-scaling and deployment procedures result in something just like Lambda, but you had to orchestrate it yourself? It seems like there's a lot to be said for the cost and time savings of having it done for you...

Plus you don't have the cost of running all that infrastructure 24/7 to have the ability to scale or provide proper security.

Re: Going Serverless with AWS Lambda and API Gateway

#44
post #36
post #33

Earlier quoted context omitted.

Are there shared PHP hosts that bill by the request? TFA indicates that is a key difference of serverless, and why it's not shared hosting. The billing model matters to some users as much as the implementation. Serverless is just shared hosting like S3 is just FTP.

There used to be quite a few PHP hosts that billed by the request in the past, so, yes?

I've been writing PHP for almost a decade and I've never come across any PHP hosts that bill by the request. Not explicitly, anyway -- there were always those hosts where if you got over some threshold of traffic and it caused a certain amount of load on the servers, they'd cut you off with no warning/notice. Those hosts suck. Never seen anything like Lambda for PHP, though. Care to share?

Re: Going Serverless with AWS Lambda and API Gateway

#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've added some overhead to every single request, and it's completely impossible to get rid of it because that's how Lambda is designed. Am I off base here? Does it really work like that? If so, what's the performance hit that you've seen compared to running e.g. ExpressJS directly on a VM or bare metal?

Re: Going Serverless with AWS Lambda and API Gateway

#46
post #32

Earlier quoted context omitted.

Here are my opinions from working with both over the last year: Serverless is brand new, and has all the burrs of a freshly cut service. Expect sharp corners, like bizarre documentation and lack of examples. I think it goes without saying that tooling and Best Practices are still immature. In my work (Lambdas) I've found they do well when organizing small pieces of work and event driven systems. They really do talk w…

What are you building that needs to be split up in such a way? And how many people access the system?

> What are you building that needs to be split up in such a way?

"Need" is such a fickle word...

I'm using the Lambdas to build an event sourced system on top of microservices. Because I can hoist so much infrastructure from each service, it makes each service significantly easier to write and manage. This allows the application specific code to change without rewriting the routing/auth(z)/provisioning code along the way. I can even rip out whole services and the others are blissfully unaware.

Because Lambdas are only charged when invoked, it keeps the costs down. RDS is my biggest expense by far, but I'm under a Standard 1X Heroku instance. If you have a service that isn't used much, Lambda's can bring your costs to near-zero. An added benefit is I can be fairly liberal with deployed lambdas because I'm not thinking about machine/hour costs. Multiple staging environments? SURE!

After a little while in the Lambda world, I started to see them as little lightweight workers. They can be told to listen to nearly anything under the AWS umbrella, and AWS is _chatty_. Pair it up with the API gateway and you can build 3rd party integrations. Before I had to set up a TON of infrastructure to have these abilities. It's pretty liberating.

Finally, I feel like the ideas in Serverless are both interesting and not well explored. I hope to share what I've found with others as we chart this new territory.

> And how many people access the system?

I'm not sure about what you mean by people. Users? Developers? I'll answer both.

For now I'm the only developer, but I expect that to change within a year. The local Docker powered dev environment keeps me sane with a simple `docker-compose up -d` to bring it up. The infrastructure hoisting significantly reduces the service's LOC, making them easier to grok. Isolated development environments and very light mocking ease local development and testing. I do pay a penalty when doing integration tests locally, however, but I'm punting that into my staging environment for the moment.

I have some pre-alpha users that are helping me shape the product. I admit at first glance it looks foolish/overkill/wat for my user size. Before Lambda, this architecture _would_ be too complex, and pricing would be prohibitively expensive, for the size of the product as it exists. That's what Lambda (and Serverless in my mind) brings to the table. It leans on Cloud Infrastructure and it's charge-by-use model to bring architectures like microservices to the hobbyist and small businesses. As the tooling and docs improve, I expect it to further blur the lines in "DevOps".

Could you tell I'm a little excited by Serverless/Lambdas?

Re: Going Serverless with AWS Lambda and API Gateway

#47
post #41

How in the world is this considered something new? It was in fact the default mode of operation for small to midscale webhosting that rendered pages dynamically in the dotcom bubble burst era (late 1990-ies). You'd upload your HTTP attached executables to cgi-bin or similar, register other stuff in crontab and usually also got access to a MySQL or PostgreSQL. Some hosters were actually fancy and deploy your stuff on…

Load balancing? Heh, that's a good one. My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php. Generally if you were in a shared hosting environment, your DB and webapp lived on the same physical server (Probably a Cobalt RAQ or Netra T1, but maybe a Sun Ultra AXi in an ATX case on a brea…

> My experience with hosting in the boom consisted of mostly first ip-based, then name-based vhosted Apache, maybe a per-vhost, but often per-system cgi-bin, and if you're lucky, mod_php.

At the core of it this is not so different.

> So yeah. This is a slightly different model.

No, not really. What's changed is our understanding of how to run this kind of infrastructure. And we now have a little bit more sophistication in how we organize process runtime environments (sandboxes, cgroups on Linux, jails on FreeBSD). But if you tear down all the PR and get past the nice decoration it boils down to a glorified shell access.

Back in the boom it sucked because nobody knew then, how to do these things properly.

Re: Going Serverless with AWS Lambda and API Gateway

#48
post #36

Earlier quoted context omitted.

There used to be quite a few PHP hosts that billed by the request in the past, so, yes?

I've been writing PHP for almost a decade and I've never come across any PHP hosts that bill by the request. Not explicitly, anyway -- there were always those hosts where if you got over some threshold of traffic and it caused a certain amount of load on the servers, they'd cut you off with no warning/notice. Those hosts suck. Never seen anything like Lambda for PHP, though. Care to share?

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

Re: Going Serverless with AWS Lambda and API Gateway

#49
post #48

Earlier quoted context omitted.

I've been writing PHP for almost a decade and I've never come across any PHP hosts that bill by the request. Not explicitly, anyway -- there were always those hosts where if you got over some threshold of traffic and it caused a certain amount of load on the servers, they'd cut you off with no warning/notice. Those hosts suck. Never seen anything like Lambda for PHP, though. Care to share?

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.

Re: Going Serverless with AWS Lambda and API Gateway

#50

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.
Post reply on HN