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

81–90 of 149 posts

Re: Serverless Architectures

#81

Post by osipov »

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/

Re: Serverless Architectures

#82

Post by Skinney »

jtwaleson wrote: post #30
Skinney wrote: post #23

Earlier quoted context omitted.

Heroku is much slower at resuming on incoming traffic, because it has to boot up a dyno to serve your code. A cold start on Heroku usually takes 30 seconds (for me anyways). A cold start on AWS Lambda takes 2-5 seconds, which the user won't notice on my services because the frontend is served from S3 and rendering is client side. And the way services are coupled to the app is about the same. I've used both Heroku and…

Sure, it's designed to be faster to boot up, but Heroku could optimize their startup time.

Difficult to do. Cold start time is slow on the free plan because they have to start a "server". They don't need to do this with the paid plan, but then again, you're paying for uptime of a server. Serverless don't need to do this.

Re: Serverless Architectures

#83

Post by vgt »

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…

Oh buzzwords...

We've been discussing Google BigQuery as serverless lately. It's a nice succinct way of saying "fully-managed" + "no-ops" + "no resource deployment" + "seamless scaling" + "separation of storage and compute" + "deployed regionally" + etc. Some customers talk about BigQuery as "Data Center is the Database". So these buzzword help describe what BigQuery is and how it is different from other analytics services and technologies.

In any case, if a buzzword helps get across some meaning, sure, go for it. Folks just get carried away :)

(work on BigQuery)

Re: Serverless Architectures

#84

Post by osipov »

gmazza wrote: post #48
osipov wrote: post #42

Earlier quoted context omitted.

That's true, but for a public cloud service, you wouldn't let random people run arbitrary code based purely on inet.d or systemd socket activation.

Why not? RedHat will let you run arbitrary binaries just fine on OpenShift - both long-running/worker/"PaaS" and on-demand/per-request/"FaaS". Obviously this is tightly locked down with cgroups.

How would you modify systemd unit files for each user of your public cloud? How would you manage the sockets once you have more users than sockets on a server?

Re: Serverless Architectures

#85

Post by ewindisch »

loup-vaillant wrote: post #27

What kind of evil genius devised a term that suggests peer-to-peer, to describe something that relies more than ever before on central services and authorities? It feels like "intellectual property" all over again —which suggests the rules used for rival goods can be used for ideas, hence ignoring the difference between moving and copying.

Because the main premise of "serverless" is function-as-a-unit-of-deployment, it's actually quite suited for distributed computing and works quite well in decentralized architectures. Using serverless, it's easier than ever to build "hybrid" clouds constructed of resources both locally and on public clouds (Google, Amazon, Azure, BlueMix, and others).

We can even deploy that code to IoT devices and embed it inside of desktop and mobile apps.

Serverless frees us from lock-in, but it does not have its own state, so it's easy to become locked into various web services. However, it's also easy enough to rely on your services (microservices) for state, avoiding lockin to other IaaS/SaaS products.

Re: Serverless Architectures

#86

Post by ewindisch »

TorKlingberg wrote: post #15

Is Google App Engine an example of serverless? The user does not really think about servers, and the code is mostly written as event handlers. The abstraction is a bit leaky though, and you can tell that there are instances being spun up and down.

FaaS (functions as a serivce) and App Engine are not the same thing. They're both a platform as a service (PaaS), but that's where the similarities end.

The difference is that traditional PaaS like App Engine and Heroku imply a certain amount of lock-in (although this has gotten better over time), whereas Serverless is a more raw compute service that is no more locked-in than, say, EC2.

Re: Serverless Architectures

#87

Post by daxorid »

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/

Functions looks interesting, but only supports node.js. GAE has the advantage that it support multiple language targets.

Re: Serverless Architectures

#88

Post by bpicolo »

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've been using Elastic Beanstalk lately and it's a true pleasure.

Re: Serverless Architectures

#89

Post by vgt »

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/

I think OP's chief argument is that "serverless" is monopolized by AWS Lambda and the like, and probably unfairly.

The answer is that Cloud Functions and AppEngine fulfill different use cases. There's clearly room for both.

Re: Serverless Architectures

#90

Post by epalmer »

bpicolo wrote: post #88
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've been using Elastic Beanstalk lately and it's a true pleasure.

Curious about your use of beanstalk:

I'm considering using beanstalk for a php app but we have content changes that are very frequent. 134 domains (virtual hosts) and maybe 500 pages (the html) change a day.

How do you update the load balanced set of instances when the instances count changes? tks

Post reply on HN