專欄

【葉郎串流筆記】猛開外掛為哪樁：開商城、做遊戲、錄Podcast的 Netflix

Netflix 近期招攬了 Apple Podcasts 的節目策劃主管來做語音領域主管、待過 EA 和 Zynga 的 Facebook AR 和 VR 內容副總來負責遊戲產品，先前還陸續嘗試期刊和社群服務、周邊商品電商⋯⋯ Netflix 大步跨出影視內容領域，到底打什麼算盤？
評論
REUTERS/達志影像
評論

今年以來全球串流市場龍頭 Netflix 三番兩次在人才市場上被抓包企圖跨足其他領域產業的蛛絲馬跡。明明串流市場大好，為什麼 Netflix 偷偷在找新工作？

人才市場上的蛛絲馬跡

首先是今年三月眼尖的洛杉磯時報發現 Netflix 開出了語音和 podcasts 的主管職缺，列出來的條件是希望找到一個有能力「對於 Netflix 在 podcast 領域的增長創造願景和執行方案（”the vision and implementation for Netflix’s growth in the podcast space”）」的人才。稍後七月初的新聞則確認應徵上該職缺的是 podcast 市場領頭羊 Apple 裡頭原本主管 podcast 節目策劃的主管 N’Jeri Eaton。

緊接著是今年五月科技媒體 The Information 報導了 Netflix 正在到處尋找遊戲領域的資深主管，希望能加入該公司帶領團隊打造一個類似 Apple Arcade 的遊戲訂閱服務。這個職缺後來同樣在七月找到人，而且還是遊戲領域有名有姓的老將——先後待過 EA 和 Zynga 的 Facebook AR 和 VR 內容副總 Mike Verdu ，確定將投靠 Netflix 負責遊戲產品開發。

如果再加上一年多前 Netflix 開始嘗試的報紙式期刊 《Queue》 、今年五月在市調問卷中透露的一個籌備中的社群服務 N-Plus ，以及今年六月閃電開設的周邊商品線上商城，這家市值 2600 億美元的串流第一品牌已經在短短一年多內連續幾次開外掛，將資源挪去做串流本業以外、無關訂戶增長的開發項目之上。為什麼？

最容易用來推理的線索是財報。歷經 2020 年 COVID-19 疫情帶來的爆炸性業務成長之後，今年第一季 Netflix 的疫情紅利隨即踩了緊急煞車，尤其是競爭最激烈的北美市場當季甚至整季只有 45 萬新訂戶。到了第二季，Netflix 北美市場的訂戶數甚至出現史無前例的赤字，不但沒增加，還一口氣掉了 12.6 萬人。

於是許多人開始大膽推論 Netflix 預期到訂戶人數即將撞到天花板，所以今年才會採取一系列動作開始積極拓展遊戲、podcast、周邊商品等新業務，希望這些業務帶來的新營收可以補上串流的成長缺口。甚至有媒體直接以「串流巨人跨足電商搾營收」來形容這個業務上的急轉彎。

問題是電玩是一個錯綜複雜而需要很長學習曲線的陌生行業，並不是 Netflix 花錢請個資深主管就可以立刻開門做生意。風起雲湧的聲音經濟 podcast 市場也是。歷史更悠久的影視周邊商品市場更是如此。除了擁有 IP 可用之外，Netflix 在這幾個領域並沒有太多 know-how ，也見不到其他競爭優勢。

「開發新營收來源」很可能只是一個幻覺，是 Netflix 隨手賣給股市投資人的夢（這就是為什麼他們在數字最難看的財報發表時機同時宣佈進軍遊戲業以及開設周邊商品商城）。

回到串流龍頭的既有角色扮演之上， Netflix 的這些外掛投資必須仍對本業有直接助益。

But how？

從防堵 HBO 到防堵 Disney

「我們的目標是在 HBO 變成 Netflix 之前先變成 HBO」（ "The goal is to become HBO faster than HBO can become us."）

2013 年 Netflix 首部自製電視劇《House of Cards 紙牌屋》上架前幾天，當時的內容長（現在的共同執行長）Ted Sarandos 這麼告訴 GQ。Sarandos 把 HBO 當成首要敵人的正當理由是《Game of Thrones 權力遊戲：冰與火之歌》。

此時此刻我們正處在一個被電視從業人員稱為 Peak TV 的電視黃金時代。史無前例的資金和人力正在急速湧入電視內容生產端，以便產出史無前例數量的電視內容。然而並不是 Netflix 或是《紙牌屋》開啟了 Peak TV。電視黃金時代其實始於 HBO 的《權力遊戲》。

《權力遊戲》帶給電視產業的是更高的拍攝規格、更多的特效、更貴的成本、更無止盡的續集和延伸宇宙。某種程度上是把電視劇的產業邏輯變成了好萊塢電影工業的翻版。

要追趕上這樣的規格也不是對著機器投入紙鈔就可以買到的。Ted Sarandos 受訪說出上面那一段話的同時，Netflix 已經默默開始複製他們自己的《權力遊戲》——也就是隔年上架的失敗之作《Marco Polo 馬可波羅》。攤開此時此刻的串流節目表，幾乎每一家都還在努力複製《權力遊戲》經驗、打造更龐大而更有利可圖的影視宇宙：比如 Netflix 的《The Witcher 獵魔士》、 Amazon Prime Video 拍攝中的《Lord of the Rings 魔戒》和 Apple TV+ 即將上架的《Foundation 基地》。

8 年後晉升 Netflix 共同執行長的 Ted Sarandos 顯然不再以 HBO 為首要圍堵目標。首先 HBO 已經變得無關緊要，因為有線電視的大勢已去，而最後 AT&T 集團整合出的串流服務雖有 HBO 的名字在上頭，但人人都知道 HBO Max 已經不是過去的 HBO 團隊高品質節目製作的代名詞。It’s not TV. It’s not HBO, either. 另一方面，雖然 8 年來 Netflix 從未真正製作出 《權力遊戲》同量級的成功節目，但他們的《Stranger Things 怪奇物語》、《獵魔士》、《The Umbrella Academy 雨傘學院》、《Money Heist 紙房子》和《Kingdom 屍戰朝鮮》的影響力都再再遮蔽 HBO 的電視金字招牌亮度。

如今，Netflix 的首要防堵對象已經變成坐擁 Marvel 漫威系列、Star Wars 星戰系列和 Pixar 皮克斯電影品牌的米老鼠帝國 Disney。Netflix 的戰略因此早就變成「在 Disney 變成 Netflix 之前先變成 Disney」，而且事實上這個戰略已經越來越逼近失敗邊緣，因為去年不惜大動作組織改造的 Disney 幾乎已成功變身 Netflix。

非常時期需要非常手段，而開設實體店面、跨足周邊商品、遊戲、podcast 和打造一個 Netflix 粉絲專屬社群平台等等業外投資就是 Netflix 的非常手段。

19 小時的片長和 44 年的深度互動體驗

對 Netflix 來說，Disney 是比 HBO 棘手一百倍的對手，因為 Disney 是一家百年企業（如果從 1923 年的 Disney Brothers Studio 起算），有整整一百年嘗試錯誤的 know-how。自製節目經驗只有８年的 Netflix 必須繼續踩雷數百次才能追得上同樣的經驗值。

這些好萊塢著名 IP 與粉絲互動的親密關係更是坐擁 2 億訂戶的 Netflix 也難以望其項背的。

Disney 是整個好萊塢最早跳入電視製作領域的電影片廠，而且從一開始就直覺地將「電視」定位為好萊塢最重要的行銷工具。早在 Mattel 美泰兒和 Hasbro 孩之寶開始利用每週播出的電視卡通銷售各種玩具之前， Disney 早就在用每週播出的電視節目向觀眾推銷即將上映的 Disney 電影和 Disney 主題樂園。

授權商品很快就變成 Disney 的金雞母

每個孩子看完電視卡通或是動畫電影之後，就會奔往玩具反斗城買回周邊玩具，以便回家繼續編造剩下的故事。因為每週更新一集，小粉絲的購物慾每週都要被強化一次。21 世紀之後還有網路粉絲社群，可以讓小粉絲們互相自我強化。而周邊商品的授權費往往跟著節目/電影的受歡迎程度連動，節目繼續受歡迎，授權費就能繼續坐地起價，還不用像 Mattel 和 Hasbro 那樣必須承擔產品滯銷的庫存壓力。

這也呼應了 Netflix 不可能把開店賣自己的周邊商品當成金雞母的理由。每個行業都有每個行業的經營風險，瞧瞧 Mattel 和 Hasbro 近年低迷的業務即可見一般。

不論在內容主業或是周邊商品副業，維持 IP 受歡迎的程度都是 Netflix 的一大門檻。而他們選擇的特殊發行模式使他們必須花更多力氣跨過那道門檻。

Netflix 以一口氣上架整季節目的特殊「binge-watching 追劇」消費模式瓦解了傳統電視頻道如 HBO 和他們的觀眾之間的關係。但這種上架模式的致命傷是觀眾可能花三天、五天一口氣追完之後，就會將注意力移往別的節目、別的 IP 甚至是別的平台上的產品。Diseny 的《The Mandalorian 曼達洛人》一季分成八週播出，加上往前、往後延伸的議題溫度停留時間，大概可以創造三個月左右的熱度。然而即便是最受歡迎的 Netflix 節目《Stranger Things 怪奇物語》一口氣上架整季 8 集節目之後，大概兩三周就結束話題溫度。

拉到更長的尺度上觀察，Disney 所屬 9 部 Star Wars 星戰電影加總起來全長是 19 個小時又 36 分，而其 IP 熱度維持 44 年迄今毫無疲軟姿態。相對之下，3 季 25 集的《怪奇物語》加總起來是 20 小時又 50 分鐘，然而討論熱度卻跟著節目上架的節奏起起落落，每一季完結隨即被觀眾遺忘。

促使 Netflix 在今年接連採取行動的壓力來源，正是 Disney + 上接連襲來的漫威節目和星戰節目帶來的驚人火力。Netflix 如果再不創造出體驗深度有如漫威和星戰一般的 IP，他們很可能就要輸掉這場串流大戰。

於是他們決定採用「揠苗助長法」，在粉絲互動自然發生之前直接自己捏出一個粉絲互動生態圈，來維持 IP 的熱度不會因為追劇進度完結而跟著降溫。

19 小時的片長和 44 年的深度互動體驗

「我們沒有那種超過 40 年歷史淵源的著名 IP。我們必須創造新的故事、新的世界觀以及新的粉絲互動」

去年底 Netflix 的編輯主管 Max Mills 就在受訪時提到這種從零開始打造粉絲文化的獨特經驗：「我們得以從頭開始思考：下個世代的宅男文化會是什麼？下個世代的粉絲文化會是什麼？」

過去一年多陸續開始開商城、做遊戲、錄 Podcast、出周邊商品、出粉絲刊物等等一系列新嘗試，正是他們嘗試捏塑一個專屬自己的粉絲文化/宅男文化的過程：

就像星戰迷一樣，《獵魔士》的影集更新空檔，粉絲必須有玩具或是 T-Shirt 來表達自己的品牌忠誠度；《Dark 闇》的影集更新空檔，粉絲必須有個網路社群可以交換錯綜複雜的劇情線索和幕後花絮；《怪奇物語》的影集更新空檔，粉絲必須有個遊戲可以繼續體驗幾個禮拜（端看破關難度而定）；《屍戰朝鮮》的影集更新空檔，粉絲必須有外傳 podcast 或是外傳小說可以提供更多殭屍宇宙細節......

乍看之下，出小說、玩具、授權遊戲、經營粉絲社團和粉絲刊物都使 Netflix 這家新潮的公司看起來更像傳統的複合式娛樂媒體集團。但實際上經營這些媒介的用意並非為了在這些他們原本一點都不熟悉的媒介上賺到錢（當然有賺也不是不行），而是為了替自家這些年資不夠深的 IP 揠苗助長出一個比較有模有樣的粉絲文化和互動體驗環境。

唯一的例外是遊戲。

Netflix 已經出人意料地宣布他們不只會出節目的 IP 延伸的遊戲，未來也可能開發無關節目的新遊戲。而這些遊戲都將是 Netflix 訂戶專屬，不會丟入遊戲市場零售或是獨立成為類似 Apple Arcade 之類遊戲訂閱服務。這個做法仍有可能是為了轉移華爾街對於訂戶增長放緩的關注眼神，也不排除真的是準備作為未來核心業務出事時的營收備胎。但這些可能性都是很久很久以後的事。

如今 Netflix 念茲在茲、欲除之而後快還是那個「很久很久以前在一個遙遠的銀河系」中頑強存在 44 年的粉絲生態系，因為他們正被曼達洛人和小尤達的攻擊火力逼到了懸崖邊上。

責任編輯：Mia
核稿編輯：Anny

延伸閱讀：


分享文章或觀看評論

評論

葉郎串流筆記

在百年電影史正要翻頁的歷史瞬間，尋找隧道盡頭的下一道光：串流。

品牌

開發者享受 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。

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


分享文章或觀看評論

評論

廣編企劃
由關鍵評論網媒體集團《業務團隊》製作，由各品牌單位贊助。業務與行銷相關合作，歡迎與我們聯繫。