前陣子開了一場會議是有關於公司該怎麼把混合雲的架構做的更穩固，覺得應該把一些經驗記錄下來 …
入坑 – 這是一個弄到嫑嫑的坑
事情是這樣的 … 大家都想上雲端，因為上雲端很潮或是聽說很好用?!，手指點點點就搞定、上線很快、人家都幫你做好了 … 等等之類的。
但有些事情不是往往不是這麼簡單 … 越是大型、年份越高的企業要導入雲端相對困難許多，在貿然導入雲端架構前必須要審慎考量現有的產品是否適合上雲端。
在這個系列文會把實務上的經驗分享出來，不見得適用每間公司，但也許會有與你相同之處可參考：
評估
由於小弟公司在加入之前就開始佈署少量的 AWS 的專案，在加入公司後更是開始大幅將產品遷移至 AWS 雲端，所以面臨幾種狀況：
- 有大量的專案在傳統 IDC 機房建置，並且專案與專案之前的關聯太深，無法輕易遷移。
- 有少量的 AWS 專案，使用獨立的 AWS account 建置，與 IDC 串接必須打洞或像 AWS Kinesis 這樣的服務來交換資料(非即時)
- 大多數的工程師沒有任何雲端的經驗，甚至可能基本概念都沒有。
- 用大量人力來執行工程專案。
- 擁有大量個資，資安防護非常重要。
由於公司評估後決定要開始遷移 IDC 專案至 AWS 上，種種的考驗一擁而上，像這樣的大型傳統企業無法一下就”蹦”的全部往雲端上丟，原因是在傳統 IDC 的程式、系統設計上都無法直接套在雲端上的概念，例如：
- 雲端上沒有 IP 的概念，都是使用 Domain。
- 雲端講究自動化、速成、有需求即用，而 IDC 反之，習慣 ssh 登入、有需求要調配人力、準備高於產品需求的資源避免應變不及。
- 沒有 multicast。
- etc
這邊會有幾個面向要想：
- 成本
- 資安
- 雲端概念的灌輸
- 技術培訓
- 自動化
- 雲上與地下的架構與管理
- 專案導入流程
除了這些可先預想到的問題以外，最重要的還有企業的文化，還有永遠計畫趕不上變化的專案上線時程。
成本
你想想一間高齡企業的專案 “會賺錢的專案” 大多都是以傳統架構下開發，甚至老舊不堪的框架、架構、程式版本，最後呈現改不動的情境 …
這類型的專案若要轉上雲端勢必是使用 EC2 這類的 IaaS 服務才能夠快速的轉上雲端，但 AWS 上最 “貴” 的 Service 莫過於 EC2，在不改動原有程式架構下上到雲端的技術成本可能是最少，但費用卻是可能比上傳統 IDC 貴上許多。(不考慮上雲後大幅降低的維運成本)
如果有這類型的專案存在，你的雲端架構往往會變成 Hybrid cloud 的架構，需要花上大量的時間將舊有的產品拆分出來進行優化、架構調整，亦或是 API 化來一步一步拆解上雲端。
小弟看過許多上雲端的專案，能有大量的 cost down 大多是採用 Serverless 的架構：
Serverless 一詞是近年開始流行的字，其主要概念就是讓你不再需要去維護 Server，沒有 Server 就沒有 infrastructure 的問題，但不是沒有 infrastructure，而是在雲上雲端公司都會替你處理好 Server and infrastructure，並且承諾 SLA。
試問各位 System manager 即使有做到 HA or Load Balancer，我想各位都不見得能夠保證能做到完全的 99.95% 的可用性，但雲端公司大多數服務都直接幫你做到 DR for region 的程度了。
再來就是 Serverless 的 Service 通常很便宜，AWS 就很大幅的推薦 Serverless 架構，而且用 “價格” 來吸引你投入 Serverless，如 AWS 很強大的 Lambda 除了每年免費的額度以外費用也便宜的 .. 驚人 !!
Serverless 的好處講完了，現在講缺點 … 通常 Serverless 的 Service 不會告訴你怎麼運作的，你就只是用，所以你遇到 bug 只能求助 AWS，所以你的成本要再加上 AWS support，這是使用雲端服務很重要的一環，當你的產品很重要絕對少不了。
服務是無價的，能有價買到的技術服務很便宜。
再來就是技術力，在台灣要能找到開發全 Serverless 架構的工程師並不好找(目前)，總總因素加起來 Serverless 的架構並不容易，但在國外已經很流行而且有很強大的執行力，所以也就是為何常常看到國外企業能常常分享上雲端後能大幅 cost down 的原因，不外乎就是善用 Serverless 的架構。
資安
針對大部分的台灣企業，總是會妄想資料被竊走然後公司倒了，其實我想說的是 Github、Facebook、Slack、Linkedin .. 等大公司都在用了，我想在台灣應該沒幾個企業能夠和這些公司比擬。
在 AWS 上有 ACL、Security Group，而資安的方向將會改以 “稽核而不限制” 的方式去掃所有 Security 相關的項目
而在 Application 層，AWS 的標準架構是以開放的概念為基礎，通常沒辦法要求全公司的工程師都有很好的資安概念去設計你的程式，除非你是 startup 能在一開始就篩選你的工程師程度，如果真的需要在這個地方坐一個控管點，那只能放個 Proxy or NAT Firewall 來做，Firewall 可以直接參考 AWS 上的 AMI Marketing 找到大廠提供的 AMI images。
延伸閱讀：
