1. It's a server actually. It's just that the server serves up functions, without state. So a more correct terminology would be "stateless servers"
2. Truly P2P (Like blockchain), therefore there truly are no "servers".
Used to think Amazon did a great job coming up with the jargon that's great for marketing, but lately as we see more and more option 2s which are TRULY "serverless", the option 1s increasingly sound like imposters.
After all in option 1, there ARE servers. To be able to claim you're "serverless", you really shouldn't have servers.
P2P also doesn't mean "no servers", but that every node is as much server as client.
Amazon popularized but didn't invent the term "serverless", which appears to have been first used in 2012.
They already had stuff like that. S3. RDS. Elasticache. At least the cloud gives you the nebulous feeling of servers off in the ether somewhere.
But serverless is neither specific nor accurate. It doesn't work. It's nothing more than lazy marketing-speak.
A requirement for serverless would be having access to a general programming language which is why those examples don't really apply.
1993 is the new 2018.
edit: And the life of the Apache Web Server (the first AWS) started with that interface.
The real serverless apps are pure clients that use 3rd party services for everything - i.e. the developer doesn't write any backend code that runs on their own infra.
CGI does the same thing Lambda does: it binds the application lifecycle to the request lifecycle. HTTP requests to an application server that runs across multiple requests are not stateless, they're inherently bound to the server's internal process state. If the server is well-written this shouldn't matter, but the entire reason an application has to be refactored at all to become a Lambda is that this is not usually the case. Most modern application-server style web apps are loaded with mutable global state that lives through many requests - from thread / connection pools to global caches to updatable configuration stores to even dynamically loaded code/modules.
Which in term, makes this project weird. Because in order to use it, you still needs to hosts a group of servers yourself. If someones else hosts it for you, you don't really care what framework they are using.
So they say but it still sounds daft.
I have a ticket to fly from London to NYC but all I have to do is turn-up and sit in a seat, someone else manages the imfrastructure. Aeroplaneless architecture!
Seeverless is a catchy name, and a better one perhaps would have been function oriented or function service or some such. But it really does mean swrverless in that (a) there isn’t one server and (b) there is zero configuration and maintenance of the server for you to perform.
People use "blockchain" to describe it to other non-technical people, but they do need a way to describe their architecture. Among blockchain/crypto developers the word "blockchain" has become washed down too much that it really doesn't mean anything. So when they need to explain their architecture they do need a way to describe how their app doesn't have a server.
What I've seen is people say "my app is 'TRULY' serverless", or "My app does not require a centralized server". This was actually my point, because it looks like people who are actually building truly "serverless" apps find themselves in a situation where the word has been hijacked by server vendors, so they have to use qualifiers like "truly", or explain it out in more detail to actually express that they indeed don't have a server. Not saying all the FaaS guys don't have a point, just saying it's kind of a funny situation not so different from when "hoverboard" was viral a few years ago. Everyone knew it didn't "hover" but it was too late because the brand was already taken.
> But it really does mean swrverless in that (a) there isn’t one server
Normally when you say "X-less", it means "there is NO X", not "there are more than one X".
And are you saying that people in the crypto world have blockchain as such an implicit given that they don’t need to describe it, but a distributed nature of its operation is something that explicitly needs to be stated every time? That seems really silly. “As a public ledger” is better than serverless in that case. Or “smart contracts”. But serverless really is a misnomer buzzword in that case.
This is all wordplay and we can go on forever like this. Using your measure, we can also say any SaaS is "serverless"--heroku is serverless, aws is serverless, digitalocean is serverless--because nobody owns a physical server anymore.
> And are you saying that people in the crypto world have blockchain as such an implicit given that they don’t need to describe it, but a distributed nature of its operation is something that explicitly needs to be stated every time? That seems really silly. “As a public ledger” is better than serverless in that case. Or “smart contracts”. But serverless really is a misnomer buzzword in that case.
Again, this is really difference in interpretation of expressions. When you use Ethereum to write a smart contract, you basically store your application state on Ethereum. Compared to ordinary apps where you host your app on a server you own, this sound pretty much "serverless". If you have an AWS instance you have to pay monthly fee. If you deploy a contract to Ethereum, you just pay once when you deploy, but once deployed you don't pay for hosting.
"Public Ledger" is an ambiguous terminology which doesn't fully describe what blockchains do either. You could have a public ledger without it being decentralized nor transparent. A central authority could just make their own database public, but they could always manipulate the data if they own the database. The whole point of blockchain is that no one party should be able to control the truth.
"smart contract" is also generally considered a ridiculous terminology by those who actually do work on building "smart contracts". They are mostly "dumb" contracts. In fact, when you write these contracts, the dumber the contract is the better it is. If you try to be too clever, you end up with stupid mistakes like the parity hack. Therefore most "smart contracts" are ideally nothing more than transparent auto-updating distributed databases which can send messages to one another.
I'm not saying you're wrong and I'm right. I'm not even saying blockchains should be called "serverless" instead of FaaS owning the brand. I'm just stating what I've observed: Most FaaS services are hosted on a server that the owner needs to pay for every month. Blockchains don't have an owner and there is no "server". I think blockchains are closer to "serverless" than FaaS because of this, but by no means I consider this a perfect description of the technology.
On a separate track - Is it the sign of my age, that I am either concerned about developers not knowing the impact of their code on the hardware, or just whimsical and miss the days when one opened strace or kdb to see how efficiently the code executes? Does someone else feel this way?
One of the less desirable side effects of hardware becoming cheaper is that there are many places for a lousy programmer to hide.
So I don't think it's for "dummies". Dummies want an all-in-one server.
Any normal PHP app is just a collection of stateless functions, but that doesn't automatically make all PHP apps "serverless" apps. What makes something "serverless" is the FaaS execution model.
OpenWhisk was one of the first projects in this space and is written entirely in Scala. Good to see a Kubernetes integration emerging.
Other notable projects: Oracle's Fn, Bitnami's Kubeless, Platform 9's Fission, Iguazio's Nuclio and OpenFaaS (community project). (there are more)
They're really invested in Kubernetes with their open source OpenShift PaaS.
All the intro docs and FAQs seem to assume that "serverless" is literally no servers, just magical cloud fairies or something.
I get that it uses docker containers, but where can i / am i expected to run those?
This someone could be e.g. IBM or RedHat, it could also be someone like Adobe that wants to offer a FaaS integrated into their main product.
It could also be your own company, e.g. you could have an infrastructure team that provides it for all other teams.
On a single machine, you can run processes ("invoke functions") locally. On a cluster, you can run a process, and it will start somewhere, on one of the less-loaded boxes.
With "serverless", the cluster is the cloud (a datacenter). You do not have to maintain it, but you can specify the code to run, and it will run, as many copies of it simultaneously as needed (thousands or zero), and you are only billed for the resources you consumed. It's ultimate elasticity for non-interactive load.
I get "serverless". I totally get lambda and some of the other open source clones of it. What i don't get about "Whisk" is if this is something that builds on top of existing serverless infrastructure that makes it better, or if it's it's own serverless infrastructure that you have to install on your own servers, or ... what. they're completely opaque about the actual server side infrastructure of this "serverless" platform.
Here's some documentation for OpenWhisk on Kubernetes (running locally or on your own servers or cloud providers' Kubernetes cluster meeting the requirements specified).
There are other ways OpenWhisk could be deployed besides as well (see https://github.com/apache/incubator-openwhisk/blob/master/an... ), but it appears you will need server(s) or local computer to run OpenWhisk on.
I do completely agree the Apache site for the project seems lacking in terms of the deployment docs. Which is a shame, because as you can see from the links I posted, deployment can be quite involved. It is still incubating though. Maybe they need volunteers to step up and help with the documentation on the Apache site?
This is all just from what I could find in docs/searching for info, I've never run OpenWhisk.
Edit: I could be wrong, looks like there is an OpenWhisk offering from IBM: https://console.bluemix.net/openwhisk/
If you're wondering whether Serverless is catching on then see also: AWS Lambda.
- Paying for idle servers can get costly if you have many of them.
- Idling servers are inefficient for cloud providers as well.
The upside is that you invoke the "functions" not as processes on one box you have to maintain (*CGI), but on many boxes maintained automatically. Your limiting resource is not the limitations of the box, but only your budget. Also, stuff like security, software updates, load balancing, etc is taken care of by the provider.
It can also be deployed on k8s with minimal effort: https://github.com/apache/incubator-openwhisk-deploy-kube
There's also instructions for using VMs as the infrastructure layer: https://github.com/apache/incubator-openwhisk#quick-start
If you have any issues open an issue or join us on the slack (http://openwhisk.incubator.apache.org/slack.html).
(I'm a committer on the project).
They are in the ReadMe, let me know what you think of it.
It contains a bunch of unique features, so it's not your typical serverless platform, but the core is the same if you don't want to go crazy with the web framework like features.
There's also a difference between deploying rapidly for local development (less is better) and actually running a functions platform at scale. AWS lambda reportedly handles over 2B lambdas a day (this was a year ago).
Not every platform needs that kind of scale, but it does put things in perspectives.
Thanks for the encouragement. To be fair we at 1backend don't consider the field that new at all. It's just the old PaaS concept with some twists and reworded marketing!
I personally spent years building microservices platforms at various places and after years of not implementing my insights I decided now the time is right and people might adopt it given the current hype cycle =)
I'd agree, old ideas, new contexts. The twists matter.
1 - Less stickiness to AWS since the serverless architecture would abstract away the provider and i could theoretically even grab the cheapest spot instances across providers (AWS, Google Cloud, SoftLayer, Azure)
2 - Lower compute bills (due to better usage and being able to more tightly pack stuff into nodes)
3 - Lower HR bills due to a lot of stuff just scaling up without effort rather than dozens of deployment/babysitting staff
Hard to know for sure, but these are the three things that drove me to Kubernetes.
Even if you could separate them it would add latency. Now if it JUST compute... and I can see that as a possibility for some CV applications.
The next few years will see 1-2 open-source frameworks along with all the cloud vendors getting to parity of running almost any language in response to almost any event source. Templated data pipelines and other processing should also become common and as easy to run as a docker container is today.
Can you expand on this, please? I've got a very basic understanding of the first two, would like to know more.
AWS Lambda is decent and has features like Lambda@Edge which runs on CDN nodes and can do processing on each request.
Wouldn't be an out of the box solution provided by AWL Lambda, Google Cloud Functions, etc... a better and more straightforward option on this space?
I am just wondering if I am the only one with this opinion, what is your experience on this topic?
- HackerNews, every time.
- The function get stuck and run forever?
- It causes a request to loop?
And you have hundreds or thousands of these "functions" deployed?
Couldn't that cause sky-high costs if it goes undetected or even unwanted DDOS against other's infrastructure?
The second is harder. Last I checked, AWS Lambda for example would allow a loop between two functions to run forever. You have to build loop detection into your software.
The classic example of this is a function subscribed to S3 events which in turn creates an s3 object itself :P
Could someone with production-level serverless experience share his insights on OpenWhisk capabilities and roadmap? What's missing from the G/A/M stacks?
- Excellent "out of the box" runtime support including Node.js, Java, PHP, Swift, Python, any binary runtime (Go, Rust, etc..).
- Custom runtime support using Docker images. Allowing custom images as the execution environment makes it easy to use (almost) anytime on the platform without needing this to come built-in. Custom images can be used to add large libraries or other resources.
- Integrated API Gateway. Makes it simple to expose custom routes to functions.
- Multiple built-in event sources including HTTP events, CouchDB, Kafka and more. Platform supports registering custom event providers to add any external data feed or event source.
- Higher-order function composition patterns including sequences.
There are numerous open-source serverless platforms but OpenWhisk is the most mature and one of the only open-source platforms powering commercial serverless offerings, being used by IBM Cloud Functions, Adobe and Red Hat. It has used by IBM's offering with customers since early 2016.
Development is all public with the project being in the Apache incubation phase. Upcoming features being worked on include Swift 4 support, on-going k8s integration and better higher-order functional composition patterns. Check out the Github PRs and issues for details.
(Disclosure: OpenWhisk committer and IBMer).
A lot of the other things you listed are present in other FaaSes too in varying degrees.
No questioning that OpenWhisk was the first major opensource project in this space, though.
Runtime support (upload code not a container) is more common in the commercial offerings that most of the Docker-based faas frameworks, which use a container as the packaging.
OpenWhisk is more flexible than most of the platforms with respect to packaging IMO (Wanna deploy code? Great. Prefer containers? Sure. Wanna use code and a custom image? No problem!)
Event support is more common in the commercial offerings (as they have cloud services for you to use), whereas the "faas" framework seem more bare bones. You'll have to configure event integration manually. Same goes for API gateways.
OpenWhisk supports numerous open-source event providers with a extensible API for integrating new providers. This is more complete that lots of the other projects in this respect.
Over time these features will become default in all projects but there does seem a split in focus between the commercial offerings and "faas" frameworks at the moment. I'm biased :) but I think OpenWhisk has a comparible feature set to Lambda (having been around for over two years) whilst still benefiting from the open-source docker story.
Most of the Azure Functions codebase is actually open source under the MIT License: https://github.com/Azure/Azure-Functions
It's not an apples to apples comparison though since OpenWhisk is intended to be self deployed.
I mentioned Functions here just because many folks don't know that most Azure SDKs, runtimes, tooling, etc are OSS by default.
Despite the monitoring part that must be quite hard.. I wonder about the network saturation in case of services that get millions of requests per minutes and having, in this model, function interactions going through the network
I believe OpenWhisk is being steered towards running on Kubernetes at some point, but I am not qualified to say. When we looked at it last year as part of the research which led to Riff, we were struck mostly by how many moving parts are involved.
Disclosure: As I noted, I work on one of these things for Pivotal.
See here for more details: https://github.com/apache/incubator-openwhisk-deploy-kube
(Disclosure: I'm a committer on Apache OpenWhisk).
Not to mention few newer ones (there are over 30 serverless frameworks for any taste and size).
The cloud providers offer "serverless" billing for AWS Lambda/GCP Functions/Azure Functions in the sense that you pay just for the compute time and don't manage the underlying infrastructure.
Outside of vendor lock in, what advantage does running a service like this really offer? To make a system like this usable you'll probably need at least a couple of boxes available 24/7
Also, if you're running lots of function iterations, it can be cheaper to run this way than Lambda etc.
However, with Zappa, you begin by downloading a bunch of wheels (pre-compiled python packages) as dependencies for your project - I guess this helps with the packaging / deployment problem, but it’s also bloat that you have to think about - and quite frankly a bizarre introduction to a framework that made me feel less than confident that it’s not duct tape app the way through.
With serverless, the wsgi plugin, and the python packaging plugin, you’re compiling wheels on a rocker container which means you’re requirements remain “yours”, you compile only and exactly what you need, and it looks a bit more like “normal Python”.
The downside of `serverless` is that you don’t get the “task” integration built in - so you pretty much need to wrap boto3 with your own api that mimics celery/rq/etc.
Also, as is the case with any solution I’ve found is that they’re peculiar to work with if you write your python code as a package - i.e. with a setup.py. You end up in a strange place with “-e .” not behaving well in a requirements.txt or a Pipfile that is used to package for Zappa.
But what happens when you have billions of scripts, each executed infrequently? You need some way of fetching the scripts dynamically (they are changing constantly), and way to time-multiplex their execution so you don't waste RAM on inactive scripts. Oh, and load-balancing suddenly becomes non-trivial because you prefer to route to one script spun up on one box (as long as the usage doesn't justify multiple boxes), instead of accidentally spinning up that script on every box.
What's new is the layer that is managing fetching, starting, and stopping the scripts. For developers, it's 'kinda the same'. But for operators, it's a massive change in how things work that enables a different paradigm.
The closest to scientific HPC I have used personally is pywren https://github.com/pywren/pywren
Which is attempting to add more cloud backends. It's out of Berkley University.
It doesn't literally mean "without servers". It means that the developer doesn't care about them. AWS have energetically pushed the line that in The One True and Holy Definition of Serverless operators don't care either.
Which, gee whiz, what a coincidence, distinguishes Lambda from opensource projects like this.
Disclosure: I work on a FaaS, Project Riff, for Pivotal. So I guess we're kinda competing with AWS? -ish?
Popularized by, but not invented by: http://readwrite.com/2012/10/15/why-the-future-of-software-a...
Almost. Imho "serverless" describes more the architecture of applications, in contrast to "mini-PaaS" which would then describe the platform on which such applications are deployed.