Netflix & 百視達的戰爭史(上)

你有沒有過這個疑問:人家說百視達輸給 Netflix 是因為固守門市不知變通,但百視達也不傻,一樣推出線上租片不就能跟 Netflix 一決高下了嗎?門市是否真的如此沒價值?
評論
評論

本篇原文刊登於作者 medium,INSIDE 經授權轉載。

你知道嗎?Netflix 曾經向百視達提議併購,但被百視達嗤之以鼻。

你知道嗎?亞馬遜以及沃爾瑪都曾加入線上租片的混戰當中,但 Netflix 存活下來了。

你有沒有過這個疑問:人家說百視達輸給 Netflix 是因為固守門市不知變通,但百視達也不傻,一樣推出線上租片不就能跟 Netflix 一決高下了嗎?門市是否真的如此沒價值?

百視達一手好牌怎麼打成這樣的? 

最近看了這本書 NETFLIX:全球線上影音服務龍頭網飛大崛起 ,對 Netflix 與百視達之前的纏鬥印象深刻,事實上 Netflix 與百視達都發生過致命錯誤,百視達也曾差點翻轉戰局,在當時的情境下,其實很難看出鹿死誰手,在這裡整理成戰況紀錄,並討論我從裡面學到什麼。因為文章很長,所以分成上下兩集。

回合開始:1997 年網飛創業,百視達如日中天

「據說」網飛的創辦,是創辦人哈斯汀因為忘了還百視達片子,而被迫繳納 40 美元的滯納金,所以他一怒之下創辦了線上租片的網飛。

事後網飛證實這只是網飛包裝自己的一個故事,但這個故事還是相當成功,一方面有小蝦米對大鯨魚的戲劇性,另一方面激起許多有類似經驗的人的認同,還成功宣傳了商業模式!

但其實網飛一開始創立時還是舉步維艱,是百視達連連的大意,才讓小蝦米得以崛起,創造今日帝國。

第一個轉捩點:DVD 還是 VHS?

網飛 1997 年創立,原本當然是個默默無名的小咖。但是新公司也有新公司的好處,就是沒有包袱。

1997 年 DVD 與播放器在美國推出,但是百視達等大型租片公司因為既有庫存是 VHS,所以不願意提供 DVD 選項,網飛一開始就提供 DVD,1998 年夏天,網飛隨著 DVD 普及搶得先機,甚至電視節目會介紹:要看最新的 DVD,找網飛就對了,網飛打開知名度。

網飛第一勝。

接著, 網飛找到 DVD 播放器廠商,抓住了他們的痛點 :消費者不願意購買播放器,因為商店普遍不提供 DVD;商店不願意庫存 DVD,因為播放器不夠多。網飛利用「出租 DVD」的商業模式,解決了這個兩難,因此成功讓 DVD 播放器廠商願意在出貨時,在播放器包裝箱內夾進網飛免費優惠券。網飛藉此打開知名度與正確的 TA 目標客群。

網飛再一勝,level up!

但是免費優惠券的方式造成網飛巨大成本(庫存及郵寄勞力成本,並不是網路產業就是無限複製零成本的),且大部份消費者使用完免費優惠券之後,並沒有轉為消費的顧客,他們燒錢卻綁不住顧客,加上優惠券序號被複製,網飛系統尚未準備好處理作弊,所以錢燒得更快。1998 年,網飛虧損一千一百萬美元。

網飛找不到賺錢方法,陷入危機。

同時,第二大租片商好萊塢影視,併購了擁有廣大 VHS 庫存的線上租片平台 Reel.com,兩者發揮綜效產生巨大線上流量,成為網飛強勁對手。

網飛 HP 再減 10

第二回合,網飛從數據著手,接連推出幾項改進:

在這樣的劣勢之下,網飛在網站上不停嘗試不同方案,並小幅 A/B 測試,找出消費者反應好的方案:

  1. 到貨時間 :數據顯示顧客喜歡越快到貨越好,所以網飛依此設計物流系統與倉儲地點,達到隔日到貨。
  2. 大幅改變租借行為 :從前的租借是單片影片,固定租期,網飛改為「吃到飽」--付 15.95 月費 ,手上可同時保有 4 部影片,沒有觀看期限,還一部就能再借下一部,這個方案大受歡迎。

網飛訂單大爆發,網站業務量成長 300%,每週十萬張光碟出貨。

網飛補血,開始再戰。

1999 年,影片格式之戰 DVD 勝出,Reel.com 虧損嚴重,好萊塢影視退出,損失 4,850 萬美元。(所以並不是線上租片就一定能顛覆傳統租片市場,也許這個失敗案例也是造成百視達對線上租片躊躇不前的原因)

網飛再一勝,但燒錢至今虧損 2,980 萬美元。影片庫存成本成為嚴重問題。

2000 年,工程師寫出影片推薦引擎 Cinematch,利用影片評分與分類,推薦使用者類似影片,引導使用者避開熱門片,租借較冷門的老片。(其實概念是向 Reel.com 學來的,但網飛的演算法把他發揮到極致)

網飛一勝,並奠定了非常重要的基礎。

2000 年,網飛估計將虧損 5,740 萬美元,因此決定找百視達結盟,並建議百視達用五千萬美元收購網飛,被嗤之以鼻。

此時,百視達有五千萬註冊用戶,網飛只有三十萬。

(百視達驀然回首,是否覺得後悔莫及?)

第三回合:百視達發現門市收入下滑,請來「翻盤專家」安提奧科大改造

百視達也不是省油的燈。在注意到網飛之前,他們已經注意到門市的收入與會員數逐漸下滑,因此也很有危機感地請來了曾經拯救多家瀕危企業的「翻盤專家」安提奧科。安提奧科的表現很精采,讓百視達這場仗「差點」就翻轉了,看到最後結局讓人不勝唏噓阿。

安提奧科首先改造門市,抓住客人痛點,改善服務體驗,並增加新熱門影片庫存,提出「保證租得到」口號,成功讓租片收入增加 13%,活躍會員增加 7%。

百視達一勝。(其實目前為止百視達並沒有把網飛做為對手)

然而,當時安提奧科請研究機構分析線上租片的潛在機會,得出的結果是線上租片市場最多只能容納 360 萬個用戶,相較於百視達五千萬的訂戶而言,安提奧科判斷線上租片市場不值得考慮。

百視達錯失先機。

但安提奧科用另外一種方式考慮了「線上」這件事:他與某 EBS 公司達成使用 DSL「將影片高速傳輸到用戶家中」的協議,但當時影片庫存量不足,消費者滿意度不高,所以不了了之。接著,安提奧科又想使用機上盒將數位內容傳輸給電視,當時也沒得到太大回響,只能說雖有遠見,但是「太早」,技術與消費者端尚未成熟。(這個 EBS 是著名安隆案的安隆子公司,不了了之反而逃過了一劫。)

接著,安提奧科決定將百視達的 VHS 庫存全轉為 DVD。短期雖有成本,但長期利潤率提高,收納空間減少,也更符合客戶需求。

百視達正在尋求自己的改變,但並未將網飛與線上租借視為重大威脅。反觀 2001 年九月,網飛燒錢速度太快,決定裁員 40%,創辦人之一也走了……

目前還是百視達占盡優勢。

百視達線上與門市的路線之爭

2003 年初,網飛宣布達到百萬訂戶,安提奧科開始關注線上 DVD 租借。

百視達以一百萬美元併購一家小型線上 DVD 租借公司(初期還不願意投入太多成本,因此只是個嘗試性的便宜併購),卻發現網站規模根本無法容納千人以上,但 安提奧科還是決定用網站來做為試驗,研究周轉時間、客戶行為,和獲取客戶的成本,並和店鋪資料結合,交叉比對

然而,統計結果發現,線上租片用戶仍然喜歡店面租片,且線上訂戶取消比例高﹑利潤低。但多年後的事後回顧他們發現,可能是因為統計與解讀方式的錯誤,低估了每個訂戶會有的平均收益,且他們 針對「百視達店面的客戶」 研究也顯示,大部分客戶沒興趣上網租片(這樣本偏差很大阿......),因此百視達再度低估線上租片潛力。

然而,安提奧科手下大將伊凡吉利斯(才 28 歲!)有不同看法,他 針對「網飛的客戶」 進行調查,發現客戶忠誠度破表,因此讓他認為線上租片服務對百視達擴大市佔率相當必要,所以強力建議開始推行。

他成功在某些百視達門市區域開始試行線上訂閱方案,並嘗試整合門市及物流,但遭遇門市的重重阻礙。2003 年年底,百視達「門市還是線上」的路線之爭越演越烈,最後,安提奧科給伊凡吉利斯一筆資金,讓他獨立運作,但不能干擾門市業務。

伊凡吉利斯在半年內,直接山寨網飛網站做出了「百視達線上」,也用各種方式接觸網飛的顧客,瞭解他們怎麼做線上租片的,並用驚人的速度複製。

看似百視達線上會成為網飛強勁對手,因為百視達有強大的資源、片源與客群,然而, 百視達線上不但無法使用既有資源,反而總公司處處阻撓 :百視達門市所有的客戶名單均不開放給線上行銷部門使用,且百視達線上的行銷,不能使用對百視達門市有傷害的語言,例如「無滯納金」的說法,有批評百視達門市收滯納金的意思,所以不能打出來,甚至百視達線上與其他網路公司(雅虎,亞馬遜)的合作,也遭到母公司法務的層層嚴苛要求阻撓。

然而,網飛在這個時候犯了個大錯:決定提高訂閱價格。

由於網飛的訂閱人數穩定上升,甚至超過原本的預期,因此他們認為是時候能盡快變現,結束虧損的狀態,因此決定將價格抬高到每月 21 美元。但這一方面給了百視達線上一起抬價的理由,另一方面,根據百視達線上的研究,客戶願付價格的上限是 20 美元,因此他們將價格設為低於 20 美元,果然開始吸引客人。

我很喜歡伊凡吉利斯的自我定位: 他們不是想打敗某個小公司的百視達,而是一家新創公司,正在追趕一個技術卓越,經驗豐富的對手。

而他們目前正在全力追趕。 百視達線上扳回一城。

插曲:華爾街狙擊手攪局

要說百視達是敗給網飛,不如說是敗給自己以及華爾街。

這部分不是我想強調的重點,所以我簡短總結:安提奧科有個策略是要減少市面上浮泛的門市數量,所以他計畫併購市占第二名的好萊塢影視,再總體汰弱扶強,只留下業績好的店面。

但這個併購案吸引了金融狙擊手,叫做伊坎,他慣於大量購買股份,成為決策影響者,再讓公司跟他溢價買回股份,或出售公司賺取差價。他也大量購買了百視達的股份,想從併購案中撈一筆,安提奧科很討厭這種人,所以對他態度非常不好,兩人劍拔弩張,之後,他們兩方都會後悔的......

第四回合:安提奧科取消門市滯納金

「滯納金」一直是百視達為人所詬病的機制,這也被網飛拿來死命攻擊,然而,這卻是極龐大的利益,因此雖然百視達知道客戶對此很不滿意,還是繼續保留這個制度,直到安提奧科經過許多市場調查之後,決定狠下心來取消,以挽救流失的門市會員。

然而,此舉當然受到門市加盟商強大的反抗。這些加盟商已經從滯納金賺錢太久了,門市會員流失,收入已經減少了,再取消滯納金,不就又少賺一筆錢?因此最後百視達使用很沒誠意的折衷方案:不收滯納金,但是收「重新上架費」,且有許多的加盟門市還是不願意參加這個方案。

結果還引發了詐欺訴訟,因為實質上並沒有取消滯納金……

百視達股價大跌,狙擊手伊坎槓上安提奧科,安提奧科只好分神對付伊坎,網飛樂見其成。

百視達一敗。

==

才寫到中間,發現我已經寫得太長了,只好先到這裡打住。

接下來還有--

插曲:亞馬遜加入戰局,可怕的對手,但……

第五回合:價格大戰開打,誰的錢比較快燒完?

第六回合:一高還有一高高

第七回合:百視達線上終於找到出路,絕地大反攻,加上另外一個競爭者竄起……

最終回:百視達即將反轉,但在最後一刻......

最後,我會分享我在這場戰爭中學到的事情,這場戰爭真的太精彩了,很值得大家期待下集(自己說)。

最新更新:下集寫完了!請拍完手再去看喔 XD

 

開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

打造第一個在 AWS 上的應用程式

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!