301–310 of 323 posts
Earlier quoted context omitted.
DynamoDB is written on top of MySQL (more specifically, MySQL's storage engine, not the query engine) so using Aurora which has a newer design would make sense.
People downvoting one of the guys who worked on DynamoDB at Amazon, somehow thinking they know better. HN in a nutshell.
Earlier quoted context omitted.
Same here. We love how replication is built in to CouchDB from the ground up. I wish MongoDB, which seems to still have more love for it in the world than CouchDB/Cloudant, would have that replication built-in.
Wait... do you mean something other than https://docs.mongodb.com/manual/replication/ ?
Whereas, Mongo only built support for classic RDMS-style replication where one database serves as the master or primary, and any number of secondaries can try to keep up with it.
It's a bit like SVN versus git. Mongo when replicated still has the SVN centralized mentality, whereas CouchDB is a lot more like git.
Compare Ref: http://docs.couchdb.org/en/stable/replication/intro.html
I was reading a post [0] by Brian Cantrill that predicted this would be the result of licences like the SSPL. I instinctively disagreed with him, but it turns out he was right: "The cloud services providers are currently reproprietarizing all of computing — they are making their own CPUs for crying out loud! — reimplementing the bits of your software that they need in the name of the service that their customers want…
Years ago I realized that a hidden driver for the growth of cloud is this. The cloud is DRM, and almost uncrackable DRM at that since you have neither the code nor the hardware.
The code needed to run those servers is the secret sauce and a huge competitive advantage, but with open source software you're giving away the secret sauce and the business victory goes to the one with the most business friendly servers
(There are many dimensions to "business friendly", a big one of which is "it's easy for us to start using this additional service since we're already paying this company for other services")
Earlier quoted context omitted.
> it requires an elastic IP which slows launch of lambdas since they have to connect to VPC Do you have any other info/links related to this?
There's an enlightening graph in this post: https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-lat... I was surprised to learn this. When working in Lambda, you have to choose between a relational database & a responsive API. It seems inevitable that AWS will fix this soon, but apparently this is a significant architectural problem. As I understand it, RDS instances should (must?) be accessed from within a VPC,…
TL;DR: RDS and this new DocumentDB are essentially AWS managing your database VMs in EC2. Advantage is drop in compat with regular apps expecting to reach a local server, because it is local to your VPC and uses normal ports. Can make them public accessible via VPC firewall, but less secure that way. DynamoDB was designed from the ground up as an HTTPS API and that's the only way its accessed.
Earlier quoted context omitted.
An API is just a collection of facts of the form, "if the system gets input X, the system produces output Y". And facts shouldn't be copyrightable.
You could describe inventions as "facts" too, are you saying that inventions shouldn't be patentable as well? Maybe the fundamental properties of the universe aren't copyrightable/trademarkable/patentable, but what you CHOOSE to do with those - what API you design or what widget you build out of it certainly is.
Earlier quoted context omitted.
It seems a bit wrong if you have a 18TB table but no idea what it contains...
It was a temp table that we hadn't garbage collected yet. We don't make a habit of leaving that much junk data around, but it bumped our monthly storage bill several percent, not like tripled it.
Earlier quoted context omitted.
This is hopefully a good counterexample. Amazon's Elasticsearch Service is pretty bad (poor general performance, very slow to make cluster changes/launch new clusters, etc). But I can't help but think Amazon can and would easily fix those things if they mattered. Amazon's hosted Elasticsearch is a lot cheaper than Elastic's, and I'll bet that's enough to get people to use it.
> poor general performance By poor performance, I assume you mean IO? AWS Elasticsearch has supported i3 instance type (nvme on-instance storage) for well over a year now [0]. Additionally, you could enable slow-logs to catch perf issues yourself [1] > very slow to make cluster changes Scale-out and access-policy changes happen in-place now and so happen much faster than they used to be. > launch new clusters In my e…
I can also launch an Elasticsearch cluster myself in about 2 minutes via terraform, so 20 minutes is not super impressive.
That said I recognize Elasticsearch is actually quite a finicky beast to set up, and my setup only has to deal with the needs I have, and probably would be set up horribly for certain other people. I can see how a hosted system that has to deal with all the weird edge-cases of a few thousand customers would take longer to set things up.
Earlier quoted context omitted.
AWS prioritizes launch above EVERYTHING. It is their strategy, to have market tells them what to build. I think it works, and AWS has yet been brought down by this horizontal complexity. Quite an achievement, but might not be a satisfying experience for the engineers work there.
This is one of the main reasons why I don't like AWS services, everything just seems so half-finished. There's not a lot in AWS that I would trust enough to use in production. I wonder how widespread this view is. I suspect it's more widespread than Amazon realise. They may have optimised into a local maximum where they get a lot of value from being first to market, but could potentially get more by being first to "v…
Earlier quoted context omitted.
They always were the OK guys in that argument. Google invented a whole new VM and bastardized the language just to get out of a $1/device licensing fee for mobile uses. The Java ecosystem has been irreparably harmed by Dalvik and its lack of support for more modern versions of Java. On another note, anyone that doesn't think API design is a creative endeavor and worthy of protection probably has never made a great AP…
> The Java ecosystem has been irreparably harmed by Dalvik and its lack of support for more modern versions of Java. So if ReactOS gets popular but doesn't support Windows 10 APIs, will it be harming the windows ecosystem? If popular implementations of a tool exist that don't chase other (official or not) implementations' features but still get lots of users, that probably means that the popular implementations provi…