Apple Car有譜?蘋果執行長庫克受訪鬆口,「自駕車概念股」搶先布局

Apple Car有譜?蘋果執行長庫克受訪鬆口,「自駕車概念股」搶先布局
Photo Credit: Reuters / 達志影像

我們想讓你知道的是

庫克(Tim Cook)5日接受《紐時》作家史威瑟(Kara Swisher)Podcast節目Sway專訪時,罕見談及自駕車較具體想法,Apple Car將採取何種策略迎戰競爭對手,牽動臺灣投資人佈局自駕車概念股。

《紐約時報》(New York Times)4月5日報導,蘋果執行長庫克(Tim Cook)接受《紐時》作家史威瑟(Kara Swisher)Podcast節目Sway專訪時談及Apple與自駕車的未來,並透露一些尚未發表的產品細節,包含自駕車軟體平台、擴增實境等技術,暗示自駕車與Apple是理想搭配,引起市場無限想像。

根據市場研究機構Gartner近年預測顯示,2017年全球行動裝置(涵蓋桌上電腦、平板電腦與行動電話)總出貨量將達到23.24億台,比起2015年的23.24億台,年成長率呈現「停滯」現象即使到了2018年或者2019年全球裝置總出貨量成長率仍將持續衰退,而因去年新冠疫情影響, 2021年行動裝置出貨量才落底反彈。

隨著行動通訊裝置市場逐漸飽和,Apple也需要新的成長動能替營運增加新柴火,其中瑞銀分析師David Vogt肯定Apple Car的潛力,假設Apple在10年內拿下全球電動車單位量8%,營業利潤將接近15%,並於日前大舉調升Apple股票評級和目標價,大幅調升至142美元(截自4月6日為126美元)。

Apple Car台灣供應鏈搶先布局

隨著自駕車逐漸在站穩市場,根據波士頓顧問公司(BCG)預測,2025年全球自動駕駛車(以下簡稱自駕車)市場銷售上探420億美元,實現部分自動化車輛將佔總體車市12.4%,至2035年市場規模更將翻倍成長。也代表由智慧型手機主導的科技產業,將面臨巨大轉變。

過去Apple對電動車的進度始終語帶保留,各界原本預期可能至少到2023年才會發表Apple Car的雛形,沒想到,庫克5日接受《紐時》作家史威瑟Podcast節目Sway專訪時罕見談及自駕車較具體想法,例如Apple為自駕車製造商打造一個自駕技術平台,正在推動汽車生產方案「泰坦計畫」(Project Titan)。

根據《經濟日報》報導,國內供應鏈大廠董座日前直言,自駕車相關供應鏈早已開始「動起來」,而未來自駕車關鍵供應鏈也都是台廠。台灣早因特斯拉(Tesla)而耕耘已久的供應鏈,則率先受到矚目,其中包含台積電、鴻海、貿聯-KY、胡連、江興鍛、和大、和勤。以及電動車興起對SiC(碳化矽)、GaN(氮化鎵)的需求強勁,世界先進、漢磊、嘉晶、昇陽半導體、穩懋、全新、宏捷科等公司未來也可望受惠,其中又以鴻海最受矚目。

根據《彭博社》報導,Apple屢傳要進軍自駕車市場,市場預估生產、製造汽車,Apple有三項選擇。第一,和傳統汽車製造商合作;第二,自行建立汽車生產設施;第三,則是與iPhone模式相同,尋找代工製造商進行合作,例如鴻海。

日前,隨鴻海董事長劉揚偉大動作為了自駕車產業成立MIH聯盟,該聯盟是透過開放技術規格,邀請各界夥伴加入,共同建構電動車軟體、硬體與零組件的生態系,最大特色為模組化、彈性化、客製化;第二個特色輕量化與一體成型。

鴻海說明目前聯盟會員已來到1348家廠商,聚焦在電動車在電池、電機、電控和軟件的布局,但不會走「獨自」開發的路線,而會和策略夥伴合作,這些關聯也給外界更多空間想像。鴻海股價也隨即反應利多,自2020年11月受到市場青睞後,已從77.5元漲至123元(截自4月7日),數月內幅度高達63%。

Apple Car相關概念股三大風險

Apple Car風聲在市場上已經盛傳多時,如今庫克接受訪談又再度受到市場關注。而天風國際分析師郭明錤在日前發文卻提醒投資人要注意Apple Car相關概念股風險的三大問題產生的風險。

第一,推出時程不確定,無論市場上如何預測Apple Car相關供應鏈的股票走勢,但始終沒有從Apple得到具體的時程,也因此一般市場上皆認為Apple Car可能最快也得至2023年,才能見到曙光,而自駕車產業卻也可能在這段期間有天翻地覆的變化。

第二,規格與供應商不確定,由於自駕車產業更進入快速變化期,無論是特斯拉又或者各大傳統車廠,都在搶進規格戰場,未來自駕車平台的規格未定,亦未受到市場肯定,因此,郭明錤認為所謂Apple Car相關概念股,在規格尚未明朗情況下,臆測的成份居多。

第三,Apple Car市場競爭力未明朗,郭明錤指出過去Apple也並非無往不利,也有產品不受青睞的情況,例如智慧音箱就是一個例子,所以Apple Car也不一定能夠在特斯拉、Rivian以及傳統車廠的競爭下得到甜頭。Apple Car將採取何種策略迎戰競爭對手,也將牽動台灣投資人未來投資布局。

延伸閱讀:

新聞來源:

核稿編輯:翁世航
責任編輯:莊貿捷


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 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 部可以獲得以下三大好處。

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。

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

了解 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。

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


猜你喜歡