I agree. If you can reliably recover from failures by migrating instead of restoring from checkpoints, then the need to checkpoint frequently becomes far less important and reduces the overhead of taking checkpoints. Similarly, a lot of users are experimenting with asynchronous checkpoints to reduce the blocking penalty, but there are big tradeoffs there with DRAM usage. So being able to take checkpoints far less frequently gives you more flexibility on the type of checkpointing you use as well.
What's amazing to me is that without reading (watching?) too much into it, and me not being a seasoned South Park viewer, this could easily pass as a real episode.
Essentially NY City is making short term rentals (rentals < 30 days) illegal for most renters. The only exception is a room without a lock, for up to 2 people, in a residence that has shared living space and is occupied by the owner.
Unfortunately it's more restrictive than just owner-occupied units. It's essentially an unlocked room (for up to 2 people) in someone's house/apt that includes shared living spaces.
For example, there are many multi-family houses where a family lives upstairs but can't rent out the downstairs apt.
Worth a read if you've ever used Airbnb for a short term stay in NYC (or if you're an Airbnb host). The City of NY is about to start enforcing a ban on short term rentals on Airbnb, VRBO, etc.
Gavin from Zebrium here. We've found that if only you somehow knew what you were monitoring for in logs, they can be a great source of detecting (and then describing) the long tail of unknown/unknowns (failure modes with unknown symptoms and causes). Our approach is to be able to find these patterns in near real-time using ML. This blog by our CTO explains the tech with some good examples: https://www.zebrium.com/blog/is-autonomous-monitoring-the-an....
Gavin from Zebrium here. Completely concur with #1. We are big advocates of writing good logs and not having to worry about structured vs unstructured (and even if you structure your logs, you'll still probably have to deal with unstructured logs in third party components).
We love Litmus because it gives our users a way to quickly and deterministically inject failures into their app so they can test the effectiveness of our solution.
Gavin from Zebrium here. Thanks for doing such a great job with this. I played with an earlier version of this and it's come a long way. I love how you've made it really easy to setup and run experiments with the Litmus Chaos Engine (https://litmuschaos.io/).
Gavin from Zebrium here. Again, we understand this concern. All data is encrypted in-flight and at rest and we have a lot of security controls in place (see our website). We also have the option of a dedicated VPC assigned to a single customer. Beyond this, we have a unique capability: since our machine learning structures and types everything, we have a feature that lets us hash (or delete) any sensitive information in logs (and we can record match to find other places this info occurs that you might not even be aware of). Not dodging the fact that we're SaaS, just pointing out what we do.
There is a trend towards not testing at all! Instead builds are deployed straight to production or canary (mini-subset of production) and then very carefully and closely monitored. If a problem is uncovered, a rollback is performed. If canary is done well, then the problem can be caught before it has widespread impact.