⭐️sMeet上市 智聯服務搶攻資通訊技術系統整合的商機
2021年疫情出乎預期未能休止,也使得在家工作、遠距教學與電競娛樂等需求不墜,推升PC相關的產業動能,宏碁集團交出一張亮麗的成績單,此次專訪宏碁集團創辦人/智榮基金會董事長施振榮先生,以及智聯服務(Acer Synergy Tech)韓政達總經理,探詢以資通訊技術為主的系統整合商業模式,同時提供客戶在空間場域運用的建置實力。
智聯服務成立於2017年,前身是宏碁的新竹分公司,長期深耕台灣半導體產業客戶,是宏碁集團組織的第三波改造的關鍵要角之一,並於2020年底完成上櫃掛牌,登上台灣資本市場的舞台,其所看到的市場在於企業積極推動數位轉型以及跨領域合作的風潮方興未艾之際,對於網路建置、維運和IT服務的需求正排山倒海而來,大多數的企業要培養足夠的資訊人才實在力有未逮,因此讓系統整合外包服務商找到重要的利基,智聯的出線呈現以資通訊技術為核心的專業系統整合公司正開始嶄露頭角,也成功創造出自身的價值。
2020年也是COVID-19(新冠肺炎)疫情全球肆虐的開端,居家上班所推動的視訊會議系統成為各方角逐的重點市場,考量到資訊安全與長期營運成本的要求,宏碁集團投注資源走入內部自行開發的道路,sMeet的視訊會議系統於焉誕生,施振榮受訪時特別強調sMeet的「s」就是指Security,安全性是視訊會議系統最重要的考量,他從系統開始研發時就一直參與實際的測試,這段期間由他主持的多項會議更幾乎是天天使用sMeet,一直到產品經一年多的完整測試後,終於決定2021年要正式上市。
打造「巨架構微服務」的整合平台
施振榮探究國內軟體產業的發展,認為軟體公司要擺脫小打小鬧的格局,一定要走向國際市場,做B2B的生意模式是台灣產業界的基本宿命,因為台灣本地消費市場規模太小,軟體的成功要能夠容易複製以造成數量上的取勝,他所看重的是sMeet做為資通訊基礎架構的水平整合平台的商機,隨著多樣化的智慧型應用的大量開發與創造,搭配台灣的硬體優勢相輔相成,打造出「巨架構微服務」的整合平台,這個商機值得台灣廠商好好珍惜。
宏碁集團歷經要「分」才會拚的階段,在1990年代,集團內的大型硬體製造子公司分拆獨立,各自努力於品牌與製造的國際競爭與征途上,但是今天需要回頭來看所謂要「合」才能贏的機會,過去電子製造與代工的利潤捉襟見肘只有3~4%,今天透過軟體系統的整合後,他認為新型態的軟硬體系統整合的商機浮現,拜少量多樣化的趨勢之賜,勢必推升軟體所驅動的資通訊系統整合的獲利模式。
以施振榮的角度來看,集團內的戰將們要從各司其職與各擅勝場的角色上,一起揪團打國際盃,這才可以看到成功的契機,他提出「新微笑曲線」的概念,即是跨領域合作,共創價值,而軟體做為資通訊系統整合的平台正充滿著新的商機,以下是他的趨勢專訪。
Q1:您如何看待台灣科技產業進入軟體的挑戰?台灣的軟體公司要如何經營才能成功?
施:說到台灣軟體產業的挑戰,軟體的成功的關鍵是要憑藉著規模與數量的加乘效益與實力,我在80年代擔任台北巿電腦公會理事長時,台灣的軟體產業隨著電腦硬體設備進入台灣時就已經起步,早期的軟體公司是以軟體系統整合(SI)的概念為主,起步時與當年的硬體產業所面對的挑戰不相上下,但是因一直無法發揮數量與規模上的效益,所以營運比較辛苦,如同當年全球最大的軟體服務公司為例,也是異常艱辛;就我的觀察,當年以軟體廠商來做系統整合為主的服務,比不上以硬體為主的系統整合商來的吃香,但是今天有機會看到翻轉的契機了。
軟體成功的兩大推力是規模與國際化的能力
鑒於軟體產業的辛苦,早期我在1990年代的初期任台北市電腦公會的理事時,因為重視軟體的潛力發展,所以特別在電腦展中提供免費的攤位給軟體公司來參展,做為一種軟體產品展示與國際化的推展,那時候很清楚的知道,台灣市場不夠大,客觀條件不足,軟體要能夠成功有兩大關鍵的力量,首先需要借助電腦硬體的規模經濟,再者就是讓軟體能國際化的兩個主要的推動力量,目前在台灣幾個重要的軟體廠商的成功經驗,也看到初期採用與PC一起搭售組合(Bundle)的策略提供成功的關鍵,大批量與消費者重複使用的經驗,促成軟體成功的機制。
我認為電腦的硬體系統是一個載具的概念,台灣因為硬體製造的實力堅強而容易進入國際領域競爭,國際級的軟體巨擘實力強勁,但是一談到硬體的載具,那一定會找台灣來合作,所以我們的軟體企業除非在某些特定領域,否則一般都會避開硬碰硬的對決競爭,因此宏碁選的軟體發展策略是不去妨礙硬體生意的發展實力,而是找到可以展現整合硬體優勢的軟體商機,這個新領域中我看到台灣進入的強項在於工程師技術與台灣健保醫療系統所帶來的優勢。
展望未來,面對國際分工與趨於複雜化的現實,為了掌握未來的機會,一個具備彈性功能、成本優勢,以服務為導向的生意模式,加上探索智慧醫療、智慧農業、智慧製造,以及智慧城鄉等應用,我預測獲利三成、四成的新事業體會快速應運而生。
Q2:今天宏碁如何在軟體市場上找到發展的契機?
施:宏碁的轉型過程中,我們認為諸如sMeet等軟體的發展機會,首先就是先制定出廣泛(Universal)的產品規格,可以藉由大小通吃與兼容並蓄的產品規劃能力,做出能與最多的硬體相搭配,我從2013年重回宏碁的時候,就推動宏碁大舉朝向通訊與智慧醫療兩大主流的方向來推動宏碁務實的市場發展轉型,當中智慧醫療靠的是跨領域的整合,而通訊則是靠軟體整合。
通訊與智慧醫療市場是宏碁所看到的美好未來
首先,通訊系統與軟體息息相關,舉凡主流的數位交換機與VOIP等系統都是用電腦與軟體所搭建而成,今天用軟體來定義一切是電腦產業的大勢所趨,過去以類比訊號為主的PBX系統承受從電腦與整合軟體所帶來的強大市場壓力,智聯的sMeet是先整合視訊的功能,接續也會將語音訊號加以整合在內,這也是為了進入通訊系統的起手式,所以宏碁朝下一世代的通訊系統發展是早已經確定。
sMeet視訊會議軟體的最佳賣點就是安全性的要求,兼具使用雲架構(Cloud Based)或內部部署(On-Premise)的架構來滿足不同的安全性的需求,這也整合宏碁過去發展BYOC自建雲服務的寶貴經驗,不斷探索使用筆記型電腦等級的系統來搭建一個私有雲系統的可能,分散式網路還是有小而美的實用性上的好處,再者,sMeet使用上也兼顧企業內部高敏感性機密的視訊會議需求,以及同仁商務差旅在外的視訊會議方便性之需,所以我的sMeet提供兩種不同的雲端網路的配置,來提供我做到隨時隨地參與視訊會議,也可以在緊密安全性下進行企業內的重要會議。
Q3:您如何看待sMeet所打造的商業模式的變革?
施:宏碁集團在陳俊聖執行長上任後積極轉型,針對旗下各主要事業做了較為明顯的區分,希望商用市場能夠靠著旗下各個小虎分進合擊,組成了以商用布局為主的宏碁聯合艦隊之姿,透過產業下游的系統整合服務,將上游的品牌產品也一起打進終端應用的客戶群,這也是智聯目前正積極努力的方向。
開放sMeet的API模組 搭建新的產業合作的模式
這個專訪的第二部份是聚焦於sMeet的產品與市場的推廣動態。以下是智聯服務韓政達總經理的觀點。
Q4:請韓總經理說明一下sMeet的產品特點。
韓:sMeet是一個後疫情時代的產品,需要慎密的商業模式以滿足遠距應用的需求,由於市面上視訊會議軟體競爭非常劇烈,sMeet在產品面需要具備後發先至的優點,最主要的利基點就是善用雲架構打造三個產品的優勢,第一,資訊安全的優勢,因為使用宏碁BYOC的私有雲技術,兼顧頻寬與資訊加密的優勢,讓企業保持高度的資安防護的能力,而且在架構上的成本非常具有優勢,降低導入成本。
第二,4K高畫質影像品質,拜私有雲技術之賜,充足的頻寬可以讓企業內視訊會議使用4K解析度影像品質,大幅提高與會者的使用者體驗,第三,容易使用,在PC上善用以瀏覽器為主的方便性,雖然手機仍需要App下載,但是整個使用介面簡單明瞭,無需訓練課程就可以使用。
為了打造更多的使用範例,針對疫情肆虐下的日常,目前sMeet團隊為台灣上市櫃公司打造董事會專屬sMeet視訊會議系統,而且完全依照證管會的法規要求所設計的專屬應用,再者,從大量的sMeet場域實地測試的經驗中,目前已經有許多新的使用範例正在運行,相關的應用也有更多的產業殷切的探詢,尋思為了讓sMeet能夠成為更多重要應用的關鍵溝通工具,目前已經著手制定彈性sMeet的API軟體模組,整合到不同專業系統中,讓更多的產業可以從中得到最大的效益,搭建新的產業合作的模式,強化以服務為導向的企業文化的貫徹。
Q5:請韓總經理說明一下sMeet的市場發展動態與上市的計畫。
韓:智聯是宏碁集團的新群龍計劃的一個企業內部創業的成果,雖然現在資本額不大,但是在宏碁集團的大家庭下,分享宏碁集團的重要的資產,也就是Acer的品牌價值,以及集團下的重要的人脈與人才的資源,以我親身經歷而言,於2021年初,智聯參與競標一個北歐國家的漁業公司的業務案,由於充分獲得Acer歐洲辦公室的協助,迅速解決問題,讓我們一舉打敗日本電信巨擘的競爭者,做到小蝦米打敗大鯨魚的致勝成果,取得成功。
有了這個初試啼聲的成功之後,我們積極利用sMeet的API來進行產業界的垂直整合應用的發展,目前瞄準包括銀行的線上開戶系統,甚至是大專院校或專業訓練單位的線上教學系統等新的嘗試,都讓sMeet在新興應用上創造商機,在國際市場上,透過宏碁集團在當地公司地協助,持續串連集團優勢資源,瞄準重要的營收貢獻產業,目前智聯是sMeet全球代理商,負責行銷與提供在地化服務的任務,目前已經在美國設立子公司,並陸續在北美各州成立區域型辦公室,並期盼進一步朝向一家國際服務公司前進,把好的人才推向全世界,走向全球。
同時也有1部Youtube影片,追蹤數超過3,870的網紅管碧玲,也在其Youtube影片中提到,...
系統維運計畫 在 躍動金門-楊鎮浯 Facebook 的最佳貼文
#拜會交通部長王國材
#爭取中央支持地方產業民生
重視防疫之餘,金門產業發展、民生經濟仍然繼續向前發展,鎮浯昨天率領縣府團隊前往交通部拜會,盼中央支持、補助地方建設的各項提案。
#離島定期交通 交通部考量後續維運成本會是沉重負擔,但同意補助縣府於三節期間以 #計畫性包船 方式辦理。鎮浯感謝王國材部長對於離島交通的支持,同時也請交通部持續研議建船計畫的可行性,讓鄉親有更多元的交通選項。
#金門縣交通控制系統建置計畫 爭取支持同意補助3075萬元。
#環島自行車道升級暨多元路線整合推動計畫 確定將金門縣納入計畫之中。
#離島觀光復甦 為業者爭取再開辦「比照安心旅遊補助模式」的加碼補助。
#星光節續辦 爭取交通部補助金門大型觀光行銷活動,未來將延續、常態性辦理。
此外, #金門大橋通車慶祝活動經費補助、 #海洋藝術季活動經費補助、 #金門縣烏坵碼頭興建工程、 #前瞻基礎建設之改善停車問題計畫 等議題,也都獲得交通部相關單位的支持。
系統維運計畫 在 矽谷牛的耕田筆記 Facebook 的最佳解答
ref: https://ably.com/blog/no-we-dont-use-kubernetes
八月第一篇,就來個有趣的文章,來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes,不但當前沒有使用,甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊,千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。
我個人覺得這篇文章滿好的,因為是認真的去比較導入 Kubernetes 帶來的改變,而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云,人家要我也要,人家不要我也不要...
文章分成兩部分,前述介紹當前 Ably 的環境架構是什麼,而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下,會發現導入 Kubernetes 沒有帶來實質上的好處。
文章開頭先簡述了一下 Kubernetes 這幾年的風潮,從最初 Google Borg 的開發開始談起,作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用,
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中,透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果,對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。
Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider,並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container,取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。
對於 Ably 來說,團隊中沒有任何 scheduler 相關的服務來調度各種服務,這意味每個 VM 就代表一種服務,所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務,用來確保運作的 Container 如果掛掉後可以被重啟,甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。
流量方面,因為每個 Autoscaling Group 就代表一個服務,所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題,畢竟每個機器本身都會被 VPC 賦予一個 IP 地址,所以使用上沒有什麼太大的問題。
接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變,分別有 (原文很多,這邊摘要不然文章會太長)
題外話,由於 Ably 的 Infra Team 數量有限,所以要考慮 K8s 只會考慮 K8s Service,如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM,畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說,透過這種方式能夠盡可能的榨乾機器的資源,整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源,這種被稱為 nosy neighbors 的常見問題已經不是首次出現了, Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用,而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務,不過這個做法跟團隊目前的作法已經完全一致,所以就資源管理這一塊,團隊看不到使用 Kubernetes 的優勢。
2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量,基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務,所以其收費是針對客戶實際上用多少服務來收,如果開了過多 EC2 VM,則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量,
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整,根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點,但是閒置並不代表沒有任何服務部署再
上面,因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說,k8s 有兩個動態調整的部分,動態節點與動態服務,而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。
3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案,基本上團隊只要能夠維持每個服務與背後的機器的關係圖,網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務
K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP,這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller,這些 Container 可以跟 AWS LB 直接整合,讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定,所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。
4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本,後續相關機制就會將 VM 給替換掉,然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果,雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。
上次四個分析基本上就是,使用 k8s 沒有帶來任何突破性的好處,但是 k8s 本身還有其他的功能,所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處
Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭,「除非經過評估,否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊,同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說,光 Storage 每家的做法都不同,而 K8s 沒有辦法完全將這些差異性給抽象畫,這意味者開發者終究還是要針對這些細節去處理。
Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由,畢竟這種用法就跟當初 Google Borg 用法一致,是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時,底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫,所以這個優點也沒有辦法幫助到團隊
Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC,所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。
Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群,社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下,一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s,但是真正理解 k8s 的人微乎其微,所以想要透過社群來幫忙解決問題其實比你想像的還要難,畢竟裡面的問題太雜,很多時候根本很難找到一個真正有效的答案。
Added Costs of Kubernetes
為了轉移到 K8s, 團隊需要一個全新的 team 來維護 k8s 叢集以及使用到的所有基本服務。舉例來說,EKS, VPN CNI, AWS LB 帶來的網路好處並不是啟動 EKS 就會有的,
還必須要安裝相關的 Controller 並且進行設定,這些都是額外的維運成本。
如果找其他的服務供應商來管理 Kubernetes,這意味公司就要花費更多的$$來處理,所以對團隊來說,金錢與工作量都會提高,不同的解決方式只是這兩個指標的比例不同而已。
結論:
1. Ably 覺得 Kubernetes 做得很好,但是團隊目前沒有任何計畫去使用它,至少目前這階段沒有看到任何實質好處
2. 仔細評估後會發現,導入 k8s 其實也會帶出不少管理上的問題,反而並沒有減輕本來的負擔
系統維運計畫 在 管碧玲 Youtube 的最讚貼文
系統維運計畫 在 太陽能電廠維運要點 - YouTube 的推薦與評價
鑒於政府大力推動屋頂設置太陽能光電 系統 之政策,為使廠商了解相關設置效益及找尋適切業者之作法,以及相關建置材料、後續維護安全等注意事項, ... ... <看更多>
系統維運計畫 在 機關名稱:經濟部投資審議委員會 - 標案瀏覽 的推薦與評價
日期 類型 代碼
20230116 決標公告 11202
20230111 決標公告 11201
20221129 決標公告 11108 ... <看更多>
相關內容