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

101–110 of 149 posts

Re: Serverless Architectures

#101

Post by jedberg »

joefkelley wrote: post #99

The one thing I haven't seen discussed in the serverless world is state as optimization. For instance, if I have a machine learning application that has to access a very large trained model, I would like to load that model into memory at application startup. Loading from disk at every "function call" would be too slow. So would making RPC calls to some external "model cache" service. Does AWS Lambda / similar have so…

That would be a case where you wouldn't want to use a purely serverless model. You'd want a persistent server that loads the data and then exposes it as an API for your other serverless functions.

That being said, it's important to remember that Lambda doesn't reload your function for every function call. It loads it on the first call and then keeps it active for a few minutes as long as there are still requests coming in, so you'd only have to deal with that initial load once in a while (or almost never if your function is active enough).

Unless you had a way of extracting your model into a very fast database.

Re: Serverless Architectures

#102

Post by icebraining »

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.

Why? Production-ready application servers like uwsgi can run multiple processes and distribute requests between them.

Re: Serverless Architectures

#103

Post by mikegerwitz »

pmoriarty wrote: post #72
mikegerwitz wrote: post #50

There are a number of things I find alarming about this (which is nothing new): Firstly, the author is encouraging the conversion of traditional web pages to single-page web applications, which means that users would now have to download actual software to use the website rather than using the software that they already have and trust: their web browser. Perhaps most alarming is the acknowledgement of this: > One of…

"the author is encouraging the conversion of traditional web pages to single-page web applications, which means that users would now have to download actual software to use the website rather than using the software that they already have and trust: their web browser." You mean sort of like every web page that uses javascript? I agree, that is alarming. Unfortunately, the horse on that has long ago run out of that st…

> You mean sort of like every web page that uses javascript?

Some web pages can still function okay without JavaScript enabled, or you can find a way to work around it. Maybe there's even a Greasemonkey script for it.

But it's increasingly more difficult.

> Unfortunately, the horse on that has long ago run out of that stable, and most people don't seeem to care.

As is the case with many things, but the fight doesn't end there.

Re: Serverless Architectures

#104

Post by beat »

falcolas wrote: post #60
osipov wrote: post #52

Earlier quoted context omitted.

>They are not always terminated, in an effort to avoid cold boot startup times. That's true. I should have pointed out that from the developer's point of view it appears as if the execution is terminated, in the sense that no state is carried across code executions. However, the issue of whether the code is cold booted or not is an implementation detail of a specific serverless platform. Atlassian did a nice blog pos…

Any code written in a common web framework (such as Django, Rails, or Play) could easily be written with the same constraints - no state left over from request to request. That we typically choose to retain state between requests as an optimization speaks of one of the weaknesses in serverless architecture. If you can't maintain state inside the application, you need to maintain it elsewhere (DB, Redis, memcache), an…

That's a part of Twelve Factor apps as well. No state in the app! And while there is a cost to keeping state in an external data store like Redis, there are costs to keeping state in the app as well. First, there is the question of complexity and testability. Your app becomes harder to reason about, harder to test, and much more likely to be dependent on complex integration to get to a testable state. Second, there's the need for external support for internal state in any horizontally scaled app. This can be very expensive.

Consider session state in a web app. If you keep state in memory and scale horizontally, you need session affinity, so stateless inbound http connections hit the same server instance. That means a session-aware router, delicate and extremely expensive F5s and other "smart" routers. But if the app is stateless and session state is in external storage, then all you need for load balancing is a simple round robin. A cheap router, that's more reliable and requires less administration, for a fraction of the cost.

There are other ways stateful apps are expensive, but that's a big one. I'd rather pay $5k than $100k for a router.

Re: Serverless Architectures

#105

Post by hassy »

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/

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

Re: Serverless Architectures

#106

Post by api »

Trouble is most of these are completely single vendor and closed. If you build your app for Lambda, theoretically you've built it to run on one computer: the AWS lambda "main frame."

Re: Serverless Architectures

#107

Post by la6470 »

Can you start a webserver in a serverless environment? No not yet !!! if you need a webserver go for a container... oops now we are entering the realm of servers... oh no i dont want to manage a webserver cries the developer. So bring up the most humongous webserver you can find on earth and tell them you just put your app here and rest is MAGIC!!

Re: Serverless Architectures

#108

Post by jaegerpicker »

icebraining wrote: post #68
andreasklinger wrote: post #25

Earlier quoted context omitted.

Might get this wrong but from my understanding: PaaS: Platform (as in Server eg used for API) on demand (as in api.something.com/*) FaaS: Function (as in eg api endpoint) on demand (as in api.something.com/v1/get_latest_posts) Of course you can create the 2nd with the approaches of the 1st but the from my understanding the main benefit is that you dont have to - as in: you can just take one endpoint and have it manag…

Yes, you could simply upload some code to the service, and they will be called only when there's a request to that particular code, instead of running a process continuously. It's called "shared hosting" and was invented in the 90s.

It's fundamentally different than that. This is a discreet function as a single function call that is deployed with no other code that you have written. This allows deployments of individual functions without affecting the rest of the services. While possible before almost noone actually did that.

Re: Serverless Architectures

#109

Post by jaegerpicker »

api wrote: post #106

Trouble is most of these are completely single vendor and closed. If you build your app for Lambda, theoretically you've built it to run on one computer: the AWS lambda "main frame."

That's not really true. Lambda apps are just a collection of node.js modules that are defined at the function level. I can and have easily port a Lambda app to a node.js express app, infact I did so for a Lambda app that was non-trivial (400 functions defined) in about half a day.

Re: Serverless Architectures

#110

Post by icebraining »

jaegerpicker wrote: post #108
icebraining wrote: post #68

Earlier quoted context omitted.

Yes, you could simply upload some code to the service, and they will be called only when there's a request to that particular code, instead of running a process continuously. It's called "shared hosting" and was invented in the 90s.

It's fundamentally different than that. This is a discreet function as a single function call that is deployed with no other code that you have written. This allows deployments of individual functions without affecting the rest of the services. While possible before almost noone actually did that.

I disagree, it was a common pattern to have a single .php file for each page, independent from each other, which would receive input params (GET, POST and COOKIE), sometimes connect to the database, and do all the processing inline, outputting the result. The whole file was essentially an implicit function. The appearance of frameworks with a single entrypoint and which load models and controllers and such is fairly recent in the PHP world. When I started writing websites, already in the 2000s, this was how I first learned.
Post reply on HN