Uploaded March 2019 | Updated September 2026, 1 week ago
A recent tweet called out a user's perception about Grammarly, a SaaS-based grammar and writing tool. They accused the service of being predatory (due to it's license) and a keylogger. While the points are off base (but not insanely so), they do raise a bigger issue: the user perception about a service vs the actual privacy risk.
When you use a cloud-connected service, do you truly understand the boundaries of where you data and data about you exist? Do you know what is being sent to the service's backend and how that data is being managed?
In my experience, most people don't understand the technicalities, nor the potential impact to their privacy.
References;
- the originating tweet, twitter.com/sebmck/status/1104132993893904386
- Grammarly's ToS, grammarly.com/terms
// MWM Y2 no. 018
A recent tweet called out a user's perception about Grammarly, a SaaS-based grammar and writing tool. They accused the service of being predatory (due to it's license) and a keylogger. While the points are off base (but not insanely so), they do raise a bigger issue: the user perception about a service vs the actual privacy risk.
When you use a cloud-connected service, do you truly understand the boundaries of where you data and data about you exist? Do you know what is being sent to the service's backend and how that data is being managed?
In my experience, most people don't understand the technicalities, nor the potential impact to their privacy.
References;
- the originating tweet, twitter.com/sebmck/status/1104132993893904386
- Grammarly's ToS, grammarly.com/terms
// MWM Y2 no. 018








![Can We Improve How Netflix Handled Failover Using DNS In 2017? (Reaction)
In late 2017, Netflix did an AWS This is My Architecture video. It was one of the first. In the video they explained how they tackled the problem of failing over when disaster struck.
Specifically, they drilled down on a clever use of DNS records to create a very flexible system that allows services to continue in the event of some pretty significant disaster.
Few companies operate at Netflixs scale (even their scale back then) but this technique is broadly applicable for any team that needs to failover in the event of either disaster or even a simple failure.
Now, a few years later, I react to that video and see whats stood the test of time, what could be done simpler given todays technology, and generally critique the design against the AWS Well-Architected Framework in a mini AWS Well-Architected Review.
The original video: https://youtu.be/WDDkLOT8SCk
More on the AWS Well-Architected Framework is at https://aws.amazon.com/architecture/well-architected/
Follow me on Twitter at https://twitter.com/marknca
Read my AWS Hero bio at https://aws.amazon.com/developer/community/heroes/mark-nunnikhoven/
Learn more about the AWS Well-Architected Framework in my course on A Cloud Guru at https://markn.ca/courses/#mastering-the-well-architected-framework
Index:
- [00:00] Intro
- [00:24] Problem statement
- [02:10] Evacuating a region
- [03:10] Geo-routing
- [04:39] Intelligent failover
- [06:11] How a failover works
- [07:26] Record choice
- [08:13] Restoration
- [09:10] Tracking state
- [10:03] Can we improve? Can We Improve How Netflix Handled Failover Using DNS In 2017? (Reaction)](https://i.ytimg.com/vi/OJbOcYVy1wk/mqdefault.jpg)

