>This means we have enormous control over what is going on. The combined software meanwhile runs on databases and services which we also run ourselves. [...] A well known example is the Netflix streaming service, which consists of Netflix-owned hardware that streams stupendous amounts of video using very limited space in a data center. Netflix would simply not be economical if they did not have full control over the stack.
That blog paragraph presents an incomplete and inadvertently misleading architecture of Netflix.
Netflix actually uses AWS and is very much "locked in" to Amazon's cloud ecosystem. The specific item the author is talking about is the Netflix CDN "appliance" that is installed at edge datacenters. However, those appliances can be seen as a "dumb box". The "smart management" of the CDN is controlled by Netflix code deployed on databases and servers at AWS. Also, the Netflix customer accounts, billing, recommendation systems runs on AWS.
I would summarize my experience of different cloud technologies as follows:
Good: EC2, Route53, S3, identity provider (IdP)
Bad: Functions as a service, hosted SQL, weird SQL, elastic anything, containers, logging, reporting, billing, IoT, CI/CD, business apps, event-based services.
I used to consider IdP to be a "bad" cloud technology until I realized it's a trust problem and not a technology problem. I don't want to be responsible for a trust problem. The other parties involved in my contraptions seem to appreciate this perspective.
junto · 39m ago
I’d probably tend to be ok with the standard hosted SQL, since replication is kind of built in to most databases so getting out isn’t much of an issue. However migrating away from a cloud specific IdP is much harder and has some serious lock in.
spilldahill · 46m ago
You can really feel the tension between short-term shipping and long-term survivability here. The incentives almost always push toward deeper integration today, and someone else deals with the migration crisis five years later. ...honestly, just having basic rules like "only use cloud services that have open equivalents" would save a lot of pain later, but it feels rare to see that kind of governance actually enforced.
That blog paragraph presents an incomplete and inadvertently misleading architecture of Netflix.
Netflix actually uses AWS and is very much "locked in" to Amazon's cloud ecosystem. The specific item the author is talking about is the Netflix CDN "appliance" that is installed at edge datacenters. However, those appliances can be seen as a "dumb box". The "smart management" of the CDN is controlled by Netflix code deployed on databases and servers at AWS. Also, the Netflix customer accounts, billing, recommendation systems runs on AWS.
https://www.google.com/search?q=netflix+AWS+manage+CDN
Good: EC2, Route53, S3, identity provider (IdP)
Bad: Functions as a service, hosted SQL, weird SQL, elastic anything, containers, logging, reporting, billing, IoT, CI/CD, business apps, event-based services.
I used to consider IdP to be a "bad" cloud technology until I realized it's a trust problem and not a technology problem. I don't want to be responsible for a trust problem. The other parties involved in my contraptions seem to appreciate this perspective.