本文為 AWS 與派仕科技合作投稿，並經 INSIDE 編審後刊載；作者為派仕科技技術整合總監蔣鐙緯。
如果你的物聯網健身器材客戶多半在歐洲，當他們早班（約是台北時間下午）開始營業並湧入大批資料通訊，你會如何在雲端上分配流量呢？
又或是，你的歐洲健身器材客戶希望開發「課程預約」系統，但他們習慣在前一週特定時間（例如：中午 12:00 整）才正式開放數百、甚至數千位會員線上預約，你該如何透過雲端來應對短時間內集中湧入的流量？
上述例子，是我們在服務歐美客戶時實際碰到的軟硬整合問題。我們是派仕科技（PAFERS Tech），成立於 2011 年，提供軟硬整合解決方案協助健身器材業者數位轉型，自喻為「智慧健身領域的 AWS」。整體團隊都是 AWS 雲端愛好者，因此接下來將用 AWS 雲端為例來進行分享。
台積電創辦人張忠謀曾說，台灣半導體業最大優勢是：台灣小，彼此距離近，台中、台南、新竹三大園區可以透過高鐵一日來回，讓絕大多數的硬體解決方案都能短時間內在台灣找齊。
這段話其實多少也帶出「軟硬整合」的痛點——時間，基本上決定了一切。在上一篇同樣投稿 INSIDE 的文章中，我們談到「拆解」如何幫助我們理解事物本質，進而協助客戶、我們團隊一起在數位轉型的浪潮中存活。
而本篇接著來談硬體的物理限制，使得「人力成本」、「開發成本」以及「轉型成本」都得與時間賽跑。競爭激烈的商業環境與機會也是不等人，因此我想透過團隊過往協助國際客戶的經驗，與大家分享如何「軟硬整合」。
端上內文「重點摘要」：
- 把硬體的「變異性」轉為「市場機會」。
- 透過「標準化」工具，縮短開發時間。
- 追求軟硬整合迭代，讓產品能持續「驗證」市場。
降低人力時間：找出硬體的「變異性」
在解答文章最開頭的兩大情境題之前，先來聊一下許多朋友都會好奇的問題：要如何挑選合適的軟硬整合題目呢？
我們得先認清到，軟硬整合的最大挑戰是——時間。在開發物聯網產品的過程中，軟體與硬體的「開發週期」是兩種截然不同世界。以軟體業來說，如果開發純 Web，完成後只要按 Command+R，通常短短 1 秒鐘內就可以檢查結果；如果開發手機 App，外接一條連接線再按燒錄後，幾分鐘之內就能檢查程式運作結果。
那如果加入硬體一起討論呢？例如要做一隻錄音筆、寵物餵食器、智慧農業物聯網感應器，簡略流程如下：先準備好各種所需的關鍵零件樣品、開發板或 MCU、儲存記憶體等（大抵上都是手摸得到的東西）→在開發板上寫驗證程式確立方向→畫電路圖／線路圖→排隊小量量產 PCB 板→排隊 SMT 打件→完成第一版 prototype 樣品→驗證，順利的話可以開始放程式進去跑、不順利的話要進行除錯，整個流程重來一次，包含排隊。
光是完成第一版 prototype，再快再快也要花上 1~2 週，這中間若需要任何修改，整趟流程就得重頭來過。正因為經手如此多「人」，導致硬體的限制條件遠比軟體還「硬」。
而我們的應變方式，是先找出硬體與其他事物不具共通點的部分，也就是所謂「變異性」，再由彈性高的軟體儘可能發揮優勢來補足。
那麼，與一般 3C 產品相比，健身器材產業的硬體「變異性」是什麼？普遍來講，這個產業對應的產品生命週期長，迭代速度無法太快，需要漸進式地融入新技術，品質要求也不像 3C 那麼高。再加上市場很「破碎」，幾乎沒有壟斷性大品牌，導致終端使用者或客戶非常依賴在地化經銷商來服務。
「客戶服務」這件事，可能是硬體業、或是剛從硬體跨入軟硬整合的業者們，過去較少思考過的議題。有趣的是，雖然我們以商用領域的健身器材品牌商、健身房等 B2B 客戶為主，但隨著疫情帶來的歐美家用市場蓬勃，也讓我們逐漸回頭滿足家用健身領域的終端消費者。
這時才發現：我們結合觸控螢幕所提供的健身器材，早已細水長流地藉由與終端使用者互動，累積許多運動相關「小數據」；而我們也藉由掌握小數據，發現終端客戶的隱藏需求，並有機會在未來推出新的軟體服務。
因此，軟硬整合第一步是：僅管硬體彈性低，但藉由找出硬體的「變異性」並將之轉為「市場機會」，再搭配軟體的高彈性，才能讓「整合」真正切合所需。
縮短開發時間：分享知識帶來「標準化」
找到適合題目後，接下來挑戰則是：要如何縮短軟硬整合開發時間？
從早期參加 Open Source 社群，參加藍牙技術聯盟工作組、到後來成為台灣的 AWS Community Hero 之一，這些經歷讓我體認到：分享知識，才能讓價值疊在知識上，並產出對人類有意義的成果。
而「標準化」的過程不僅是開啟了對話，也是運用軟體、硬體之間訊號通訊的共通性與變異性，讓分享知識成果成為「整合」過的通訊標準並呈現在大眾面前。AWS 雲端之所以能在協助各種產業進行軟硬整合上如此快速，也是因為「標準化」。
我們所面對的健身器材產業不僅仰賴在地化服務，也仰賴在地化系統。例如：健身房客戶為了掌握會員，總會盡量開發或導入客戶關係管理（CRM）系統與企業資源管理（ERP）系統，但由於這類特定產業的系統與在地法規、文化、語言等息息相關，因此難以直接採用其他國家的既有系統。
而我們若要在硬體、軟體（App）以及雲端（API）三者間傳遞多國語系、型號、參數對應等資訊時，就得創造簡化的資料交換格式，並善用 AWS 各種運算服務的優點。
以文章開頭第一個情境題為例，當歐洲健身器材客戶集中在台北下午時間大量傳遞資料時，我們會使用 Amazon ECS Cluster 裡頭的 capacity providers 功能來分配這批流量，並配發給 ECS Cluster 裡頭的 Fargate Spot、Fargate 以及 EC2 三種 instance type。
至於第二個情境題的「課程預約」系統，雖然是看似不起眼的小小功能，但它不僅是客戶的基本營收功能，對技術開發來說，更是軟硬整合場景中不容忽視的挑戰，因為幾乎上演了一齣可比擬電商雙十一搶貨的流量大戰。
那解法為何？我們將 CloudFront + API Gateway + Lambda + DynamoDB 進行組合並做出簡單版的「虛擬等待室」（Virtual Waiting Room Service）服務，再將這服務規劃成微服務架構，未來就能隨時套用在自家其他功能，或是稍作修改後成為可公開銷售的產品。
當預約正式「開搶」，即使健身房數百名、數千名會員們大量湧入，我們的系統也會計算後端足以乘載的上線人數，再將會員們先安排在由 AWS Lambda 運行的虛擬等待室裡「排隊」。
系統會依據目前排隊人數，來彈性決定是否要開始通知後端系統 AWS Fargate + Amazon Elastic Container Service 擴充容量。等到 AWS Fargate + Amazon Elastic Container Service擴充後端服務容量後，就會通知虛擬等待室服務開放更多會員同時段加入；待這些湧入的流量漸漸消化後，ECS Capacity Provider 也會減少後端服務容量。
對會員來說，雖然因為得先排隊進入等待室，讓預約流程比較慢一點，但他們不必忍受預約系統當機而乾著急，因此體驗心得反而都很不錯；而從營運面來看，這樣的雲端運用模式可以平衡支出，讓成本盡可能貼近客戶需求，創造客戶、使用者、服務端三方多贏局面。
這就是 AWS 全球機房的優勢。藉由幫客戶就近在 Amazon Elastic Container Service (Amazon ECS) 與 AWS Lambda 上建構 API 資料串接通道，讓歐美市場的健身器材客戶可以透過軟硬整合的系統來提供進階服務。
AWS Lambda 的無伺服器（serveless）概念，是讓那些會重疊使用的機台愈大愈好，同時又像共用客廳、但水泥隔間的分租套房一樣，讓每個「房間」外層包 microVM，既擁有輕資產特性，也能保障高資安。
也就是說，雖然是用軟硬整合服務外國客戶，但我們不必四處奔波採購，只要透過 AWS 一站式解決，再藉由其標準化的雲端工具作為「中繼站」，就能讓服務深入當地市場。
每次有人問我：為什麼選擇 AWS？我總很認真回答：「因為他們人都很好。」先別翻白眼，因為「人」真的是軟硬整合業者面對拓展全球市場時的關鍵。
由於 AWS 團隊遍佈全球，當我們遇到任何問題時，只要接洽其中一個窗口，AWS 就會自動幫我們轉給對的市場、對的人來協助。相較之下，假如今天 AWS 雲端服務拆分成分佈各地的多間公司，像我們這種同時又要軟硬整合、又想做國際生意的台灣業者，就得不斷在接觸各廠商的過程中，經歷冗長的溝通流程。
API 這個詞彙裡的「I」，指的是「介面」（interface），而它要中介的其實就是雙邊的「邊界」（boundary）。因為存在邊界，所以當人、貨物要流動時，中介者就會有利可圖，例如：高速公路收費站、國與國之間的海關等等。
在資料的世界裡也是如此。儘管邊界阻礙了軟硬體的整合、資料與資料的流動，但軟硬整合第二步是：只要有「標準化」，無論是像 AWS 客服流程的標準化，或是 AWS 軟體工具的標準化，都能大幅縮短業者軟硬整合的開發時間。
加快轉型速度：持續輸出、持續迭代、持續驗證
最終，軟硬整合產品開發目的仍是要能「驗證市場」，而這題同樣要回到團隊本身來自問：當產品生命週期有限，我們要如何讓推出服務的腳步加快呢？
在學習新事物時，我們都知道「輸出」是最好的學習模式。不管是把學到的新東西寫出來、講出來、動手做出來，都是驗證自己是不是「真的懂」的極佳方法。
而市場驗證也是同樣道理。當推出一個新產品，如果消費者願意買單，就代表驗證成功；而企業要存活，就要讓「推出產品—消費者買單」這樣的資源交換過程速度加快。
驗證，也會因為產品生命週期不同，而有不同目標和策略。如果處於市場還混沌不明的初期，這時候的驗證稱為「投資」；若在市場成熟期，你家有這產品、他家也有這產品，這叫做「維護」；若在市場後期，則面臨產品不再被市場需要的夕陽產業階段，但這階段往往也是企業會開始投資下一波新產品、新產業的起點。
那麼，如果企業不持續驗證會怎麼樣？答案很簡單，就是手中資源不斷消耗，卻無法再取得新資源，因而被市場淘汰掉。
AWS 就是一個持續輸出、持續迭代、持續驗證的雲端服務。亞馬遜（Amazon）最初為了面對挑戰、提升營運效率，因而持續開發各種解決方案；等應用成熟後，便於 2006 年起將這些軟體服務以「雲端」型態對外開放。
但 AWS 並不是開放後就停下腳步，目前仍有超過 9 成創新產品來自各行各業客戶的真實回饋，再進而修改成更符合市場需求的雲端服務。可以說，AWS 本身就是一個分分秒秒都在「被驗證」的雲端服務平台。
換句話說，追求軟硬整合迭代，不僅是為了符合市場需求，更是為了投資未來。
結語：
我個人以前在半導體業從事製程整合，創業後開始進行技術整合，一路都很享受「拆解」、「理解雙邊知識」、「整合」的這段過程。
整合一點都不簡單，同時需要人力、開發以及轉型，而這三者皆與「時間成本」密不可分。此外，自從成為台灣的AWS Community Hero 之一以來，我也在與各領域朋友分享 AWS 技術並獲得反饋的過程中，發現到大幅降低時間成本的關鍵，就是共享知識。
因為共享知識，才能降低人力在同一處不斷撞牆的頻率；因為共享知識，標準化工具才能讓愈多人雨露均霑；因為共享知識，技術迭代才能高速起跑。
更歡迎你來我的部落格逛逛，或加入 AWSUG Taiwan 社團，與一群 AWS 技術愛好者共享知識與經驗。
最後，希望透過這篇文章的經驗共享，祝福台灣每個業者軟硬整合都能順利，並成功拓展國際市場。
責任編輯：Chris
延伸閱讀：
最新發展：
未 滿 十 八 歲 禁 止 飲 酒 