By this definition, we've been running "serverless" on Google App Engine for most of a decade.<p>* 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.<p>* 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.<p>* We have no ops or devops staff. We just deploy code that implements functions (http endpoints).<p>* 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).<p>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.
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?<p>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.
There are a number of things I find alarming about this (which is nothing new):<p>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.<p>Perhaps most alarming is the acknowledgement of this:<p>> 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.<p>This highlights the major issue of SaaSS/SaaS, and FaaS takes it to the extreme:<p><a href="https://www.gnu.org/philosophy/who-does-that-server-really-serve.html" rel="nofollow">https://www.gnu.org/philosophy/who-does-that-server-really-s...</a><p>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.<p>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".<p>I expressed my opinions and concerns at LibrePlanet 2016:<p><a href="https://media.libreplanet.org/u/libreplanet/collection/restore-online-freedom/" rel="nofollow">https://media.libreplanet.org/u/libreplanet/collection/resto...</a>
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.
Serverless = new name for PaaS.<p>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.<p>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.)?<p>[1] <a href="https://en.wikipedia.org/wiki/Platform_as_a_service" rel="nofollow">https://en.wikipedia.org/wiki/Platform_as_a_service</a>
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.<p>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?<p>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.
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?<p>Am I missing something?
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.
It's just outsourcing. It "depends on 3rd party applications / services (‘in the cloud’)" It's like Salesforce's "No Software".<p>A real serverless architecture would be federated, like BitTorrent or Bitcoin.
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.
In regards to Stateless and 12 Factor...<p>> This has a huge impact on application architecture, albeit not a unique one - the ‘Twelve-Factor App’ concept has precisely the same restriction.<p>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.
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?
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.<p>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.<p>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.<p>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.<p>Does AWS Lambda / similar have some sort of overridable "init"?
"1. Often require vendor-specific language, or at least vendor-specific frameworks / extensions to a language"<p>...<p>"(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."<p>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.
<a href="http://martinfowler.com/articles/serverless/sps.svg" rel="nofollow">http://martinfowler.com/articles/serverless/sps.svg</a><p>Is there something wrong that the client browser is connecting directly to the database, so JS -> MySQL direct connection won't expose credentials ?
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 <i>one</i> computer: the AWS lambda "main frame."
Serverless now means "servers in the cloud" ? So what do we call apps that don't use servers!? I'm actually writing one right now...