31–40 of 56 posts
How does this work when a database/persistence layer gets involved? Having a DB connection per function that calls it seems bad.
How does this work when a database/persistence layer gets involved? Having a DB connection per function that calls it seems bad.
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).
Are 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…
Congrats 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…
So it Server less Framework that seems to be considerably tied to AWS servers . 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.
'Serverless' as currently jargoned is used to connote that the developer does not have to think about servers (or VM's or containers) directly. The 'serverless' buzzword does not mean that there are not servers somewhere doing useful work.
Congrats 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…
Since TESS (Trademark Electronic Search System) requires a session, here is your reference [1] in image format. It's a trademark for SERVERLESS and also SERVERLESS FRAMEWORK both filed on November 25, 2015. https://piqd.com/serverless_tm.png https://piqd.com/serverless_framework_tm.png
How does this work when a database/persistence layer gets involved? Having a DB connection per function that calls it seems bad.
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…
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.
Earlier quoted context omitted.
'Serverless' as currently jargoned is used to connote that the developer does not have to think about servers (or VM's or containers) directly. The 'serverless' buzzword does not mean that there are not servers somewhere doing useful work.
Sorry, can you elaborate in which way this is "does not have to think about servers"? Because almost the first thing on their tutorial is some messing around with AWS.
I recently started using APEX. It doesn't rely on CloudFormation and has supports for hacking Golang support. Its worth a look if your getting more serious about Lambda development and interested in other options. http://apex.run/
