FaaS is closer in mindset to CGI than fCGI : if you're gonna have a server accepting connections, you might as well accept HTTP connections. CGI and FaaS are more like developing a function that transforms a request into a response, and let the infra deal with the rest.
It is true though that it would be nice to have a standard for FaaS that doesn't have the inefficiency of CGI.
That the process is kept warm is an artifact of the infrastructure. As a Dev you absolutely don't care about how it's run and that's the whole point: just implement your business logic and the system takes care of the rest. As a dev it's all transparent.
That's actually less true of Lambda than of php-fpm. In Lambda, you can mutate the state of global variables between requests[1]; you have to take care not to do that. In php-fpm, all is thrown away.
That's true for php-fpm, though many use something like apcu to cache state between requests. FCGI itself doesn't mandate that "thrown away globals" behavior. Golang under FGCI, for example, just spawns a goroutine for each new request.
No it’s no more out of hand than any other term that has been co opted in computer science and that most people in the industry have sccepted like bugs, viruses, bits, etc.
What was the previous "computer science" definition of "debug", "virus", "platform", etc. before someone coined it? But as time goes on, if you are part of the profession, when someone starts a conversation about the merits of "serverless", it's not helpful or insightful to keep with the tired response "the code is running on servers not via magic pixie dust".
That response is about as insightful in 2018 as saying "I don't know why they are calling it debugging. Don't they know there are no physical bugs in their code"?
The other terms you mention have some relation to the original meanings. A computer "virus" is named after the infectious, peer-to-peer spread of the real one. A "platform" is named after a supporting structure. "Debugging" has an engineering tradition that predates software[0].
"Serverless" is the exact opposite of that. It's taking a word that literally means "without servers" and making it mean "with servers, possibly a lot of them".
Yes! I've been advocating among my colleagues to perceive "serverless" as "functional programming -> web services"
I get that the allure of not focusing on infrastructure, scaling, etc. is strong. But that's really a side effect of what you're actually doing: applying FP principles to web service design.
And it really fits the paradigm well. You've got HTTP services (short lived, therefore comfortably stateless) that are ideally infinitely scaleable (easy to do when your HTTP services are basically pure functions). Do you need caching? That's like memoization of your functions!
No one who has any technical competence is “confused” by the term “serverless”. No one thinks that thier code is being run by unicorns and fairies.
It’s more like people yelling at the wind or thinking they are intellectually superior because they are in on the little secret that servers are involved.
It does cause confusion because it is absolutely non-descriptive, especially when the literal definition is completely the opposite of anything it has ever described.
Confusion by who? I’m sure the same people who are “confused” by Amazon’s use of “serverless” would also be “confused” by terms like lambda, cloud formation, cloud trail, Redshift, Route 53, Elastic Beanstalk, Aurora, OpsWorks, Mechanical Turk, etc.
Just like everything else in technology, if someone is confused by tech jargon, they should research it.
I'm sure you realize there are people out there that are starting out or are just new to this? There's no need to add to the confusion, we already have enough of it in this industry.
Product names are either unique (for branding) or have some tangential matching definition. Serverless is none of those. Vague, inaccurate, nondescript. It is of no use.
This is like NoSQL all over again, absolutely meaningless in every aspect and adding to years of
So out of everything that it takes to be a competent dev in 2018, including learning $front_end_framework_of_the_week we should single out the term “serverless”?
I know most of the features of AWS either from real world day to day use or at least on high level that I can talk intelligently about them. The time it took to learn them wasn’t lengthened by the term “serverless”. That was one of the easiest things to wrap my head around - write your code like you always do and just have a function as an entry point that takes two parameters - a JSON object and a context object and wire up an event that calls it.
But on the other hand, when a bunch of Azure folks start talking about Azure features they are using, I am clueless. Does that mean that Azure services are misnamed or that I would need to spend some time learning about it on high level if I wanted to talk intelligently?
For instance when I heard friends talk about Data Lakes, Data Factories, Event Hubs, I had no clue what they were yamerring on about. The same when anyone starts talking about machine learning.
No. Who said single this out? Instead we should just do better.
Concepts should be carefully named because this is not just jargon between a tiny handful of highly competent and super technical people; a vast number of devs and non-technical users will use these terms and it is in everyone's best interest to use descriptive and sensible wording.
Data lakes, data factories, event hubs are product names, not concepts, but they are either exactly the same as their underlying concept, or very closely related. However, as stated for the 3rd time, serverless is not. It's completely inaccurate and vague.
Where did you get that "serverless" means function as an entry point with 2 params? Every platform is different, from entry points to parameters, to bindings, to runtimes, to concurrency, to scaling, to security, and more. So the term is meaningless in describing anything. Many "serverless" function/lambda systems are evolving into running arbitrary containers and now have come full circle to basically a modern version of PaaS, which is what they should've been called all this time.
There are clearly better options and tons of examples of poor naming causing annoyances and best and utter confusion at worst. We still live with the NoSQL hype repercussions and now serverless is following the same trend. It's not helpful and we can do better. What is a serious argument against that?
Data Lakes, Data Factories, and event hubs just sound like gobbledygook to me and if they are “exactly the same as thier underlying concepts”, those concepts mean no more to me than the term “serverless” mean to the uninitiated and I’ve been developing professionally for over 20 years. It’s the developers responsibility to pick up on industry jargon just like I had to do a year ago as the Dev lead when the company I worked for wanted to “move to the cloud”. I thought AWS was just a bunch of VMs a year ago.
I had heard of “Nosql” two years ago but I didn’t know what it was until I was hired to implement two projects on top of Mongo. Did I complain about the use of the term “NoSql” every time someone mention it? No, I learned Mongo inside out so I wouldn’t design something non scalable and non redundant.
You keep answering about yourself, I'm talking about the entire industry. For every one of you, there were 100 people who used MongoDB because its "fast, cool, noSQL".
It's great that you research, but many do not. Hype, jargon, and excessively misleading terms are real, and they make a measurable impact on productivity and confusion. This is why marketing and branding is so important when naming, and its why there should be an effort made to use better terms.
I still haven't heard a single argument on why we shouldn't do better, other than that you can handle it. Good for you, but that's not the point.
Does it? I always just considered those IaaS and thought "serverless" basically meant AWS Lambda or any comparable service (for which I agree FaaS is quite apt).
Cloudflare usually puts out good info but this is really bad marketing material stretched way too far to make a point, because they have their Workers platform and want to ride the "serverless" hype train.
Everything mentioned in that diagram is completely arbitrary and varies for every single vendor.
Serverless doesn't have a good definition because it's not a real concept.
At most lambda/workers/functions are really just PaaS, except instead of uploading all of your code, it's just a single file with a single endpoint.
If we really need a new term, then micro-paas or FaaS works fine, although most FaaS vendors are expanding to running any arbitrary container with multiple endpoints, so we're right back to normal (but modern) PaaS at the end.
There is still a server running the code, you just don't control it.
Claiming "it just means I don't have to worry about it" means that classic shared web hosting with shockingly outdated versions of php and perl are "serverless" too.
There are many apps that have "no server anywhere." For example I have a purely offline chess app. This chess app is not "serverless", because it does not use any FAAS interfaces.
It's absurd that such an app is not considered serverless precisely because it doesn't actually use a server.
"X as a Service" is a common enough term that someone is more likely to have heard it before, and it accurately describes what it is (if the X is accurate).
"Serverless" is deliberately wrong and misleading.
One of those stupid "entire website in a page" would be a better fit for "server less" because technically the logic is all client side.
And wires are still involved with wireless networking, but people are somehow more forgiving of that. People are just being pedantic for no good reason.
> And wires are still involved with wireless networking, but people are somehow more forgiving of that.
not between 2 wireless endpoints, there are no wires. Between you and what you call "serveless" there is a server you need to query to get the result of whatever program you executed remotely. There is no wire between my router and my laptop.
Well, Joe Armstrong once proposed a global database of open source functions, that you could dynamically lookup and fetch [1]. Sounds like Functions as a Service :)
> Just remember the modern definition of serverless:
Just because it runs on someone else's machine doesn't mean it is "serverless". an API Gateway obviously is a server.
FAAS is just a good old worker queue, there is nothing new about that.
There is no "modern definition" of serveless. it's just marketing, it has nothing to do with technology. Developers shouldn't use that word and expect to be taken seriously.
That's a good definition for P2P, not for "serverless". Serverless functions run on a server. It typically refers to a category of PaaS which allows on-demand code execution (as opposed to "always on" services).
Serverless databases are a thing. Serverless is not confusing. It's only confusing if you try to be pedantic with remarks like "duh, it has to run on a server some where."
Which really means wireless networking doesn't exist, because there are still wires involved somewhere, and I don't hear people being pedantic about that.
If you think "serverless" is not confusing, then you have lost the vocabulary to even describe apps that run truly without servers: Photoshop, Word, tons of games, etc.
By your "wireless" analogy I think you view these apps to be absurd impossibilities, like electronics without wires.
This distinction is important. SimCity 5 gratuitously required the user to be constantly online, talking to some server. I mean obviously - there has to be a server somewhere, right?
No, there does not!! We need to retain the ability to talk about apps that do not need ANY server, and "serverless" muddies that crucial distinction.
> If you think "serverless" is not confusing, then you have lost the vocabulary to even describe apps that run truly without servers:
I generally just call them apps and people understand what I mean because of context. But if you want to get pedantic, Photoshop requires a computer (what a server is).
Are you seriously incapable of talking about programs that don't require servers because the word serverless exists? Have you considered... offline? Local? I've never heard the word serverless ever used to describe a system that does not require servers.
Wireless networking is wireless because communication between device and AP is wireless. Serverless has no point where there isn't a server involved. It's just a service that runs your program on a server you don't control. No definition of 'serverless' fits into that.
Just coming to this article, I find my self agreeing with you and the gist of the thread about serverless being a horrible descriptor at the same time.
It was just one thread though, and I could see how it sucked people into its vortex, I haven't even had a chance to read the article yet, and here I am doing the same as everyone else (including you...). Well, worse actually, as we've contributed to a new thread.
"[T]he English language... becomes ugly and inaccurate because our thoughts are foolish, but the slovenliness of our language makes it easier for us to have foolish thoughts."
This is a garbage article. It reads as a commercial and not an informed technical piece.
As I understand it, according to this article, netflix is 90% complex services that have nothing to do with node. All this article is describing is adding an additional layer in front of those services, which uses a hosted solution that abstracts away servers.
So it sounds like by-and-large netflix still uses traditional solutions.
So what's not clear from the article:
1. Why node?
2. Why add a layer at all? I don't see why UI A/B testing couldn't be handled with truly front-end changes. Does this somehow enable A/B tests on TV apps, for example?
3. How does this play with traditional version-control? (e.g. in a post-mortem if you need to see who changed something, and who approved it, is there a written log? And merge conflicts?)
While the article focuses on the Why, the article isn't thick with implementation details about the How. From the image, it looks like they wrote a Node.js program and have it running inside Docker. The article mentions their custom IDE (NeWT - Netflix Workflow Toolkit) that connects to the Docker instance.
The lower half of the article covers their development toolchain:
Interesting that they show a usecase involving Vizceral (their traffic visualizer, "intuition engineering"), despite them publicly abandoning the project. Hope this implies they are working on releasing it formally!
TL;DR: It sounds like they wanted their UI teams to be able to easily deploy UI specific API endpoints, and existing offerings had too much latency.
I’ve often built UI-specific API endpoints, but have often been told such endpoints are a bad practice. In reality, I think they’re great. It allows you to serve up optimal payloads and move much more quickly than writing the equivalent general APIs.
That said, wasn’t Falcor the Netflix solution to this very problem?
