才短短過半年,台灣 VR 發展為何已落後世界?

半年前我們還在說這是台灣的機會,因為全球都還在摸索中,台灣跟大家都在起跑點上;而現在我要推翻這句話:台灣已經落後了。
評論
評論

本文原分上下篇刊於 TAVAR 共同發起人謝京蓓 Cori Shieh 的 Facebook 頁面,經 INSIDE 編輯合併刊出。

經歷了半年的推廣 VRAR 產業,同時也是在 Computex 中和多國內外朋友們談了很多這半年全球市場和產業的變化,綜合一些心得,想跟大家聊聊:

1. 6 月初中國有兩個很重磅的 VR 相關消息:

一是 Jaunt VR 和上海 SMG,以及微鯨 VR 即將合組公司「Jaunt 中國」,並透過此合組公司讓 JauntVR 在中國發展的高端 VR 影視內容。二是暴風魔鏡和 Leap motion 合作推出了新款 VR 眼鏡盒暴風魔鏡 5plus,支持手勢識別技術。

這兩個消息中,我看到的共通點就是: 中國 VR 廠商間的競爭已經拉到了一種新高度: 有實力的廠商直接與國際標竿大廠對接合作來奠定己身於中國 VR 產業市場的至高點。

前兩個月中國廠商喊得聯盟也好、生態圈平台,頂多也只是自己國內廠商串串喊喊,一起做話題而已,雖然看起來嚇人,卻也只是紙紮老虎;但他們開始是聯合 Leap Motion、Jaunt 這等一等一歐美公司在中國做生意時,它們就已經把產業競爭從公司的個體較勁拉到了國際生態系整合的資源戰。

以暴風魔鏡和 LM 合作為例,原本只是一個低階的 VR 手鏡盒,功能、造型都普通,許多台灣廠商自製的 VR 眼鏡盒都還完勝它,但如今這個合作卻一舉把這石頭點成金,馬上拉高競爭門檻,台灣做低階 VR 盒的廠商怎麼有能力去找到類似 LM 的廠商合作來翻盤? 這好比一個遊戲新手還沒解完新手村的任務,就馬上被丟在高手競技場中,再裝備、天賦都還沒滿點數值前,就要跟魔王打,這樣的一場遊戲局,誰能打得下去?

2. Computex 看到的 VRAR 創業團隊危機:

今年我特別留意了 Computex 參展的 VR 團隊,扣除國外參展的 VR 創業團隊後,我發現今年參加的團隊跟去年幾乎大同小異,而廠商參展的展品內容也無令人耳目一新的表現。這是一個警訊: 這一年中 VR 市場變化極大,許多新型態的商業模式和產品型態已經浮出,但台灣的創業團隊所展示的的成品和商業模式仍是停留在去年的標準,甚至目前還在發展市場中競爭飽荷的項目,這樣的競爭力實在難說服國際買家和投資人來採購我們的產品或服務,而我們還在怪為何買家不來台灣看團隊…對大市場 (歐美、中國) 的市場數據、技術發展、產品型態情報掌握不足,成為台灣創業團隊的最大致命傷。

3. 黃國昌立委的 VR 國會質詢大家都劃錯重點:

重點真的不是林全看到甚麼 VR 內容,而是為什麼我們的行政院長對此新科技如此陌生,以及當黃立委問到對這產業有何具體推動發展想法時,台上長官僅以”在亞洲矽谷”的計劃中有初步規劃來含糊帶過。 這我真看不懂了,這和亞洲矽谷計劃有何關係呢?

當我們國家官員還在含糊用 A 作 B 來搪塞時,中國的福州市人民政府就在兩個月前公佈了促進 VR 產業加快發展的十條措施,從專屬項目基金、園區基地推動、獎勵外商和中國廠商發展合作等,一條條、一項項的清楚列出。這,才叫做具體推動說明!

而這兩個月期間,大陸類似福州市提出的 VR 產業扶持的其地方政府還包括了上海、北京、蘭州、南京等等迅速增加中,不要說和中國企業競爭了,光是政府制定個推動想法,大陸就比我們快狠準,在這樣政策支持匱乏的環境下,我們廠商要怎麼脫穎而出呢?

4. TAVAR 和 TSS 的合作,贊助 VRAR 創業團隊至海外加速:

這是我最近和行業、媒體記者朋友常常提到,務必請大家 多多支持的合作專案。台灣廠商現在面臨的問題 已經不是你做不做 VR,而是你做 VR 能不能拚的過人家活得下去。

半年前我們還在說這是台灣的機會,因為全球都還在摸索中,台灣跟大家都在起跑點上;而現在我要推翻這句話:台灣已經落後了。因此,任何現在想投入 VR 發展的廠商,要更現實的去評估自己在國際市場的競爭力和勝出機率有多少,而評估的方式也不是窩在這島上自己用著過時的市場情報來衡量,而應該是勇敢衝到大市場中,在那想辦法和這些國際團隊搭上線,從合作中來評估。

我去年認識一個年輕人 C,他在美國唸碩士期間,和朋友拍攝了一部 360 度影片,並認真地和美國同業們取經了解市場回饋;另外他也很幸運地爭取到在一家 VR 內容開發的領導公司中作實習,當他實習完畢後,他也決定了要創建自己的公司。

C 的 startup 是否能從市場中脫穎而出我不曉得,但我肯定 C 的公司會比國內的 360 度內容開發公司更具國際競爭力:不在於 C 和他團隊的作品經歷,而是在 C 比國內業者更了解大市場需要、大市場的競爭技術、以及和專業團隊的合作人脈,這些讓 C 勝出。

為了要讓台灣 Startup 有 C 這般機會,我代表著 TAVAR 台灣虛擬及擴增實境產業協會和 Taiwan Startup Stadium 台灣新創競技場 Anita Huang 合作推出了 VRAR 創業團隊海外加速計畫,讓團隊有三個月時間在海外研習,接軌當地專業團隊、市場。要改變公司競爭力?先從改變創辦人的腦袋和眼界開始。

講了這麼多,感覺結論偏負面,然而卻不太代表我認為台灣團隊沒機會了,只是這場戰役已經轉型、而我們必須察覺到這其中變化而隨時調整。VRAR 這場風還會吹的久、吹的長,我們必須隨時看清風向的改變,即刻調整自己的角度(產品發展方向和商業模式),才能夠在這大潮漲起之時,能夠凌駕浪頭、而非淹沒其中。

早上打完了上半篇,匆忙趕去跟一個 startup 做市場諮詢。而下午在等待台大演講上台前,但總覺得要在說明一下,即便我們正面對著國際生態系整合的資源戰,台灣的 VR 創業者相較中國 (/歐美) 的創業者來說仍有些勝出點/優勢,我列出一些我的看法,大家參考、相互交流:

1. 台灣軟硬體人才、製造資源均齊全,容易形成團隊和做出 demo:

我在三月和四月去完深圳和北京後,深刻感受到台灣 VR 創業的優勢: 以從事硬體創業者來說,相較於北京或歐美的創業者飛到深圳找人開模,台灣創業者可以在一天一內走一趟中南部,很快就能找到質量具國際水準製作廠商來打樣,相較於北京、歐美創業者要飛到深圳來找製作商,台灣密集的產業群聚發揮了極大優勢。

另外,內容創業者更是具備優勢: 台灣有過 7 成以上的遊戲開發者都使用 Unity 引擎,也多集中在北部,因此創業家想要找到開發團欸合作做內容 demo,只要南港、內湖、新店走一遭,大概就能找到品質佳的開發者。這點讓台灣創業家在團隊組成、完成 demo 的速度就比歐美、大陸廠商快很多。

2. 台灣行業交流興盛、且分享不藏私、真誠:

只要參加過大陸的行業交流聚會的人,一定會認同: 大陸的行業聚會最大收穫是換到的名片數量而已,但有價值的市場情報比較缺乏。也許是競爭性格使然,大陸人交流的情報資源都是高射炮居多,有點到一些卻又看不到門道。台灣的創業家行業交流,大家反而願意真誠分享,因此 startup 容易形成競合(但變大之後是否還是競合就不曉得了 XD)。

3. 台灣在國際創業比賽舞台上擁有較大的國際化優勢:

台灣創業團隊近年在國際創業競賽上頻頻得獎,不容否認台灣新創實力堅強,而當我參加完 TAVAR 和 TSS 合辦的 VR/AR Show-n-tell,聽完八家廠商 pitch demo 後的感受又更強烈: 這八家本土、小型的廠商在英文演講掌握度上極高、台風穩健,只要有資源後續協助這些廠商改善簡報內容和些許調整演講方式,相信在之後的國際展會/競賽中,不怕其他亞洲團隊的競爭。

有鑑於此,我由衷建議台灣政府多放些資源和預算協助內容開發的 VR/AR 新創團隊參加國際競賽,以及持續地在國際展會中整體行銷這些得獎團隊 (包含展館的包裝、新聞 PR 等)。

-小結-

台灣是一個很適合新創的環境,軟硬體資源整合充分、市場開放、行業交流興盛、國際 (英文化) 程度相對高,但是台灣創業者有一缺點就是,從腦袋中萌生商業想法,到做出 demo 的過程太久 (這是和大陸的創業者相比)。

我經常遇到一個事情:兩三個月前才遇到的中國創業者,跟我分享創業想法後,不到兩個月它們就真的完成雛形、可以展示了。這等強大的執行力,你說是從哪裡來? 我覺得與其說是產業環境整合度高、倒不如說是人的性格中對獲得成功的渴望異常強大,因此驅動著他們分秒必爭,完成理想。

半年前我看大陸 VR 產品、公司普遍一般般,但如今卻看到各自產出作品,在市場上進行商業驗證。對比台灣: 我在去年認識的 VR 開發者,截至到目前有出現新作品、或是成功完成產品開發、推進到市場中的少之又少。論執行力來說,我們有很大的提升空間。

最後,VR/AR 是場科技和市場發展的馬拉松賽,不管是終端裝置市場的開展、又或者是技術的成熟至少都是 5-8 年的發展才能達成,因此即便我們現在有些步調慢、有些落後,只要加緊執行力、提升國際能見度和強化國際市場接軌程度,相信後續仍是有很大的發展潛力的。也由衷希望台灣有越來越多新創團隊投入這領域的研究和產品的開發,相較於其他產業,這塊剛萌生的市場還存在很多想像空間、等待我們挖掘、驗證。

大家一起加油!

額外補充:

台灣新創競技場 TSS 執行長黃蕙雯指出,目前蔡英文政府所規劃之亞洲矽谷計劃中,並未有提及 AR/VR 的相關規劃,詳情請見下圖:

歡迎加入「Inside」Line 官方帳號,關注最新創業、科技、網路、工作訊息

好友人數

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

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