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 little bit of syntactic sugar so it looks like we're just adding functions to a queue.
* We have no ops or devops staff. We just deploy code that implements functions (http endpoints).
* Persistence is also scaled by Google; there's no database server, just an API to read/write data that scales infinitely (or at least, scales with linearly our bill, not limited by the dataset).
It sounds to me like the article is trying to distinguish between "serverless" and PaaS by describing PaaS done poorly. For the longest time, GAE didn't even expose the # of instances servicing your app. They've exposed a lot more of the underlying constructs since, but you can still ignore them unless you're trying to hyperoptimize your bill.
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 :)
There doesn't appear to be a monopoly on "serverless" and the term has been used by many vendors including IBM at the last Serverless Conference[1].
There is definitely room for many kinds apps in the PaaS space, including serverless as well as microservices. OP was arguing that existing platforms like GAE have been supporting serverless and can continue to do so. However, the premise of the serverless computing movement is that newer platforms (e.g. OpenWhisk, Google Cloud Functions, AWS Lambda) are better for running serverless applications than traditional PaaSes (e.g. Heroku, Bluemix, OpenShift)
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.
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.
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).
I'm building a full fledged app. http://blog.improve.ai/ Once there is an Express type framework on top of Lambda and API Gateway, it will be a natural development model.
Here's how Google defines Cloud Functions: "Lightweight Event-based Microservices".
Google Cloud Functions is a lightweight, event-based, asynchronous compute solution that allows you to create small, single-purpose functions that respond to cloud events without the need to manage a server or a runtime environment.
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
Beanstalk doesn't like having more than one virtual host per application/server/load balancer. You can do it but its a lot of custom code to make it work. Beanstalk does do deploys very well though with automatic deploys to a subset of instances, checking they are working, then deploying to a new set of instances. Big fan but it is really designed for one domain per instance set.
Beanstalk handles the load balancing for you and throws a DNS entry in front of it all, as far as I can tell. Works well so far. It's smart and (seems to do) blue/green style deploys for my single app instance atm I believe.
(I'm only running on a single box so far, mostly using it because it made deploying to production and all the annoyances that come with that a breeze).
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.
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.
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.
Unless and until there is a standard for function-as-a-service so you can move your functions between services at a moment's notice, you're very much locked in; and locked in without any guarantees of quality of service.
I am involved daily in precisely an effort to do just this. The differences between the big 3-4 providers is relatively marginal (call arguments and versions of interpreters such as NodeJS). Take it as a plug if you must, but being able to handle the former is one of the goals of https://github.com/iopipe/iopipe.
The version of language runtimes is where the most lock-in will occur, and really, that's kinda marginal, too. Language runtimes should be as stable and standard as, say, the Linux kernel's userland interface. If language runtimes can't deal with this, then they'll fail.
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 main benefits of Serverless FaaS applications is transparent production runtime provisioning, and so open source is not currently as relevant in this world as it is for, say, Docker and containers.
This highlights the major issue of SaaSS/SaaS, and FaaS takes it to the extreme:
Not only does the user not have control (as in the case of SaaS), but in the case of FaaS, the actual author is relinquishing the same control.
These suggestions all "make sense" from an architectural perspective (depending on who you ask, and depending on the software being written). But I plead for others to consider whether this is necessary in their particular instance; it's the default thinking now-a-days: want to write a program? Want a wide audience? Want it to scale? Put it on the Web, make it a service, store it and all user data on someone else's computer, and call it "the cloud".
I expressed my opinions and concerns at LibrePlanet 2016:
Article author here. Don't worry, I'll be laying on some cold, hard, reality later in the series. I definitely don't encourage SPAs universally and I'll be talking extensively about the concerns of handing over responsibility to vendors.
I appreciate you not only explaining it but coming up with two, alternate terms that don't sound so dumb. As in, not calling a centralized architecture "serverless". Your names also fit within context of what people are calling other "N as a Service" schemes.
"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 stable, and most people don't seeem to care.
> 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.
It is misleading that the HN title suggests the author is Martin Fowler, but this is not the case for this guest article. The actual author is Mike Roberts, the article is hosted on Fowler's site.
Here's is my slight change to the bookmarklet code. It's not fool proof and and I'll have to see if it actually results in me editing submitted story headlines less often or not. It basically takes the substring of the document title from the start until it finds the first hypen (-) or pipe (|) which are what seems like most sites use when appending the site name.
VPS (virtual private servers) were available (and largely ignored) for quite a while before 2006, when AWS came along with the catchy word "cloud". This single word changed everything. Same technology all of the sudden became cool, and everybody started using it.
Maybe now it is the turn of PaaS [1] - call it "serverless" and folks finally start seeing all the benefits (true scalability, efficient resource utilization, timely and painless software upgrades, et c.)?
Since serverless is a kind of a PaaS, it offers many of the same benefits. However, unlike Heroku, Cloud Foundry, OpenShift, and other traditional PaaSes focused on supporting long running applications and services, serverless frameworks offer a new kind of a platform for running short lived processes and functions, also called microflows.
The distinction between the long running processes and microflows is subtle but important. When started, long running processes wait for an input, execute some code when an input is received, and then continue waiting. In contrast, microflows are started once an input is received, and are terminated by the platform after the code in the microflow finishes executing. One way to describe microflows is to say that they are reactive, in the sense that they react to the incoming data.
They are not always terminated, in an effort to avoid cold boot startup times. In fact, they run much like any other service framework, where your code is behind a function lookup, and called when an appropriate request is received.
AWS Lambda in particular will spin up a new container running their framework, which will then stay alive for a period of time before being terminated.
With socket activation (using xinitd or systemd) and a minimal framework, you could implement much the same on your own VMs.
>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.
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), and that elsewhere has a cost associated with accessing it.
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.
Diego, the underlying scheduler for Cloud Foundry, has a concept of pre-defined one-off tasks. It'll eventually show up in the rest of the platform.
However, it'll be in the middle of the range for startup times, as some agents are sideloaded. Latency is around a second. The initial target is tasks like database migrations and batch jobs, so the ~1s delay isn't an issue.
One of my colleagues in NYC spiked on using one-off tasks for a FaaS and concluded it's not a slam dunk fit.
If I was to shimmy FaaS-style stuff into Cloud Foundry, I think it'd be easier to have standing apps with an array of functions already running, then push the magic into route services. I suspect this is how AWS already does it, given the vast difference in spinup times between Node and JVM requests -- Node makes hot-patching a list of functions easy, the JVM is less hot-patch friendly and really expects you to provide all the JARs at launch time.
Disclaimer: I work for Pivotal, we donate the majority of engineering to Cloud Foundry.
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?
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 managed by something else.
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.
You don't run the server so I guess you can pretend it doesn't exist.
Kinda like s3... it involves servers, but you don't have to do anything. Its just a black box you put in or get out data. "Serverless" FaaS is just a place you park some code and it runs.
The latest installment just went live - conveniently I offer a comparison to PaaS in it (in that I think there are significant differences between PaaS and FaaS)
Thanks for the article, it was a good read. My problem with the FaaS nomenclature is that it positions serverless as different from PaaS while the two are more alike than different. Now, we need to be careful about the definition of PaaS because there are at least two: 1) PaaS as a cloud computing service model, and 2) PaaS as empirically defined by various PaaSes, like Heroku, Cloud Foundry, OpenShift, etc.
In my opinion, serverless is a kind of a PaaS per definition 1 above. However, in practice serverless is different from PaaS in the definition 2, because Heroku and others have focused on long running services. In contrast, serverless does not replace the need for long running services but works with them. The sweet spot for serverless are short lived, stateless functions, FaaS per your definition. I like to call them microflows to highlight the complementary relationship to the microservices.
The API gateway made me smile. In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing.
There's merit in serverless, no doubt. There are many things that worry me. Not owning the infrastructure means I don't get the telemetry I'd like, making triage difficult. Direct access to the database is a good idea said nobody ever. And at what point does my own infrastructure become more cost-effective than cloud?
Those concerns don't invalidate the applicability or relevance of serverless though. I think its value as a protyping tool, or to validate a proof of concept is huge.
> In the 90's we had message queues. In the 00's we had service busses. Today we have API gateways. All they do is route requests - they're all the same thing.
On AWS, you have options a message queues (SQS), busses (SNS), API gateways, and load balancers (ELB). i.e. many of the existing proven patterns are still around, and you can choose which one is best for the particular circumstance. And that indicates that while they have similarities, they're not exactly the same thing.
I can see cases where a design of "API gateway -> lambda fn -> database" is performant, simple and very cost effective. particularly where the function is very simple and load is low or varies a lot. That won't be everything though.
I don't understand why you think that "Direct access to the database" is always bad. Someone has to access that database directly, on behalf of everyone else who is insulated from it. A lambda fn may not be worse than a web app for that role. But if it is inadvisable, then it can use the same indirect requests that a web app would.
If you give client code access to your database you have to trust that client to respect data types, sizes and, depending on how your database is designed, referential integrity. There's risk of data loss because again, you have to trust the client. There's risk of denial of service in scenarios where the client fills up your database with junk. It's risk all the way down and using it or not is down to probability x impact.
> If you give client code access to your database you have to trust that client to respect ...
I get all that but I still am unsure of what you mean. A database is useless if no-one can ever access it. So some code somewhere accesses that database, not so? And other code makes request to this code?
What do you consider "client code" and what are you comparing this to? Why do you think that lambda functions cannot be in the second category, and if they cannot be, why can't they use the same gated mechanisms as other "client code", and I would assume that they use restful http to read, and http or message queues to write?
> There's risk of denial of service
in the AWS lambda case, the rate limiting is specifically the role of the api gateway. There's always the risk, and I don't think that lambda increases it.
First, "client". A client is anything that calls a server but is outside the trust boundary of that server.
And yes, of course there's code that accesses the database. The problem is that if it's client code, that code must be trusted by the database.
A better approach is where there's code between the client and the database, also on the server (server estate, at least), that verifies data going into and out of the database.
That isolates client-side changes - malicious, unintentional or otherwise, that might impact the data, because there's a server-side gatekeeper.
So all of a sudden FAAS is more appealing than BAAS, and the FAAS API gateway doesn't just do routing, it does validation too. Guess what, you just created an application/business logic layer on a middle tier, and it's no longer serverless.
"...Why do you think that lambda functions cannot be in the second category..."
They can indeed be in the second category. The author, however, specifically calls out direct database access from the client without lambda functions.
> The author, however, specifically calls out direct database access from the client without lambda functions.
Ah sorry, I missed this part:
> 2 Using another example of BaaS, we’ve allowed the client direct access to a subset of our database (for product listings)
"The client" in this sense is a web browser and is thus completely untrustworthy. He seems to be talking about read access, hopefully with an api gateway for auth and rate limiting in front of it. But yes, it is wise to be much more wary of this case.
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.
API Gateway in AWS can't directly talk to the DB. It has to either hit a mock (where a canned response is sent back), a lambda function, or serve as an HTTP proxy. You may of course be referring to the more abstract concept of an API Gateway that then talks to a backend DB directly without passing through intervening code, and yes, that would be stupid. But you hardly need serverless infrastructure to achieve that level of wrongness; even with a server in between, you can easily achieve the equivalent of that by taking a SQL string from the client verbatim and executing it against your DB.
> I get all that but I still am unsure of what you mean.
Direct database access would be like exposing ODBC from the DB directly to a web application. You either have to trust that the application doesn't do a "drop table ..." or hope that the DB has fine-grained enough access controls to prevent that.
Whereas in a SOA design, the API endpoint runs your code that gates access to the DB.
"web application" could mean a number of things. To me "web app" in the comments above meant the code on a server that handles http requests, not the browser client of it. You are talking about Javascript running in the browser of a random internet user, right? It could be catastrophic to allow that level of access to a database from the public web, obviously.
As is pointed out in (1) that can happen already through carelessness. And it does (2)
But it probably isn't what was intended in a newly designed general system. That would assume great stupidity.
I suspect that even the "no code, just access the database" actually has some kind of code and config in front of the db, like odata (3). I'm not saying that odata is great, but it is an example of trivial access to a database. it's gated, mostly read-only and configurable, but it probably doesn't count as "writing a custom server app to gate to a database"
The vast majority of web sites on the internet today don't need much infrastructure, they're low traffic blogs, web sites for the hair salon down the street, or a landing page for a non software corporation. Facebook fills this role for a lot users, and they in turn sacrifice their data and privacy to a souless corporation. Don't forget the $billions dollars industry of shared hosting providers out there. A lot of businesses still pay $10 a month for a shared server, mysql, and php.
Why should this be the case? Why should it cost anything to have an online presence today? Why shouldn't users own their data? In my personal opinion, these types of FAAS (function as a service) and mBAAS (mobile Backend as a service) the article is talking are an enabling technology in this regard.
Even if it costs nothing, Facebook is a far better option for hair salons and other similar small businesses. Facebook drives engagement and views, while nobody will bother with a self hosted website. The oft repeated lesson here is that convenience trumps privacy for the vast majority of users. If you look at the last decade, in spite of there being robust, self-hosted solutions for syndication and engagement such as RSS, pingbacks, OPML etc, in the end closed systems won.
Maybe there is a secret ingredient to making it work again, but we don't know what that is. Yet.
I think the secret sauce may be in things like 'call ahead seating' or 'get in line, online' that some restaurants and hair styling places do now. You don't typical get that capability on facebook, and it's a differentiator.
Thing is, why would a hair salon (which presumably has no advanced technical skills) choose to write or purchase software to run on their FaaS service, instead of simply registering an account on a SaaS service that takes care of everything for them, and even integrates with FB?
FAAS and mBAAS still cost resources, so they still cost money, and someone has to pay for that. If you're hosting a low traffic, mostly static site, I think you're better off paying $18/y on NearlyFreeSpeech (for a dynamic site with a database), where you are actually a client, than relying on the freemium plan from a cloud service for which you are just a prospect.
The direct access to the database no no is being challenged, with new technologies it doesn't imply what it historically has.
If you haven't worked with DynamoDB you should check it out, via IAM roles you can assign fine grained access controls per user down to the row level. All of the authorization is done at the IAM level and you don't have to worry about validation or data integrity if the user is read only.
> And at what point does my own infrastructure become more cost-effective than cloud?
I am no expert at all, but one idea came to mind: say you have this small festival each year (or once) where you have 1 month (or less) you can buy tickets. Instead of setting up, securing, etc a whole server stack you can simply run te ticket-purchase code on a FaaS and have a database with results. Running your single page app all year on a very simple host, but having this database and compute thing only one month.
I think it might have something to do with the fact that the payment model isn't connected to a server instance, but how often your code is run. Heroku, GAE etc. are server-oriented. Your code is running on a dyno or an instance, and you pay based on the number of instance-hours you use. In AWS Lambda, or Azure Functions, you pay for the number of requests you process and the time spent processing those requests, how many instances are spent processing those requests are irrelevant. It's a serverless payment modell.
All the best trying to recover a 'serverless' application when one portion fails; lots of late-night phone-calls and picking-through the terms of SLA documents in that future compunded by the fact that most serverless advocates say that you can dispense with operations staff...
The serverless architecture appears to have many servers provided by different people instead of having no servers, as "serverless" leads me to think. Is this just trading wrangling a server farm for wrangling contracts with 3rd party service providers?
If your PaaS supports scaling down to zero (Heroku free tier, Cloud Foundry somewhere in the future) and resuming on incoming traffic, it's basically a much better version of FaaS. The way you deploy code, the way services are coupled to the app etc is much better.
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 AWS a bit, there really isn't that big a difference here, except that Heroku as a lot more third party services that can be connected.
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.
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.
Depends on what you mean by serverless I guess. GAE (and Heroku for that matter) still has the notion of code running on an instance, dyno, server whatever. When I think of serverless, I think of Azure Functions, AWS Lambda and the like, where the cloud runs a single function in response to a request. How is it run? Doesn't matter, you pay for what you use.
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.
Google promotes Services on Google App Engine to be used in a microservice fashion. If you create a new project and click on Services, they include a link to the docs about microservices. So if we go by that, it seems to be more microservices than serverless. Based off the article, the serverless (FaaS) bit would be Google Cloud Functions.
Terms such as "serverless" don't have a fixed sharp-edged meaning but are very fuzzy categories, except on a per-person basis, where you may (will) find people insisting on a specific meaning. When this story was submitted on some reddit forum (forgot which one) everybody was up in arms after just reading the headline, screaming "everything is a server" and "there is no cloud"! Don't take it too seriously. Human language is very deliberately a very flexible tool, with the same word fitting into very different contexts, taking on very different roles. Even in science, by the way.
> This has a huge impact on application architecture, albeit not a unique one - the ‘Twelve-Factor App’ concept has precisely the same restriction.
While 12 Factor does say that processes should be stateless I've never thought it really meant it. Connection Pools and in-memory caches are pretty typical in 12 Factor (or all non-serverless) apps. And for me that is what makes serverless kinda silly. Some global state is actually pretty useful when you can avoid the overhead of initializing things or going over the network.
Serverless apps should be stateless but should work in conjunction with stateful apps. Unlike Heroku, Cloud Foundry, OpenShift, and other traditional PaaSes focused on supporting long running applications and services, serverless frameworks offer a new kind of a platform for running short lived processes and functions, also called microflows.
The distinction between the long running processes and microflows is subtle but important. When started, long running processes wait for an input, execute some code when an input is received, and then continue waiting. In contrast, microflows are started once an input is received, and are terminated by the platform after the code in the microflow finishes executing. One way to describe microflows is to say that they are reactive, in the sense that they react to the incoming data.
But how is this different from coding in, say, Django?
In Django you write a "view", which is just a Python function that is started when an HTTP request is received, and terminates by returning an HTTP response object. Then there are models, but these are just a translation layer between the Database and the view function, they don't keep state either.
I don't see how a Django view isn't a "microflow". It seems to me that the architecture is exactly the same, it's just that you don't get to choose the web framework.
There's definitely a performance tradeoff, one which I reference a little in the latest part and will definitely talk about more when I get to drawbacks (likely in the 5th update.) There's definitely a big class of applications where FaaS with its current limitations isn't a good choice, but I wouldn't say that class is universal.
12 factor statelessness I read as meaning more application / domain state rather than infrastructure state btw.
> This is an evolving publication, and I shall be extending it over the coming days and weeks to cover more topics on serverless architecture including some things commonly confused with serverless, and the benefits and drawbacks of this approach.
> This is an evolving publication, and I shall be extending it over the coming days and weeks to cover more topics on serverless architecture including some things commonly confused with serverless, and the benefits and drawbacks of this approach.
With this type of architecture, aren't you creating latency by separating out the "backend" from the database? In the traditional approach the backend server and database are in the same datacenter, but it seems that's often not the case in FaaS approach, what are the ramifications of that?
If you were on AWS, I would expect the Lamdba fn to be running in the same datacenter as the backing dynamodb table, or at least in the same region. dynamodb response times are pretty good - typically under 10 milliseconds.
Roughly speaking: A region is a geographic location (e.g. eu-west-1 is in Ireland and eu-central-1 is in Frankfurt, Germany) The "Availability Zones" are separate datacenter buildings in that region connected by fat pipes.
For fault-tolerance, it is common to make sure that all of app's parts run across multiple availability zones in the region. This will happen without much manual config.
Crossing regions is very different - it's not going to happen automatically, they're pretty much isolated from each other. Only a few extremely-highly-available apps (e.g. netflix) have engineered to cross regions. See https://www.infoq.com/presentations/netflix-failure-multiple...
We sort of do this for a JVM with the exception that it is the JVM and you really can't be rebooting it all the time.
What we do is use a message queue and extreme thread isolation. Are internal framework is sort of analogous to an actor framework and/or Hystrix but is stateless through out. Messages are basically functions that need to be run.
That being said because our whole architecture is message driven and uses a queue with many client implementations we have been experimenting with OCaml Mirage and even some Rust + lightweight container because of the serious limitation of booting up the JVM.
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 some sort of overridable "init"?
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.
"1. Often require vendor-specific language, or at least vendor-specific frameworks / extensions to a language"
...
"(1) is definitely not a concern for the FaaS implementations I’ve seen so far, so we can scrub that one off the list right away."
That point do not make any sense to me. You have to follow the AWS Lambda programming model which is specific to AWS Lambda, so either way you are tied to some libraries and patterns which are vendor-specific.
The client could conceivably connect to something like an ElasticSearch database (JSON API), setup with no auth/read-only permissions and appropriate rate-limiting.
You are really talking about a very small use case if you say the only database that could be used would be no auth/read-only considering most database requires auth for security and most apps need to write.
And then you use a "function" behind the gateway for the parts that need to write or need to see things that need authentication. Just like in the diagram...? Nothing says that you can only allow public access to a database.
Wrong. All wrong. Serverless is like what is the server standing on before the server? That is serverless. Peer to peer mesh discovery protocols, for example. Serverless implies no server. Buzzz buzzzzz buzzzz buzzzz. Sexless sex.
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?
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.
Raw WebSocket handling could be delegated to something like Pushpin [1] (disclaimer: author). This way, the backend doesn't have to maintain any long-lived connections of its own, but it retains a similar level of control over each connection that a full backend would have had.
As an experiment, we built a chat app like this (using Stamplay as the FaaS) and it actually worked.
* 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 little bit of syntactic sugar so it looks like we're just adding functions to a queue.
* We have no ops or devops staff. We just deploy code that implements functions (http endpoints).
* Persistence is also scaled by Google; there's no database server, just an API to read/write data that scales infinitely (or at least, scales with linearly our bill, not limited by the dataset).
It sounds to me like the article is trying to distinguish between "serverless" and PaaS by describing PaaS done poorly. For the longest time, GAE didn't even expose the # of instances servicing your app. They've exposed a lot more of the underlying constructs since, but you can still ignore them unless you're trying to hyperoptimize your bill.