Ah, the PetStore example brings back memories! Wonder how many people remember it?
Serverless Architectures
41–50 of 149 posts
Re: Serverless Architectures
#42Earlier quoted context omitted.
Sounds like inet.d, or CGI behind a webserver.
...or socket-activated systemd service [1, 2] [1] http://0pointer.de/blog/projects/socket-activated-containers... [2] https://developer.atlassian.com/blog/2015/03/docker-systemd-...
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.
Re: Serverless Architectures
#43In regards to Stateless and 12 Factor... > 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 se…
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.
Re: Serverless Architectures
#44Is 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.
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.
Re: Serverless Architectures
#45In regards to Stateless and 12 Factor... > 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 se…
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.
Re: Serverless Architectures
#46Serverless = new name for PaaS. 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 scalabilit…
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 bu…
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.
Re: Serverless Architectures
#47Ah, the PetStore example brings back memories! Wonder how many people remember it?
Welcome to Old Developers Club. :)
Re: Serverless Architectures
#48Earlier quoted context omitted.
...or socket-activated systemd service [1, 2] [1] http://0pointer.de/blog/projects/socket-activated-containers... [2] https://developer.atlassian.com/blog/2015/03/docker-systemd-...
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.
Re: Serverless Architectures
#49Serverless = new name for PaaS. 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 scalabilit…
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.
Re: Serverless Architectures
#50There 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:
https://www.gnu.org/philosophy/who-does-that-server-really-s...
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:
https://media.libreplanet.org/u/libreplanet/collection/resto...