That's core functionality, not analytics. Nearly all of that is browsing, ordering, location updates, etc. The dismissive comments are amusing and show a lack of understanding of how the business works and, subsequently, the technology required to power the end-to-end flow for users.
I wish articles such as this would also talk about the risk-adjusted cost of absolute data safety or provide treatment discussing the cost of ensuring the last 0.00001% of data is unconditionally guaranteed in the event of black swan events. For example, what's better for the business? Double EC2 operating costs from $100K/mo to $200K/mo or pay out $10K in credits/yr as a direct loss to the business plus whatever the reputational or regulatory cost? Sometimes you need 100%. Sometimes you don't. Not acknowledging this tradeoff makes the article very FUD'y and is a disservice to engineers who get sucked into black-and-white thinking.
At this point, esp with the upcoming 22.2 release, nearly all failure modes are handled on a machine timescale. There used to be some unbounded failure scenarios that you could run into where a human would have to kick a node, but to the best of my knowledge, they have all been resolved, and unplanned failures are bounded to about 10s now.
One of the bigger burdens from large fleets like this is fleet management and maintenance, specifically managing upgrades. If you have a story around that, you're in good shape.
Most of the excitement comes from moving workloads onto crdb from PG, where it's not uncommon to have workloads with right-leaning indexes or workloads. This class of problem is solvable, but it will catch some people by surprise.
At the end of the day, having a database that can absorb punishment from as small as a few dozen QPS up to millions of QPS is a big reliability win, esp with the self-healing characteristics of the database technology.
To be clear, you can use CockroachDB if you're a service.
What is prohibited, however, is you can't take CockroachDB and try and offer a hosted CockroachDB-as-a-Service to external organizations.
But if your organization has a DB-as-a-Service offering internally, you can totally add crdb to the mix (this is pretty common, as a matter of fact). If your org offers a service and its backed by crdb, you can totally do that, too.
Supposedly this feature is being walked back now. I just received the following from their support. I'm ecstatic to hear this and hope their Product Management has reassessed the importance of non-WYSIWYG inputs.
>>>
We really appreciate your feedback, and we hear your frustration. We're sorry for the impact this is having on your ability to communicate with your team and on your overall productivity. We made a mistake by forcing everyone into this feature without providing an opt-out for customers like you: people for whom the existing behavior was working just fine.
We've started working on a preference that will let you return to the previous message composer. We don't have a specific release date to share right now — it's this team's top and only priority, however, and we expect to have it available on the desktop within a couple of weeks, with Android following shortly thereafter.
We will follow up with another note when this option is available to you, and we'll include instructions on how to enable it.
Again, we're sorry for the disruption and we're grateful for the feedback. We missed the mark on this feature! We will do our best to learn from this and avoid similar mistakes in the future.
I just received this from Slack support and want to table flip.
> I'm afraid there isn't a way to revert to the old formatting method. We don't currently have plans to make the new formatting configurable though we are carefully considering all our customers' feedback.
The best talk I gave on this wasn’t recorded (and had another section on the details of the new MBUF struct that mmacy came up with), but here are a few pointers for the time being:
The FreeBSD/VPC hypervisor efforts ran into a few “corporate speed bumps.” A few folks, myself included, are working to merge this code and make it generally available. The FreeBSD hypervisor effort certainly was the best systems work I’ve seen in my life, especially in such a short amount of time and given the resources at our disposal. My favorite anecdote was that the internal first-pass review of the benchmark data was that we had cheated because we had “exceeded the laws of computer science physics” when we saturated 100GE with VXLAN encap’ed guest traffic with no hardware acceleration, and we were only using a half a CPU core. If someone asked me to do this type of work again I’d use FreeBSD as the base again in a heartbeat. Good systems engineers are invaluable. Working from a solid technical foundation is equally critical, so is the community.
The control plane work likely won’t be made available (it was Linux specific, anyway). :-/
As for both the FreeBSD work and control plane work, it was good times, good memories, and a great team while it lasted.