【Lynn寫點週報】Android不再免費,Google正式對歐洲製造商收取授權費,對誰的影響最大?

評論
評論

2018 年 7 月 18 日,歐盟指控 Google 違法藉由 Android 作業系統壟斷其搜尋業務,向 Google 開罰近五億美金。

經過 Google 對歐盟上訴後,歐盟照舊認定 Google 仍觸犯反托拉斯法,Google 不得不宣布改變其 Android 系統的授權模式──同意將 Google Play、Google Search 及 Chrome 瀏覽器分開授權。

Google 官方於 2018 年 10 月 16 日於部落格中發布了一篇文章:Complying with the EC’s Android decision,表示 Google 即將配合歐盟的政策,改變其 Android 系統的授權方式。

Android 手機製造商不再被迫接受一整包的 GMS ( Google Mobile Services):預載高達 11 項 Google Apps,強制消費者強制使用 Google 的搜尋服務。(相關名詞解釋可以參考我之前寫過的文章:【Lynn 寫點週報】歐盟向 Google 裁罰史上最高罰金有用嗎?早就太遲!全面解析 Android 授權模式。

隨後美國知名科技媒體 the Verge 爆料,宣稱取得了 Google 內部人士的機密授權資料──未來手機製造商在歐洲販售的智慧型手機,若要預裝 Google Play,都需要向 Google 支付權利金。奇怪的是,授權金的多寡是依照螢幕的像素密度 (ppi) 來認定級距,最高上限為 40 美金。

老實說這真不是一筆小數目,都快要等於一顆 SOC 的成本價了,若 Android 手機付了這一筆授權金,手機製造商肯定虧損,有可能轉嫁部分成本給消費者。消息一出,網路上許多人開始擔憂歐洲將興起一陣手機代購潮,委託親友或是代購店家把手機從美國或是亞洲轉運過來以取得較便宜的手機。

但是先別急,Google 身為一家網路廣告公司,Android 手機的策略方向不會因為歐盟政策改變,就變更為賺取授權費的模式,這樣會分裂 Google 的生態系:Lynn 推估新的條款多半只是為了規避政府的追查。首先我們先來看看 the Verge 目前揭露的三層授權模式,以及個別的授權金收取方式:

第一層:Android 開源計畫 Android Open-Source Project (AOSP)

AOSP 計畫提供 Android 底層架構的開源程式碼及平台,所要求的 Android 限制很少:手機廠商可以根據自己的喜好做任何的修改及或是更進一步的客製化。目前使用 ASOP 架構的智慧型手機將維持免費,Android 依然維持開源的狀態。

第二層:手機預載 Google Play、Gmail、Maps 等 Google Apps

過去 Google 強制要求製造商,若出貨前希望預裝 Google Play(用於下載其他的 Android Apps)及其他的核心 Google Apps,必須一併安裝 Google Search 及 Chrome 瀏覽器,但目前改為可分開授權。

也就是說,若手機製造商只想預裝 Google Play 而不想綁定 Google Search 及 Chrome 瀏覽器,必須依照手機的螢幕解析度級距,向 Google 支付 1~40 美元的手機授權金。

這一層協議是為了遵守歐盟所指控的「未經 Google 認證智慧型手機,一般稱為 Android forks, Google 要求手機製造商如果要預載其獨家服務,包含 Google Play 及 Google Search,便不能發展及銷售 Android fork 的手機。」

因此 Google 必須將 Google Play 及 Google Search 分開授權,給予廠商選擇空間,但是 Android 的免費是建立在 Google Search 所帶來的廣告業務。若喪失了廣告業務收入,Google 必須針對 Google Play 的部分進行收費,才能符合歐盟的公平競爭。此外,Google 也必須允許廠商發展及銷售 Android fork 的手機。

第三層: 一併預載 Google Search 及 Chrome 瀏覽器

選擇預載第二層的核心 Google Apps 並支付權利金後,手機製造商另外可選擇免費預載 Google Search 及 Chrome 瀏覽器(非必要),藉此獲得授權金減免或是廣告分潤(目前尚未確定詳細條款)。

Google的作法只是變相繞過歐盟的裁罰條款,仍強制廠商綁定其搜尋服務

Google 這樣的作法只是為了規避歐盟的罰鍰,本質上仍強制 Android 廠商繼續預載 Google Search 等搜尋服務。若上述的機制推出後,根本不會有廠商選擇第二層協議架構──只支付授權金給 Google,一定會走第三層的預載搜尋服務,抵銷掉授權金所增加的成本。

對於毛利微薄的智慧型手機製造商來說,40 美元的額外成本過於昂貴。

舉例來說,根據 IHS Markit 所做的拆解,一顆最高階的完整 Snapdragon 845 解決方案(含所有的 SOC 項目)成本約為 67 美元,這是除了螢幕以外最昂貴的零組件。40 美元的額外成本對於手機廠來說,大概是手機多了一顆中高階 SOC 的成本。

因此,若手機廠僅選擇第二層的協議,所販售的手機售價將不具任何競爭力,另外 Google 的搜尋服務早就壟斷了市場,即使不預裝相關搜尋服務,大部分的消費者仍會使用 Google Play 下載 Chrome 瀏覽器,廠商沒有理由拒絕第三層的授權架構。

歐洲消費者放心,對於一般的 Android 旗艦手機價格影響不大

依據 Google 是網路廣告公司的本質推測,這套協議架構應該會做修正到:「若廠商選擇了第三層架構,所產生的收益將抵免掉授權金」。從結果來看,Android 仍然是免費的作業系統──只要你願意協助推廣 Google 的搜尋業務。

Android 市場競爭如此激烈的情況下,廠商要上調價格的空間不大,因為有選擇預裝 Google 搜尋服務的其他品牌將賣得更便宜,以軟體授權的理由漲價更無法被消費者接受,預期歐洲的 Android 手機並不會因為 Google 的新政策而漲價,消費者應該不用過於擔心。

受害的是手機製造商,出貨前支付授權金可能損害其資金管理能力

上述政策看似沒有問題,Android 手機廠仍可以選擇協助推廣 Google Search 等服務來獲得免費且完整的 Android 作業系統。但這項政策更動對於手機製造商來說可能是非常大的壓力,為什麼呢?

如果手機製造商要於出貨前就將授權金支付給 Google,再等廣告分潤或是獎勵補貼下來抵銷成本,那麼手機製造商將面臨龐大的現金流管理壓力。比如說,如果今年這一批貨出貨 100 萬隻,公司必須先付給 Google 高達 4,000 萬美元的授權費,過了半年至一年才可能從 Google 的獎勵政策中回收這筆款項。

對資金周轉緊縮的手機廠,這樣的現金流壓力真的非常的大,更可能影響到手機供應鏈的收款天數,比如說過去是 90 天付款,因為 Google 的新政策,手機品牌廠多了一筆授權金支出,沒辦法像過去 90 天內付款給供應商,可能改為 180 天付款。

這樣的改變將可能讓供應鏈處於非常的艱困的狀態。因為薪水、設備、租金是每天都在燃燒的項目,收付款周期延長對於經營極為不利,需要更多的資金調度才能應付每日的現金開支。

舉個例子,假設我今天工作,老闆對我說一個月的薪資需要半年後才領到──這是多麼可怕的事情,因為中間的生活開支跟房租都必須持續繳納,這根本是逼死人。為了維持營運,營運現金只能從銀行借調,代表公司需要支付更多的利息及手續費給銀行,間接提高了成本跟管理難度。

華為、三星成為最大的潛在受害者,但更慘的可能是背後的供應商

歐洲的智慧型手機市場相當獨特,最受歡迎的品牌廠是三星跟華為,與亞洲的市場生態有些許的不同。根據 Statcounter 的數據指出,三星在歐洲的擁有 33.4% 的智慧型手機市佔率;華為 16.86%。若單就 Android 手機市占率,三星有 45%;華為則有 22.5%(四捨五入),兩者加起來超過六成的 Android 手機市占率。Google 這項禁令對於這兩大智慧型手機品牌可能是相當嚴重的衝擊──如果 Google 要求品牌廠出貨前支付授權金的話。

幸好歐洲主要的 Android 手機廠都是全球的龍頭,僅僅歐洲地區的收付款政策變動並不會讓華為跟三星陷入倒閉危機,但以 Google 及這些一線品牌廠的議價能力,這些大廠很可能將成本轉移到供應鏈上,對於毛利持續創新低的手機代工產業,營運可能再陷困境。


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

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