Euxodus is right. As long as you’re not building a product where the primary value of it is just delivering MongoDB as a service, you’re fine. There’s an FAQ that addresses that and more here https://www.mongodb.com/licensing/server-side-public-license...
I agree with you but this is an incredibly hard problem to solve. How are you going to get your friend to engage with videos that are in direct opposition to her world views? Recommendations are based on what she actually clicks on, how long she actually watches the videos, etc.
And from the business perspective, they're trying to reduce the likelihood that your friend abandons their platform and goes to another one that she feels is more "built for her".
A start would be to recognize that businesses are not allowed to exploit this aspect of human nature because the harm is too great to justify business opportunity.
It's easy to solve. FB gets to either be a platform for content or a curator for content. They can't be both because that would be a conflict of interest.
Then what's the business model? Who pays for all of it?
I'm not defending a specific approach or solution, but just pointing out that at this point, FB is a huge entrenched business that makes a lot of money on the status quo, and so convincing them to change "for the better" is barking up the wrong tree until "for the better" means "more profitable".
Splitting the platform and curation means the platform needs a revenue stream. If the curator pays the platform, then all you're doing is shifting the conflict up a notch, not solving it.
Mongo addresses this with partitioning and you can distribute partitions which serve local client applications anywhere. The database as a service for Mongo supports 66 regions across AWS, Azure, and GCP so write latency (regardless of where the client application is) doesn't become an issue.
It's absolutely an issue when multiple applications or users write to the same data from different locations, or when users move around.
If the application only lives in one place you are paying for the latency to reach the application from the remote client in the first place, even if the latency from the app to the database is "fast".
FaunaDB gives you local-latency reads and minimum global write latency from everywhere.
The commercial entities associated with the most popular open source technologies are taking measures to protect themselves from Amazon simply taking their software and turning it into a service, whether it's introducing proprietary components or new licensing. Wouldn't be surprised if we saw AWS do something similar for Redis, MongoDB, Kafka, etc.
> Wouldn't be surprised if we saw AWS do something similar for Redis, MongoDB, Kafka, etc.
They started on their own Redis fork a while ago as ElastiCache has had baked in SSL for over a year and half now. While it's possible they've added it via an stunnel type software stop it, I'd bet for efficiency and simplicity it's baked into their internal fork: https://aws.amazon.com/blogs/security/amazon-elasticache-now...
They already did their MongoDB-compatible NoSQL document database. Not sure what's under the hood but I assume an altered MongoDB engine adapted to their scalable cloud storage architecture.
It does, I've used it, I even have the socks, but it's a managed Database product. It's not equivalent to Firebase, AWS Lightsail, Digital Ocean One-click, etc. So a new MERN developer isn't going to gravitate toward that.
> It's just that there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS.
AWS's version will likely always lag on features, whether it's their Elasticsearch service or this new DocumentDB thing. So to continue the music industry analogy from the original article, sure Taylor Swift may or may not be able run the most reliable streaming service but she'll still get business if Spotify/Pandora only has covers of her songs.
A closer analogy would be “Spotify/Pandora cannot stream new albums for a period of X months” since AWS has the option to develop the missing features, and will if they’re requested by enough customers (AWS is extremely pragmatic when it comes to product roadmap). So, to strain the music analogy further: if you’re happy with the back catalog and you can wait a little bit to listen to the latest songs (say, while others test if they’re any good) then you don’t have to put up with the unreliable streaming service.
IIRC this strategy was tested by Jay-Z with little success. Taylor Swift also came back to Spotify...
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.
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 experience, it depends on the cluster size, but usually, I see cluster being up in 20m. That's nice given that it sets up pretty much everything (spin up instances, apply access policies, run health checks, enable cloudwatch monitoring, snapshots, create route53 records, integrate with cognito, enc-at-rest via KMS, spin up load balancers, setup vpc resources etc) on my behalf.
Actually not IO performance, but mostly CPU. Last time I tested (which admittedly was about a year ago), an AWS ES cluster was about 20% slower than a self-made cluster with the same instance types. Given that AWS ES clusters still cannot use C5 instances, which offer FAR better cost/$, the performance disparity today might be even larger.
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.
We have a history of losses and may not be able to achieve profitability or positive cash flows on a consistent basis. If we cannot achieve profitability or positive cash flows, our business, financial condition, and results of operations may suffer.
You're right they're not profitable — and neither is MongoDB — but the point is that AWS launched an Elasticsearch service 3 years prior to Elastic having a very successful IPO supported by stellar metrics (also found in the SEC filing you linked). So the statements made at the beginning of this thread are probably a bit premature.
Only in tech do people think that a money losing company is “successful” because they were able to convince investors to buy stock instead of defining success as having a business model where income is greater than expenses.
In reality long term profitability is the only metric that matters for a corporation
And in contrast to these startups with their "success" AWS is printing cash for amazon which releases surprisingly few "metrics" beyond $ in and $ out.
