Netflix Billing Migration to AWS • Hacker News Board

Re: Netflix Billing Migration to AWS

#121

Post by Annatar » Thu, Jun 23, 2016, 8:29 AM UTC

emcrazyone wrote: post #13

crisopolis wrote: post #5

At least they ditched Oracle (licensed)...

I worked at a Fortune-5 that was heavily invested in Oracle. Oracle has a nasty licensing model where they charge you per core regardless of if that core is a physical one or not (hyper-threading). While I was there, it suites told all the engineering managers that Oracle was out and the going forward solution was Microsoft SQL which, as I understand, has more relaxed licensing model. Another thing I'm wondering abou…

> Oracle has a nasty licensing model where they charge you per core regardless of if that core is a physical one or not (hyper-threading).

That's why you then switch to their T5 or M-series with up to 3,072 processors, and then Oracle comparatively charges you peanuts, since those systems have relatively few physical sockets. And if you know SPARC, and you know Solaris, you can squeeze some serious savings. The problem, it seems to me, is that most system administrators and managers today are neither familiar with SPARC nor with Solaris, so they end up paying more in the long term in licensing and maintenance for running something else like MySQL on GNU/Linux.

But that's their problem, not the guy's who knows SPARC and Solaris and how to save money, isn't it?

Re: Netflix Billing Migration to AWS

#122

Post by travmatt » Thu, Jun 23, 2016, 1:08 PM UTC

tomphoolery wrote: post #61

partiallypro wrote: post #36

I find it to be a peculiar business decision to completely (as much as you can) migrate to one of your largest competitors' cloud service. It seems like Microsoft is the only, of the larger cloud providers, that doesn't -really- compete with Netflix. (Google has YouTube, and I guess even Microsoft has a much smaller Windows Store presence.) Even if Amazon can't access the raw data, they could see how you're utilizing…

> Even if Amazon can't access the raw data, they could see how you're utilizing it to improve their own video service, and they get the benefit of billing you and potentially using their pricing leverage to squeeze your margins. So you're saying Amazon is going to risk millions of dollars so they can make a few more bucks on video streaming, which is like 3 levels down from their primary business? Prove it. I had an…

That was my first thought. Sabotaging one of the most conspicuous brands (and arguably their flagship customer) in the United States today sounds like an excellent way to commit business suicide - how many other tech companies would they cede to their competitors? Could a company ever defend using AWS again if they even tangentially competed with Amazon? Moreover, I bet that AWS is much more central to their long-term than Amazon video is. That just seems like a ton of risk for very little upshot.

Re: Netflix Billing Migration to AWS

#123

Post by kevin_b_er » Thu, Jun 23, 2016, 9:53 PM UTC

thramp wrote: post #79

ForHackernews wrote: post #15

Does this mean Amazon can mine Netflix's data to improve their Prime Video services?

Customer data is sacrosanct within Amazon. Cannot touch it without the customer’s consent. source: I work for Amazon Web Services.

Amazon already showed its hand at maliciousness when it blackballed all chromecasts from stores, including 3rd party sellers. I don't put suddenly blackballing netflix beyond amazon's consideration. Amazon is cutthroat with public customers, corporate customers, and with its own employees. I think netflix is stupid to put more eggs in the vulture's nest.

In fact, I can pretty much guarantee that at the first opportunity where the lawyers agree it is a usable hole, they'll try to kill netflix through denying it service. Taking out netflix for a week or two while the engineers rebuild the backends with a different provider would be excellent for amazon's video division.

Re: Netflix Billing Migration to AWS

#124

Post by tacticus » Fri, Jun 24, 2016, 1:32 AM UTC

niftich wrote: post #60

ihsw wrote: post #57

Earlier quoted context omitted.

Just to be clear -- their video streams are still served up via Netflix's OpenConnect appliances. The surrounding infrastructure -- everything "outside" of the play button -- finished moving to AWS. Their billing system has now joined its siblings in living on AWS.

Those being the colocated servers they give to ISPs? EDIT: yes. [1] [2] [1] https://openconnect.netflix.com/ [2] http://www.datacenterdynamics.com/content-tracks/colo-cloud/...

Also the cdn edges they run themselves.

https://www.youtube.com/watch?v=tbqcsHg-Q_o

very cool video.

Re: Netflix Billing Migration to AWS

#125

Post by runamok » Fri, Jun 24, 2016, 9:21 AM UTC

thwarted wrote: post #82

tomphoolery wrote: post #61

Earlier quoted context omitted.

> Even if Amazon can't access the raw data, they could see how you're utilizing it to improve their own video service, and they get the benefit of billing you and potentially using their pricing leverage to squeeze your margins. So you're saying Amazon is going to risk millions of dollars so they can make a few more bucks on video streaming, which is like 3 levels down from their primary business? Prove it. I had an…

But where does Amazon's primary revenue stream actually come from? That's right, it's AWS. Looking at Amazon's Q1 2016 Financial Results [0], page 8, we see that net sales of non-AWS amounts to ~$26B, and AWS is ~$2.5B. From the Segment Highlights section (same page), AWS sales is 9% of total sales. AWS beats non-AWS income only because there were losses in international; ignoring international, it's a $16m differenc…

Hell, the prime video player is far more buggy and error prone than the Netflix one at least on my media PC. So they can't even reverse engineer that well.

Re: Netflix Billing Migration to AWS

#126

Post by bpicolo » Mon, Jun 27, 2016, 2:46 AM UTC

Annatar wrote: post #118

bpicolo wrote: post #111

Earlier quoted context omitted.

MySQL is insanely performant for simple primary key lookups, and has a lot of good knowns. It also has fewer tripups for things like vacuuming, (pretty much requiring) pgbouncer, pgbouncer pooling settings... If you're doing things with replication logs, mysql replication logs are a heck of a lot simpler, and there's more tooling for them in the OSS world That said, I do use postgres a lot :)

> MySQL is insanely performant for simple primary key lookups, and has a lot of good knowns. MySQL is extremely buggy and silently corrupts data. It also does not enforce explicitly requested referential integrity, a core mandate of a relational database management system. https://www.youtube.com/watch?v=emgJtr9tIME MySQL lacks adequate authentication model (like OS authentication or SmartCard authentication in Oracl…

Video neglects to mention MySQL strict mode (which one should be using) and solves all these behaviors. They're explicit about this in docs, including what the default is: http://dev.mysql.com/doc/refman/5.7/en/server-configuration-...

Auth is a pretty aside argument. Those sorts of auth are not a particularly common use case. All sorts of auth can go in front rather than be built in, and if those don't apply, sure, might affect your DB choice. Not inherently a reason to not use MySQL though.