191–200 of 323 posts
Earlier quoted context omitted.
in my experience it qualifies as "medium"
If it can be stuck in a sqlite database and run on a developer laptop, then no, it is not medium by any standard. Please elaborate why you think 50Gb is anything other than a small dataset that can fit in memory on any half-decent server though.
Earlier quoted context omitted.
> I'm not sure I fully grasp the problem (why doesn't DynamoDB need to be accessed from within a VPC?) This is due to the fact that DynamoDB's query API is a standard AWS API which means granular internal/external access can be provided through IAM mechanisms (ie: roles, temporary tokens, federation, etc.). On the contrary, to access RDS, Redshift or DocumentDB you would use standard ODBC/JDBC/Mongo facilities, which…
Not quite. It’s not the auth mechanism or even the wire protocol. The issue is to accesS traditional resources in a VPC you need to have an IP address within the VPV to route network traffic to/from it. It’d be the same if you ran a DB on and EC2 instance or even ran your own DynamoDB clone with no auth. AWS services don’t have that issue because they’re accessible from anywhere on the network, even through an intern…
Services with "native" AWS APIs use IAM for granular access management. Other services can only support access restrictions using the network so that means VPC/Security Groups.
Earlier quoted context omitted.
The linked blog sorts of hints at it, but the way out is to not try to build business models around people paying directly for some sort of license. Successful open source does not require someone making money off developing it. It is successful when it is something that helps a profitable company but is not core to their business; then, they benefit from making it open source and having everyone contribute to its de…
SSPL, the new license for Mongo, isn’t written to force developers already using Mongo to build apps to pay license fees. It’s designed to stop cloud companies from offering managed Mongo with closed service rigging. I suppose Mongo could sell exceptions to cloud companies, the way other companies dual license libraries or frameworks. But even Mongo’s bread and butter paid deals aren’t primarily about alternative lic…
Earlier quoted context omitted.
The client change would never work. The client is licensed as lgpl, so if they tried to pull any funny business like that, it would be instantly forked and if’d out.
As the person suggesting it, it's difficult to imagine how it could never work considering I haven't managed to figure out all the possible combinations in which such a strategy could be applied. Finally, it is quite exasperating to call this kind of strategy "funny business" in a thread about their core tech being ripped off by a megacorp
Earlier quoted context omitted.
SSPL, the new license for Mongo, isn’t written to force developers already using Mongo to build apps to pay license fees. It’s designed to stop cloud companies from offering managed Mongo with closed service rigging. I suppose Mongo could sell exceptions to cloud companies, the way other companies dual license libraries or frameworks. But even Mongo’s bread and butter paid deals aren’t primarily about alternative lic…
Right, but the point of the article the GP linked was that expecting a cloud company to pay for a license for add-on code... instead, they are just going to write their own versions to work with the open source parts.
The question is whether giants will pay the cost of reimplementing entire stacks, core and shell. I don’t have the time myself, so I’ll have to wait on a report about how compatible AWS DocumentDB really is.
Given AWS history, I’d expect they’ll get most of the popular functionality, most of the way, but gotchas will abound, and they’ll never hit 100%. Switching cost of code won’t bottom out unless DocumentDB takes lead mindshare, which closed clones rarely manage.
Earlier quoted context omitted.
It sounds like it is built on top of the Aurora storage subsystem that is used by both Aurora MySQl and Aurora Postgres[1]. I kinda expected them to build it on top of DynamoDb's backend and provide the same kind of "Serverless" on demand experience, but I guess the architecture didn't fit, or maybe this was just faster. 1. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
Definitely because it was faster. Amazon's strategy is to launch new features ASAP and then rely on everyone having to be on-call to fix shit when it inevitably breaks in prod because they rushed to launch. I will admit that while their "operational excellence" is shit, the security engineers do have quite a bit of power to block launches so their security isn't as bad as the reliability. However, the fact that write…
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.
as MS Cosmo DB prior, the compatibility list leaves quite a bit out.
Earlier quoted context omitted.
50GB is a really small data set.
in my experience it qualifies as "medium"
Earlier quoted context omitted.
The correct pricing strategy of any product is "whatever the customer is willing to pay for it". If you feel the price is too steep for your use-case, then don't buy it.
That's rarely actually true for anyone that wants to operate for more than a short time period. There are significant costs to gouging your customers. Anything from it being illegal, to it encouraging competition and your customers being motivated to actively flee you and shit on your reputation. The correct pricing strategy for people that don't have a long term enforceable monopoly is "whatever most customers are w…
Pricing strategy has little to do with customer happiness in aggregate. Every price will make some customers happy, and other customers feel gouged, because different customers extract different amounts of value from your product. The key to protect yourself from competition isn't to spend time worrying about how pricing affects your aggregate customer volume, but about whether your customers are happy. Maybe some customers are unhappy because they feel gouged. Maybe you could make them happier by reducing prices. But maybe, you're better off letting them go, if they represent a small minority of your users, and instead focus on what a majority of your users might appreciate more - better service, relevant features, etc. which make them happier.
Earlier quoted context omitted.
Definitely because it was faster. Amazon's strategy is to launch new features ASAP and then rely on everyone having to be on-call to fix shit when it inevitably breaks in prod because they rushed to launch. I will admit that while their "operational excellence" is shit, the security engineers do have quite a bit of power to block launches so their security isn't as bad as the reliability. However, the fact that write…
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.
The downside is that a lot of their products lack polish which sucks. On the flip side even when they are launched with minimal features, they do tend to be reliable, durable and secure, which is important when it comes to data related services.