Edit: An example of the kind of thing I am concerned will happen[2]. Use the word "serverless" in a project? Get a take down notice.
[1]http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4802:t7t...
[2]https://twitter.com/sindresorhus/status/776142274564616192
Take this as an opportunity to call it "cloud functions" or "functions as a service" or something more accurate/descriptive.
I'm not sure I'm comfortable using a presumably open-source, free (beer and speech) tool knowing that the group behind it will have to find a way to monetize their users in order to justify the investment from VCs at some point down the road. Open-source developers should of course be able to be compensated for their work, and the project has to find a way to sustain itself (I work for a company whose main product is open-source so I know this better than most), but the venture capital model doesn't seem like a good fit with the interests of the community, in my opinion.
That said, Serverless is a great tool, and congrats on the 1.0. Thanks to the team for their hard work.
There certainly are other open source tools like ansible, Chef, Puppet, Hashicorp, MongoDB (and many more) that have started out as an Open Source project and are still OSS champions.
We have many plans for monetisation and are working closely with small to enterprise scale companies on building products and services around the Framework that help you once your infrastructure has reached a large scale. More info to come in the future.
The license is MIT which guarantees we can't coerce you to do anything.
What alternative for compensation do you propose?
- Kickstarting: Django REST Framework's development was successfully funded for a year or more by funds raised on Kickstarter[1]. This model doesn't scale that well.
- Sponsorship: DRF is also a good example of this. Corporate sponsors who use the product are asked to chip in as sponsors, in return they get some branding placement and community goodwill. It seems Serverless was at one point using this model (sponsored by Coca-Cola), it's unclear why they had to stop.
- Services/support model: as popularized by Red Hat, Canonical, etc. Give away the product for free, make money on support contracts.
[1]: http://www.django-rest-framework.org/topics/kickstarter-anno...
https://techcrunch.com/2016/03/30/cockroachdb-just-raised-20...
Once Serverless supports other λaas offerings I think this will really take off.
In addition to the big boys (Amazon, IBM, Google, Microsoft), I'd love to see some alternative stable open source providers come about. Maybe something built on top of kubernetes or docker swarm.
It's true each function needs it's own connection, but in reality:
1) The containers actually stick around for a while and get reused so if you write the code correctly it only has to establish the connection once per container invocation
2) Unless you are doing a lot of traffic you'll probably only realistically have a few containers running your functions so it will only be a few connections.
3) If you end up with enough traffic that it actually becomes a problem, it would have been a problem anyway because you'd be running a lot of servers with persistent connections in a more traditional model.
In other words, the number of connects and set up and tear down is about the same as in a traditional setup, maybe just a little bit more.
Edit: One more thing. Sometimes a counter I hear is "Yeah but every function needs it's own connection". I counter that with the contention that even with a traditional setup, a good abstraction means only one or maybe two functions actually talks to the database -- everyone else should be getting their data from that function. Also if you do it that way that one function can do some smart caching (which survives at least a few minutes with serverless).
I think this is the part I disagree with. DB connection pools are much, much smaller than than the total # of functions that touch a database in any reasonably complex application.
Yes, scale is always an issue, but it seems to me that in this serverless world where you have 1 connection per function you run into scale issues a lot(order of magnitude?) faster than the "traditional" way.
> a good abstraction means only one or maybe two functions actually talks to the database
In a serverless world, does this mean you would run a handful of functions with DB connections, and other functions would proxy db requests through them? I can see that working ok I suppose.
It's one of the things I have in mind for https://dbhub.io. Thinking it should be a good fit (especially for Serverless apps), but haven't yet written the code to try it out.
Likely to do so in near future though (weeks, not months).
That said, 1) What's the schedule on the documentation for best practices for SLS in production?
2) What's an example workflow ? (something involving multiple devs, testing, CI etc.)
3) And lastly, What's the timeline on adding support to Google Cloud Functions (in alpha) and Azure Functions?
EDIT. Only writing this because its in fact possible to imagine serverLESS framework these days (web workers, p2p etc), but this seems to be just about more volatile servers.
