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

Guide to Serverless Architecture

simform.com

Post reply on HN
Print view View original

81–90 of 105 posts

Re: Guide to Serverless Architecture

#81

Post by alpha_squared »

icebraining wrote: post #68
rdsubhas wrote: post #48

Earlier quoted context omitted.

> The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. There is another way of looking at it: Pay for a percentage of the traffic, irrespective of how fast your application runs or what your budget is. If you reach your monthly budget because of one hacker news trending article, yeah, then no more traffic for you. It can be insane. If I have autoscalin…

I don't know if platforms already support it, but there's no reason why you can't have a throttle (calls/minute).

I can't speak for all serverless platforms, but AWS API Gateway does support throttling and burst throttling[0].

[0] http://docs.aws.amazon.com/apigateway/latest/developerguide/...

Re: Guide to Serverless Architecture

#82

Post by Dawny33 »

cle wrote: post #73
Dawny33 wrote: post #10

> grouping a bundle of functions together behind an API gateway, you’ve created a microservice Always beats me why people don't warn the readers about the almost impossible nature of logging and monitoring such systems :/

How is it impossible? My team and I have built and maintain quite a large serverless system--logging and monitoring have been the easy parts.

We do monitor too. We made a Master-Worker architecture which scales according to the data traffic. (Talked abt it in Velocity Conf. London this year)

One way is we monitor the Ansible tasks which make this happen. Apart from that, there is no way we can do it.

+ trying to make it happen by using something like a Prometheus+Grafana server would defeat the entire purpose of going serverless

Re: Guide to Serverless Architecture

#83

Post by Dawny33 »

andre-m wrote: post #76
Dawny33 wrote: post #10

> grouping a bundle of functions together behind an API gateway, you’ve created a microservice Always beats me why people don't warn the readers about the almost impossible nature of logging and monitoring such systems :/

Do you mind expanding on that? With APIG+Lambda you get CloudWatch integration 'out-of-the-box', and can expand the metrics and logs you send out with a few added lines of config. You can also toggle X-Ray for a detailed view of your call graph. If the default implementation isn't good enough, you can define your own CW events, alarms, and log filtering. I'll grant you that you can't just ssh into a host and tail som…

Yeah. I was talking about the serverless systems which are distributed in nature, which means a huge master-workers architecture.

Re: Guide to Serverless Architecture

#84

Post by Vinnl »

sudhirj wrote: post #75
Vinnl wrote: post #56

Earlier quoted context omitted.

I didn't really feel like the benefits of packages like Serverless and Apex were worth it for me, as they're not solving that big of a problem, and you'd replace it with lock-in to even less mature products. That said, the current lock-in is not that bad, just good to be aware of and keep an eye on. I hope that the annoyances are temporary indeed, but that doesn't buy me anything today :) That said, I think for almos…

Up != Apex, same developer, though. Apex embraces serverless as an architecture, Up runs regular servers as functions.

Oh, oops, didn't scan close enough. But in any case, I don't want to be writing "regular servers", I want to write FaaS functions. Ideally (and hopefully this is where we will end up), against the same interface regardless of provider, but not necessarily e.g. Express's interface.

Thanks for sharing though, it's surely useful to some.

Re: Guide to Serverless Architecture

#85

Post by alpha_squared »

blowski wrote: post #40
methodin wrote: post #30

Earlier quoted context omitted.

And a huge plus - not having to pay if nothing is using it (generally).

The downside being that you pay a lot more if it gets used a lot.

Which is probably when you need to re-architect, anyway. There are also several optimizations that can be made along the way to reduce costs. I think there are plenty of ways to think of problems from a serverless standpoint that really don't need to go the traditional server route. I also think there are plenty of use cases where serverless may very well be a problem, that's okay.

Re: Guide to Serverless Architecture

#86

Post by icebraining »

debaserab2 wrote: post #78
dschep wrote: post #38

Earlier quoted context omitted.

> - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. The post isn't loading so I don't know exactly what it's in reference to (AWS lambda, the framework, the more generic idea?). But, the serverless framework[0] supports all major cloud providers (AWS, Google, & Azure) as well as self-hostable options like OpenWhisk and Kubeless. [0] https://…

I may be naive (or just witless), but don’t you kind of end up with vendor lock-in to serverless itself? The first step in their example is “login to your serverless account”.

Maybe the image is outdated? The Quick Start doesn't seem to talk about Serverless accounts.

Re: Guide to Serverless Architecture

#87

Post by not_kurt_godel »

emj wrote: post #15
not_kurt_godel wrote: post #11

Earlier quoted context omitted.

> CGI scripts with a new name "Electric lightbulbs: candles with a new name"

Back when we only had shared hosting or bare metal there where some pretty good CGI hosters. So a better comparision is compact fluorescent lamp: incandescent light bulb with a new name, CFL are clumsy and expensive for many things but a cheap and easy way to use less energy. I'm waiting for the LED version.

Would those hosters scale up to serve arbitrary amounts of traffic? Would they automatically replace hosts that failed? Could they seamlessly integrate with systems that can store and query unlimited amounts of data? Did they have a system like API Gateway to put your CGI scripts behind? Did they have deployment systems that would set up all of the above and more with a single command, like Serverless? Also are you aware that Lambda is exceedingly cheap?

Re: Guide to Serverless Architecture

#88

Post by wahnfrieden »

rdsubhas wrote: post #48
wahnfrieden wrote: post #18

Earlier quoted context omitted.

The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog. Interestingly lambda seems to make async IO t…

> The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. There is another way of looking at it: Pay for a percentage of the traffic, irrespective of how fast your application runs or what your budget is. If you reach your monthly budget because of one hacker news trending article, yeah, then no more traffic for you. It can be insane. If I have autoscalin…

You’re looking for throttling which you can do with Lambda/API Gateway.

If you don’t have spikiness in your traffic and provisioning for peak capacity is affordable and simple, then serverless is a bit less compelling.

Re: Guide to Serverless Architecture

#89

Post by wahnfrieden »

bpicolo wrote: post #37
wahnfrieden wrote: post #18

Earlier quoted context omitted.

The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog. Interestingly lambda seems to make async IO t…

Which will never accumulate a backlog because it is happy to kill your task. ;)

Still need to use a dead letter queue, yes :)

Re: Guide to Serverless Architecture

#90

Post by wahnfrieden »

k__ wrote: post #27
wahnfrieden wrote: post #18

Earlier quoted context omitted.

The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog. Interestingly lambda seems to make async IO t…

What are good alternatives to nodejs that are better suited for this kind of architecture?

It’s more that you’re dealing with a different set of constraints on which to evaluate technologies. There’s not an overall better suited technology than nodejs - still good reasons to use it on Lambda.

To make the most of Lambda though you’ll want something that affords small code size (as there’s a 50MB limit), and has fast single execution latency.

Post reply on HN