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

Serverless Architectures

martinfowler.com

Post reply on HN
Print view View original

131–140 of 149 posts

Re: Serverless Architectures

#131

Post by nickbauman »

osipov wrote: post #81
stickfigure wrote: post #77

By this definition, we've been running "serverless" on Google App Engine for most of a decade. * We don't monitor how many instances are running and don't really care. Our "functions" are http endpoints. GAE spins up or down instances to meet the load. Our interface with "instances" is just the size of the bill at the end of the month. * Async task processing is also just an http endpoint function. We even have a lit…

If GAE has had "serverless" for most of a decade, then why did Google decide to create Google Cloud Functions? https://cloud.google.com/functions/docs/

Cloud Functions are just the functions. Gae is that and more.

Re: Serverless Architectures

#132

Post by nickbauman »

vikeri wrote: post #124
hassy wrote: post #105

Earlier quoted context omitted.

Because Lambda/Cloud functions are meant for scripting tasks in your cloud environment, not for building full-fledged apps. (Lambdas couldn't even be triggered with HTTP calls when AWS Lambda launched.)

I spoke to a solutions architect on AWS who said that their recommendation for building a new backend service (eg. a REST API) is to use API gateway and Lambda. I definitely got the impression that he meant full-fledged apps.

I did this. AppEngine is a far more cohesive and polished service than cobbling together Lambda, S3, API Gateway, SQS and Dynamo (which you'd need to do to actually have a fully functioning site).

Re: Serverless Architectures

#133

Post by SideburnsOfDoom »

solipsism wrote: post #69
SideburnsOfDoom wrote: post #61

Earlier quoted context omitted.

Why would a lambda fn be considered untrusted client code? If the database and the lamdba fn are both in AWS, then they're on the same "server estate". How is this any different from the server portion a web app?

This is something that annoys me about relative terms like "client" and "backend". An entity can simultaneously be the client of one pair and the server of another. No good solution comes to mind, aside from being very explicit. "database client" vs "user client".

Indeed, this was a very confusing conversation because of it.

If by client you mean "a web browser" then "a better approach is where there's code between the client and the database" makes perfect sense; but in the meaning of "client" where any code that calls the database is a client of the database, it's balderdash.

I honestly don't think that a "trust boundary" has anything to do with it, generally.

Re: Serverless Architectures

#135

Post by zippergz »

vikeri wrote: post #124
hassy wrote: post #105

Earlier quoted context omitted.

Because Lambda/Cloud functions are meant for scripting tasks in your cloud environment, not for building full-fledged apps. (Lambdas couldn't even be triggered with HTTP calls when AWS Lambda launched.)

I spoke to a solutions architect on AWS who said that their recommendation for building a new backend service (eg. a REST API) is to use API gateway and Lambda. I definitely got the impression that he meant full-fledged apps.

I have done some (small-ish) projects with API Gateway and Lambda. Lambda itself is pretty nice. The API Gateway is a pain, and has a lot of rough edges. Especially if you need to do anything other than standard JSON in and out. I’ve spent way more time than I’d like to admit futzing with mapping templates and models to try to get stuff to work the right way. And then dealing with errors from the Lambda function in a sensible way is a headache all its own.

I generally really like AWS and I use it for a ton of stuff, but I very much welcome competition and innovation in this space.

Re: Serverless Architectures

#137

Post by takeda »

tianlins wrote: post #96
stickfigure wrote: post #77

By this definition, we've been running "serverless" on Google App Engine for most of a decade. * We don't monitor how many instances are running and don't really care. Our "functions" are http endpoints. GAE spins up or down instances to meet the load. Our interface with "instances" is just the size of the bill at the end of the month. * Async task processing is also just an http endpoint function. We even have a lit…

I think one difference is that for many languages like Python, the http endpoints are hosted in one process. That's less horizontally scalable than lambda services.

I'm not sure where you got this from. There's nothing inherent in WSGI that prevents you from spawning multiple threads and processes. I'm unaware of WSGI implementation that does not do this. uWSGI even shows how to do this even in their quickstart [1].

Having said that, this is actually irrelevant when trying to scale out. There's nothing that prevents you from starting your application multiple times each copy on a different machine. As long as your application is stateless (which is a requirement no matter which language you use). I don't think there's any programing language which prevents you from doing that.

[1] http://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.ht...

Re: Serverless Architectures

#138

Post by madeofpalk »

hassy wrote: post #105
osipov wrote: post #81

Earlier quoted context omitted.

If GAE has had "serverless" for most of a decade, then why did Google decide to create Google Cloud Functions? https://cloud.google.com/functions/docs/

Because Lambda/Cloud functions are meant for scripting tasks in your cloud environment, not for building full-fledged apps. (Lambdas couldn't even be triggered with HTTP calls when AWS Lambda launched.)

Yes.

I'm a massive fan of AWS Lambda, but using it to serve public API quests is just a nightmare. Just because you _can_ do something, doesn't mean you should.

I'm constantly puzzled by why people use Lambda for this - if you don't want to deal with managing traditional services, there's plenty of other options out there (in AWS and otherwise) that are much more suited to the task of serving a website.

Re: Serverless Architectures

#139

Post by MichaelMoser123 »

So the web page now has to contact a lot of servers. That means more round trips and worse security - more endpoints means a bigger surface for attacks. Also you know what data is on what server - you just have to inspect the javascript source code. Is this a good idea?

Re: Serverless Architectures

#140

Post by Illniyar »

stickfigure wrote: post #77

By this definition, we've been running "serverless" on Google App Engine for most of a decade. * We don't monitor how many instances are running and don't really care. Our "functions" are http endpoints. GAE spins up or down instances to meet the load. Our interface with "instances" is just the size of the bill at the end of the month. * Async task processing is also just an http endpoint function. We even have a lit…

If you are referring to the definition of "FAAS" as described in the article, then no, GAE is not serverless (or FAAS) because it is not stateless (though you may use it as such) it can keep things in memory, such as a local sesion cache (from what I recall), though you probably shouldnt rely on it as such.
Post reply on HN