Build a serverless app with a serverless database
fauna.com
fauna.com
Not doubting it I just don't understand. Unless you're storing through "cache" client-side or direct RAM I don't know.
Thanks for the clarification.
It's probably more accurate to say something like "devops-free" since management of servers is hived off to a third party. Sounds less buzz-worthy, so maybe someone can come up with something better.
What is the difference between Fauna and DynamoDB? Especially since the article swaps them out (and explains the API differences).
DynamoDB is going to be having a replica you can read from within physical milliseconds of your lambda function (serverless is such a bad name, makes me think of P2P, anyways...) while it seems like Fauna is gonna have to make network calls out to your service...
Which when you pay per time with lambda, and you want lambda functions to be fast anyways, I don't see the point of Fauna? Note: I'm not saying Fauna is bad, it seems like a cool idea, but I'm not understanding how it is a superior alternative.
So lets say you don't want to pay for DynamoDB, it still seems like you'd be better off running something like a pure NodeJS database like Parse's open source server or https://github.com/amark/gun , either inside the lambda function directly or connecting to it (since it'll be on a nearby machine in AWS)?
The biggest operational difference between FaunaDB and DynamoDB, aside from being globally distributed, is that you don't have to pre-provision capacity in FaunaDB. DynamoDB requires you to provision capacity per table and you have to pay for whatever you don't use. If you go over the provisioned capacity your app stops working. FaunaDB is delivered like a utility; you just pay as you go.
Also FaunaDB supports joins, transactions, unique indexes, views, etc., and you can install it on-premises if you want.
At some point, the new hotness will be the old tiredness, and the cycle will repeat.
>When I say serverless, I’m referring to the function-as-a-service pattern. A serverless system must scale dynamically per request, and not require any capacity planning or provisioning. For instance, you can connect to FaunaDB serverless cloud in moments, and scale seamlessly from idea to runaway hit.
So, not AWS lambda then. With their concurrency limits, one-lambda-function-per-kinesis shard architecture, gateway request per second limitations, API count limitations, payload limits...
Its kinda equivalent to a timeshare condo vs renting a condo. Your functions only run when they are called.
Serverless implies a very high level of abstraction when interacting with cloud infrastructure. Traditionally app developers have consumed cloud infrastructure on the level of individual boxes running operating systems. Obviously these don't usually correspond to actual physical machines, but the OS box is the unit of abstraction presented to people running building and deploying cloud apps. Serverless apps are typically based on the "function" (one invocation of some small bit of logic) as the unit of consumption for cloud infrastructure - e.g AWS Lambda. They also typically embrace high-level abstractions for managing data - e.g. building against DynamoDB as opposed to your own Cassandra cluster running on EC2.
The term "serverless" is annoying as heck. I mean, sure, you're not fiddling with nginx configs, but you're even more tightly dependent on running in a cloud environment. It really should be "servermore".
Also, this confuses me:
> FaunaDB can tolerate the loss of a minority of physical datacenters in a cluster without interruption. According to the CAP theorem, FaunaDB is a CP system.
CP means that consistency is favored over availability, yet "without interruption" tells me they favor availability over consistency during a partition.
You can have a split that still has a group of machines with quorum: a 3/2 split would leave three nodes with quorum, and two without.
Clients which attach to the non-quorum machines would lose the ability to read or write if it's CP, yet the clients connected to the quorum machines would retain the ability to read and write. So it would be a partial outage, until some way is found to identify quorum members and route clients back to that quorum (making the assumption that clients could talk to any node in a partition).
Without interruption -for a minority of nodes-. Meaning it's using a quorum to achieve consensus. In the event of partition (which looks the same to the remaining nodes as a 'loss'), the majority side will still allow reads/writes. Meaning if you can't talk to the majority, you can't read/write; hence, not AP. If it maintains distributed consistency provided there's a quorum (Raft, Paxos, etc), it's CP.
I'd be curious then what the cost for doing a lookup of data not on your current node would look like. Do you re-connect to a different node which does have the data, or is it transparently piped back to your current node on request? Is that request broadcast, or is there some form of index maintained on each node of who has what data, how is the cross-talk structured... I'm a bit of a DB nerd, so the answers to these interest me.
> Meaning it's using a quorum to achieve consensus.
I missed the sly usage of "minority" there. I was expecting a quorum based architecture based on the rest of the documentation.
It seems dishonest to imply that there is "no interruption" at all on partition, since that's obviously not the case.
You can actually still do temporally consistent reads from the disconnected minority, but obviously they won't have the latest updates.
FaunaDB has a strong consistency, a relational data model and rich queries. This makes it more like a traditional SQL operational database, except it scales.
Seriously. Startups that promise that are ~dime a dozen.
Can we see TPC-C or whatever numbers?
In these evaluations we are running on production data so we can't share them directly.
What do you think about something like this for generating a reasonable data set?
http://ldbcouncil.org/blog/datagen-realistic-social-network-...
Hence, benchmarks.
So, if you do TPC-C or TPC-D or whatever, and compare well to others, you are doing great!
But if you avoid benchmarks, people think that you are not doing well. So they will not buy.
Just my 5c.
WHAT POSSESSES PEOPLE
TO USE PULLQUOTES
1. They don't trust people to read everything. A lot of readers drop off before the end of an article just because their attention flits away. Pull quotes are a way of saying, "Here's something coming up that I think is interesting. If you are interested, you should keep reading."
2. A lot of people have trouble with long runs of samey text. Some see it as boring, others as imposing, others as hard to navigate, but for whatever reason, long runs of text are simply hard to read for a lot of people. So pull quotes are a way to break up the text without resorting to vaguely relevant cat pictures.
But nearly no one ever uses it to refer to what is coming up, its almost always what has just happened 1 sentence ago.
> A lot of people have trouble with long runs of samey text.
nothing is more samey than repeating the same sentence!
pull quotes like how this article has,punishes the user for reading the article word for word. There are other methods that have the pull quotes outside of the flow!
And if it is a really important sentence, then throw some slight yellow background on the text or something, like a highlighter!
That's true if you read them inline, but pull quotes are generally presented in a large font so that you can see them without having actually read the accompanying text yet.
> pull quotes like how this article has, punishes the user for reading the article word for word, There are other methods that have the pull quotes outside of the flow, which I personally would prefer!
I agree with that. The pull-quotes on this site are poorly designed and really hurt the flow of the article.
A serverless system must scale dynamically per request.
FaunaDB is a globally distributed database that requires
no provisioning — you only pay for what you use.
I mean, if my attention sagged and I'm being brought back into engaging with the article via a pullquote, I at the very least expect the quote to at least pull me toward the relevant context.
Instead, way too many sites stick the pullquotes way after or way before the actual paragraph from which the quote was extracted, making it incredibly difficult to establish exactly what the context might be for that quote.
THAT'S ANNOYING AS
ALL HELL
I never tried (yet) but if I need something like Fauna then my assumption was wrong ?
For large organizations, I can see the benefit of moving to serverless particularly doing away with server ops for more slower and less frequent tasks..
but for fast response and cost effectiveness, unless AWS Lambda dramatically reduces costs to match a $5 / month digitalocean instance that will respond instantly and can take quite a beating for lighter requests, I'd be more wary-AWS bills can rack up very fast.
No maintenance except for watching for throttling by AWS, watching your billing to ensure it doesn't go out of control, watching for API Gateway errors.
Hey, more setup!
Theoretically, you could also do the entire setup via Cloud Formation; but you can also do the same with EC2 instances and ECS.
What would I do instead? Set up a 1-n member autoscaling group, with rules to scale on load. Set up an ECS service which auto scales on load. Set up an ELB attached to the ECS service. Not as fancy as Lambda and AWS Gateway, but it will probably scale better, at a lower peak cost (at the expense of an up front cost of one server).
It's beneficial because it's easy to spin up code and extremely cheap until you get load (so great for prototypes or MVPs), and it scales predictably. Yes, it can get more costly at a certain point than just running your own solution, but that point is less obvious than you think, and likely later (once you include the sysops tasks you need to take care of) than you think, and at that point you hopefully have enough of a revenue stream to be able to determine whether it makes more sense to move to servers, or to spend that time/money building new features.
Yes, no one of these is hard to do, and they should be things any engineer is familiar with. But -why are you spending your time on it-?
If your project is small enough, serverless allows you to spend all of your time on your actual code, not ops tasks, and -know- it will be trivial to scale, for the same amount of money.
If the project is large enough, the same thing applies; the ops tasks required for multiple boxes get more complicated, and serverless keeps you just focused on the code, with it scaling trivially.
In short, bear in mind the opportunity cost. If someone feels the ops work + cost of hardware < going serverless, fine. That's their decision. But to be dismissive of those who find it's a better value to go serverless, because they can iterate faster, because it's no more money at first, and only gets more expensive at scale (when they hopefully are making money, -and- have saved themselves the work of building an HA solution, as well as handling any unexpected shared state), seems misplaced.