I hope something like "AWSless" will follow soon :)
Releasing Serverless Framework V.1, and Fundraising
51–56 of 56 posts
Re: Releasing Serverless Framework V.1, and Fundraising
#52Earlier quoted context omitted.
This seems to come up every time serverless comes up. There should probably be some better docs around this. 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 realistica…
> 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. 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, b…
For what it's worth, what we've been doing is building a separate service for talking to the database, which itself maintains a single common database connection pool.
I can't say yet whether that turns out to be a good idea or a poor one. (I'm not the one who designed and built it.) One notable feature of our implementation is that it eliminates all possibility of using transactions -- a design oversight that worries me.
Re: Releasing Serverless Framework V.1, and Fundraising
#53Earlier quoted context omitted.
> 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. 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, b…
For what it's worth, what we've been doing is building a separate service for talking to the database, which itself maintains a single common database connection pool. I can't say yet whether that turns out to be a good idea or a poor one. (I'm not the one who designed and built it.) One notable feature of our implementation is that it eliminates all possibility of using transactions -- a design oversight that worrie…
You could build the transaction support into the database service. Then when you need to write multiple things, you put them into a queue as a single work unit, and let your abstraction deal with taking the work unit off the queue and putting into the database in a single transaction.
This has the added effect of making your system more reliable because you'll be using queues and you have a shorter window when a process can die and hang a db connection that is trying to roll back.
Re: Releasing Serverless Framework V.1, and Fundraising
#54Congrats on the raise, but I'll be honest it really rubs me the wrong way that they renamed to "Serverless Framework" from JAWS. They should have picked a different name. The word "Serverless", for better or worse, was what the community settled on. Lot of companies and individuals use it in many different ways and have before this project existed. But they are trying to own it[1]. Not being a good community member I…
I loathe that sort of thing, but in this case I think we lucked out, because "serverless" is a particularly bad name for that style of architecture. Take this as an opportunity to call it "cloud functions" or "functions as a service" or something more accurate/descriptive.
Function hosting.
Re: Releasing Serverless Framework V.1, and Fundraising
#55Are there other examples of an open-source community project taking on several million dollars in venture capital funding? It seems a bit odd to me. 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 shoul…
I raised almost half a million for an Open Source Firebase ( https://github.com/amark/gun ). The license is MIT which guarantees we can't coerce you to do anything. What alternative for compensation do you propose?
There's a few models I've seen work well:
- 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...
Re: Releasing Serverless Framework V.1, and Fundraising
#56Earlier quoted context omitted.
For what it's worth, what we've been doing is building a separate service for talking to the database, which itself maintains a single common database connection pool. I can't say yet whether that turns out to be a good idea or a poor one. (I'm not the one who designed and built it.) One notable feature of our implementation is that it eliminates all possibility of using transactions -- a design oversight that worrie…
You could build the transaction support into the database service. Then when you need to write multiple things, you put them into a queue as a single work unit, and let your abstraction deal with taking the work unit off the queue and putting into the database in a single transaction. This has the added effect of making your system more reliable because you'll be using queues and you have a shorter window when a proc…
You certainly COULD (and if I were designing it I would have either done that or allowed callers to request a transaction in which case a connection is temporarily reserved for that client and a token returned which can be used to continue the transaction). But the people designing it DIDN'T do either. Which is part of why I question their design.