AWS, Azure, and GCP respond to cloud report(cockroachlabs.com) |
AWS, Azure, and GCP respond to cloud report(cockroachlabs.com) |
I feel like cynicism/pessimism gets weird praise, too. The anthropologist Wade Davis considers it an indulgence and I wholeheartedly agree.
/tangent
That's basically the summary of Azure. I think all that complexity ends up hurting more than it helps, not just on the end user side, but in terms of lower reliability from the provider side.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I'm very excited about the possibility of moving to you guys, especially since it's a drop-in replacement for Postgres. The one thing holding us back today is postgis replacement. We rely heavily on it for location calculations and route path saving.
I've personally seen the reliability differences of services in Azure vs AWS for example.
Edit: I am a chump, I misread TPC_RR as TCP_RR and responded. Leaving this here for shame. Thanks to jsolson for pointing out my mistake.
I’m not sure if the post was edited, but TCP_RR is definitely not a typo. You may be more used to seeing TCP_CRR which opens a new connection and then a round trip, but for raw network latency netperf’s TCP_RR benchmark is probably the best tool available.
It’s like listening to failed beauty pageant contenders
There are many changes I would make to increase performance for one workload that would have a deleterious effect on another. An easy example is the dirty ratio in Linux - depending on the speed of your local storage, what the size of your working set of memory is, how frequently the data in the working set changes, keeping the settings the same across workloads and systems could be disastrous - it could result in extended periods where you are stuck in a synchronous flush to disk and block all other IO. That same setting on another server might be perfectly acceptable and prevent having to go to slower block storage devices sooner than necessary, increasing overall performance.
It's the same with how you configure your servers - you can throw more spindles at sequential workloads and have great performance, but a random workload really should be using flash storage, etc. etc. etc.
Most people strive to provide sane defaults that strike a good balance for the majority of workloads. This is going to be beneficial to the largest number of people. It's totally fair for someone to provide feedback on this sort of thing, and give details on how things could be further optimized to fit a specific workload. Defaults are not best practices - they are a starting point.
Everyone wants an easy button, and that might exist for something that's very well-established with a large community of users, at which point it probably just exists as an AWS service. For many things, you have to do research.
So the fun part here is, several options are viable, until you find this one issue where it doesn't work anymore. then you have to track back or find work around and check if the work arounds are acceptable or not.
And some of these limitations are usually not that straight forward to see and also to read about.
However, there are some resources like https://github.com/ahmetb/cloud-run-faq which are very good and helpful. Sometime official documentation doesn't really cover the questions that are important for your product.
Also, what i found without a multiples poc testing connectivity and the basic building blocks it is difficult to find all the gotchas, that might turn into blockers for a particular solution.
Worse, you're changing the equation constantly when you work on your features.
Finally when these things do happen, the server will protect itself in the interim. When it does that, things will be broken.
However, for newbies (or the scatterbrained), perhaps you could prefix the link with something like: "For context, see discussion of earlier, related post: https://..."