Infrastructure-as-code 如何改善我們的生活品質？
「除了在東京以外，也要在美西建一座一模一樣的機房喔！」
「這應該很~~簡單吧，照著原本的東西點一點，拉一拉就好了啊」「大概要忙上半年，準備上線最少再三個月，接著踩一堆雷後一年後上線，時間久了後，兩邊狀態越來越不一致，整天陷在改東改西的日子裡，最後走向毀滅」某工程師內心這麼碎念著…同時也悄悄地打開 LinkedIn，思考著自己的下一步...(~本故事純屬虛構~)
Infrastructure-as-code (IaC) 一詞在雲端運算出來的幾年後開始被廣氾討論，各新創公司也紛紛在創業初期選擇了公有雲 (如AWS, GCP) 做為平台，在沒有老舊系統的包袱之下，朝 IaC 這條正確的道路前進。甚至連一些穩定的大型企業也漸漸捨棄行之有年的實體機房 (On-Premise Data Center)，投入 AWS/GCP 的懷抱，開始評估並導入 IaC。
然而，新創公司求快速，大企業求穩定，願意在初期就紮實地走在 IaC 的道路上其實不容易，究竟它有什麼樣吸引人的地方？讓大企業與小公司都願意為他投入資源？
KKStream 在一開始就決定走向雲端，而且，也願意採用 IaC 來建置所有的雲端資源。
說 Data Center 是一間公司的命脈絕對一點也不為過，舉凡伺服器，資料庫，原始碼，通通都存放在這裡。看看電影裡面要偷取重要資料，是不是都會潛入一座充滿電腦主機的地方呢？就知道它的重要性了。
在這十年之間，Data Center 建置的變化與管理之大，並不亞於其他蓬勃發展中的技術，個人以下粗略地將 Data Center 分成三個不同時期：
農業時期
我們在黑暗中尋求光明
企業選定某個風水寶地，租用一間實體的機房(或其中的一區)，有著森嚴的門禁與不斷電系統，穩定的政局與相對便宜的水電費，並雇用一群專家來管理這上百台、上千台的機器。包含每一個伺服器配置、資料庫設定、網路路由、Load Balancer、系統升級、甚至到硬體的更換，都由手動或是搭配一些難以維護的 script 去操作，有時候也需要透過 SSH 直接登入 production 的機器來升級或配置。
在這樣的時代，付出大量的金錢(機房租金/人力)，深怕忽然停電，配置錯誤，人員變動/請假，甚至機房因為某些原因爆炸(?)而造成損失。任何的變更都是緩慢且難以復原，每一次的變更都要經過層層審核，拖慢了產品迭代的速度。
工業時期
“ 工人智慧 ”引領全球
雲端服務興起後，世界變得不同，人們開始擁抱像是 AWS 或是 GCP 這樣的服務，透過 Web Console 或是 CLI ，建置一套完整的 Infrastructure 變得極快，大幅度減輕了維護的成本與迭代的時間。不過這些操作仍然是由「人」去操作，只要是由人去做的事，就有出問題的可能，也許是因為時間關係，忘記當初是怎麼做的，又或許是「換人」了，每個人的習慣不同，做法不同，都會造成結果不同，久而久之，即使制定好的 policy 也會漸漸變得模糊。
舉例來說，我可能花了一個月幫團隊建立好所有的基礎設施，其中包含了 testing/staging/production 的環境，過了幾個月後，當有東西需要修改時，我必需透過 Web Console 或是 CLI 去操作三次，甚至幾個月後，需要把整個環境從東京搬到美西，因為每個元件都層層交錯，必需要極度小心，把數個月前手動建立的東西完完整整再做一次，只要有一個地方出錯，很有可能整個系統就動不了。
對於短期的且有時效性的專案，這已經足夠，但是對於想要長期發展的專案呢？很明顯還是不夠完美。
科技時期
給我一份 “ code ”，我給你全世界
科技時代導入了 Infrastructure-as-code 的觀念，原先由「人」透過 Web Console 或是 CLI 來操作的思維，取而代之的以寫 code 的概念去管理/建立/維護你的 infrastructure(見下圖)，由「人」決定邏輯，讓「機器」幫你做事，這帶來了以下幾點好處：
- 速度與可靠性，所有的建置都是全自動化的，這比透過 UI/CLI 操作來的更加快速與可靠。
- 基礎建設 的 source code 可以被 version control tool 所管理 (如 git)，這代表任何的改變都有跡可尋，也可以讓大家 review ，如果發生問題，也有辨法快速 roll-back。
- 基礎建設 的 source code 可以輕易重覆使用 (就像把重覆的功能抽出變成一個 function)，並且如果要 deploy 到不同的環境或是不同的地理位置也都沒問題。
- 有順序地新增與刪除資源，把資源的相依性定義好後，這些資源會完全按照 code 裡面定義的順序去新增，就算是移除也一樣。
- testing/staging/production 環境會長得幾乎一模一樣，這對開發和維運人員來講，是作夢也不敢想的事情，也減少了非常多環境相依性的問題。
- 最重要的是 — 它讓工程師的生活變得很開心，手動做重覆的事情，既枯燥又容易出錯，如果能自動化做到這些事情，把時間省下來多跟正妹工讀生聊聊天，何樂而不為？
「科技來自於 “墮性”，在這個時期，只要握有 code ，就等於握有全世界。」
實務上的挑戰
若是已經在工業時代的專案，該怎麼進入科技時代呢？
理想上，導入 IaC 可以解決許多由「人」造成的問題，但是實務上也會碰到不少難題，例如：
- 我的服務已經在線上跑的安安穩穩，一秒鐘幾百萬上下，雖然手動有點麻煩，IaC 很好我也知道，但能不動就不動。這是最常見的問題，還記得在某堂 AWS 訓練課程裡，講師提到的一句話：
Do the Right Thing in the First Time
一開始不做，之後會很累，能在專案開始時就同時導入 IaC 是再好也不過了，但總會因為某些原因而沒有這樣做。然而，最佳解還是「不要再拖了」，越不開始做，之後就越不會做，埋下的坑就越大，也是累到以後的自己，長痛不如短痛，只要能開始就不嫌晚。
- 沒有人力/資源去做這件事情其實所有的專案都有一樣的問題，只是看大家夠不夠重視，如果重視的話，自然有辨法排進 schedule 中，能做的就是讓大家知道這件事的重要性與必需性，當大家開始重視而漸漸變成一股風氣，想不做也不行了！
- 學習曲線過高比起手動操作 Web Console/CLI，寫 infrastructure-as-code 的確讓不少人怯步，其主因在於每做一次改變，都要等待數分鐘(有時甚至要到十分鐘左右)才知道結果是否正確，對於剛開始學習的人會是一件非常消磨耐心的任務，在沒有人帶的情況下，常常一整天就在 trial-and-error 過去了，什麼事也沒做到…這讓我回想起幾年前接觸 IaC 的慘痛回憶。
不過，這會是一項值得的投資，若是團隊內有人可以問，有 code 可以抄的話，學習曲線就變得平緩許多。
經驗分享
在 KKStream 中，我接觸到的第一個專案就是處在工業時代，所有的服務已經上線，但是環境都是手動建立的，包含 testing/staging/production 皆是。
為了往後大家的生活品質著想，第一件事就是把它推進科技時代，在用 IaC 重新建立好環境後，使用 Route53 分配權重，在兩套系統並行的情況下，確認新環境沒有問題後大膽切換過去，最後在沒有產生 downtime 的狀況下，成功地轉移成功！前後大約花了兩個月的時間。
此後，專案中所有的 infrastructure 就如下圖一樣，透過 code 去建置全部的資源。這也是 KKStream 中第一個，但不是最後一個採用 IaC 的專案。
Infrastructure-as-code 有哪些工具可以用
目前兩大 IaC 的工具為 AWS CloudFormation 與 HashiCorp Terraform，前者為 AWS 官方服務，同時支援 JSON 與 YAML 的格式，與 AWS 其他服務整合良好且快速，線上資源豐富，官方文件詳細。後者為知名公司 HasiCorp 推出的工具，除了支援 AWS 外，也支援 GCP ，有著易讀易上手的優點。
各有各的優缺點與擁護者，在 Google 上也有不少比較文可以參考。
在進入 infrastructure-as-code 的世界後，有哪些注意事項？
- 手動操作是包著糖衣的魔鬼，千萬遠離它，當一切都自動化就緒後，一個看似平凡或是偷懶的手動介入，都有可能造成不可預期的結果，如果已經全自動化，就照著自動化的流程操作吧！
- 落實 CI/CD，infrastructure-as-code 之所以強大，在於他用管理 code 的方式對待所有的基礎建設，因此，將 IaC 與 CI/CD 做結合，才能發揮 100% 的威力。
- 減少 hard code，就像一般寫 code 一樣，沒有人會覺得 hard code 是件好事，在寫 infrastructure 的 code 時也一樣，相關的參數都抽出來變成可調整的而不是寫死，保留彈性卻也不要 over-design。
最後，不論是 CloudFormation 或是 Terraform，能進入科技時代的就是好東西。
