2016 12 月，KKBOX，KKStream 以及 KKTV 共派出六位同事前往美國 Las Vegas， 參加一年一度的 AWS re:Invent 盛會。 相較於 2015 年的第一次去，這次有更完整的分工，帶回來了更多不一樣的觀點。 出發往 Vegas 前，我們各自依自己的工作崗位與個人興趣，認領了不同的議程。 只能說，非常的包羅萬象。 從最基本的 storage, computing, queuing, database, 到像是 CI/CD, big data, machine learning, IoT serverless, 或是非常重要的 cost optimization, site security, multiple accounts, … 等都有。
因此， 當收到來自 AWS Taiwan 友善的邀請參加 AWS re:Invent Recap 2016 | Taiwan， 希望能提供個十分鐘的 keynote 與台下的與會者分享時， 我二話不說就答應了，即使那個時候沒有任何想法 ;)
這個只有十分鐘的 keynote 分享，實在很難準備。 想來想去， 就挑 re:Invent 行前，KKStream 與 KKTV 最在意的三個議題來聊一下。
1. Offline Computing
Offline computing 泛指 線上 API 以外 的伺服器端計算， 目的是在與使用者的 API 脫勾前提下，執行一些常務性質、較費時、或偶發性的運算。 這些計算的計算時間單位與 API server 的很不一樣。 後者（API server）的計算時間單位是以 millisecond 來看， 而這邊提的 offline computing 則從 second, minute 甚至到 hour, day 等都有可能。
在 KKStream 與 KKTV 這邊開發的 streaming services， 有以下幾類的 offline computing 在運作中：
- metadata processing
- thumbnail processing
- audio/video encoding
- log processing
- data analysing
- report generating
- system monitoring
- routine maintenance
以下則是一些我們用來執行上述任務用到的：
- Gearman (legacy)
- cron jobs
- Amazon SQS
- Mass (based on Amazon SWF)
Gearman 沒什麼好談的，就是個 legacy。 要自己照顧 job server, worker， 還得處理不時會來出搥一下的 queuing issues。 整個 workflow 都是寫死在 worker code 裏頭， synchronous or asynchronous 的撰寫方式不同， 要工程師任意改變 workflow 還是太慢了，太 developer-relied， 不符合這個多變的世界。 如果你有點感興趣，請千萬放棄這個念頭。 至於我們的嘛，我們正一步一步努力移除它中…
cron jobs 很實用。 包括像是每天要定時出的 daily report， 每半個小時就要微調一下的 Auto Scaling policy， 每個月要出的帳單…等， 但不會有人想要維護 cron servers， 把維護人力安排到開發或是設計架構，來得更順應人心。 cron servers 雖然簡單， 但愈是簡單而基礎的系統，就愈是會被用得很兇， 然後就愈是有機會牽一髮動全身，最後變成 one of legacy。 在 cron servers 發展至不可收拾，只要一有問題或是一點小調整就牽一髮之前， 我們想讓它去 server 化。 目前有 AWS Lambda 的 scheduled events 可以頂著用先。
SQS 非常好用，而且很可靠。 但它就只是個 single-in single-out 的 message queue。 它的 At-Least-Once Delivery 很酷也很有道理（想想 CAP theorem）， 但也因此開發者要更加小心，寫出 reentrant worker/function 來才行。 它最最可惜的，就是不支援 workflow，但是我們有非常大量的 workflow-like tasks 要跑。 要基於它來實作出一個支援 workflow 的系統也的確是可行的，但就是太囉唆了點。
於是，偷了在電腦動畫產業的 render farm 的點子過來， 仿效 Pixar’s Maitre-d (Tracker)， 延用它的 job script 與相對應的 script grammar， 與同事合力下（後來幾乎都是同事在寫）， 完成了基於 SWF 的 Mass， 滿足 encoding system 的盡可能所有需求。最重要的是，它簡化了 workflow tasks。 Mass 有更多可以分享的概念，但不是這一篇的重點。
SWF 提供了 Queue, Decider 與 Worker 的組合， 加上有 retry, timeout, priority 這三個功能，非常好延展。 但我們更加貪心了，我們想要可以隨著每一個 task 的輕重不一， 自動（或手動）指定不同層級的 worker 來運算。 舉個例子，像 video transcoding 這種繁重的工作， 就交由夠力的 EC2 instance (ex, c3 系列)。 而像遵遁 CENC 的加密這種小事，交給 t2 也許就已足夠。 至於 adaptive packaging 這種事，甚至是可以考慮直接進 Lambda 就好了！ 另外，如果能有個視覺化的界面會更優~
2. Online Computing
我還記得自 AWS re:Invent 2015 回來後，我非常興奮地與同事聊著 AWS Serverless， 包括像是 Amazon API Gateway, AWS Lambda, Amazon DynamoDB 以及 Amazon Kinesis。 Python 也正式被 Lambda 納入支援的程式語言清單裏頭， 加上原來支援的 Node.js 與 Java，整個前景看好。 AWS 最常被使用（也是最賺錢）的 IaaS 解決了 IT 人員的困境（也吃掉了他們的工作）， 而 Serverless 則是把 system admin 與 developer 之間的糾結給減輕了（同時再吃掉了一些工作機會）， 軟體產業因為分工愈來愈細而產生更多的「中間工作」， 被提出來的 Serverless 的目的就是用來解決這些「產生出來的中間工作」。
API Gateway, Lambda 都很不錯，就是問題太多了… KKTV 從一開始的「全部 API 都用 API Gateway + Lambda 來實作出來」， 到後來的「開始著手研究怎麼 roll back 回 EC2 web server」的作法， 或甚至是「研發出讓一支 repo 可以很方便的在 Lambda function 與 web server 之間切換」… 你就可以曉得我們遭遇了多少讓人心驚膽跳的意外了。
舉些個例子， 你知道 API Gateway 無法原生支援 gzip 等的 Accept-Encoding 嗎？ 你知道 Lambda 的 cold start 問題以及你沒有一個比較安全的機制可以做 pre-warm 嗎？ 你知道 API Gateway 的 HTTP status 的控制與使用有一定的限制嗎？ 你知道 API Gateway 的費用支出，有很高的機會會比 Lambda 來得高出非常多嗎？ 有意思吧！
另外，我們剛經歷了 big data 的時代（持續進行中）， machine learning 帶來的 AI 又才剛剛起步， 所有公司無不想盡各種辦法，收集使用者的行為與資料， 產生一匹又一匹的 user behavior log 出來。 要讓這些 log 產生一定的回饋與貢獻， data engineering 是要做好做滿的第一件事。
AWS CTO 在台上說得好：
幾乎所有在做 data analysing 的團隊，其實並不是真的在分析。 反而是花費了超過一半的時間與精力在整理資料， 讓這些資料可以以比較容易被分析或被使用的樣貌呈現。 我們，需要一個比較優雅而自動的方式來協助大家處理這些 data engineering 的任務。
雖然 data engineering 是屬於 offline computing 的範籌， 但是怎麼快速收集/接納來自所有使用者的 log， 怎麼立即做一些簡易的 ETL (Extract, Transform, and Load)， 就介於 online computing 與 offline computing 之間了。
終究來說，我們還是很愛 Serverless 這個想法， 一方面我們就可以讓盡可能多的人投入系統開發， 另一方面，是因為我們的確沒有足夠的 SA 人員（或幾乎沒有 :D）。 經過一年的投入，我們學到了以更正確的態度來看待它，不至於有不切實際的期待。 於是我們同樣帶著滿滿一袋有關 API Gateway, Lambda 的疑問與建議，踏上了 Vegas 之路。
3. Content Delivery (CDN)
KKTV 開台的第一天，就開始使用 Amazon CloudFront 了。 很幸運（也可以是很不幸）地，一切美好，無痛。 It just works. 但 CDN 終究是個非常偏 infrastructure 的系統， 有太多地域性或地理性的限制，也許是來自法規，或甚至是來自不友善的 ISP 造成的。 在接下來的幾個月，每個月都有 CDN 大問題 要處理的。
也多虧了 KKTV 上線後使用 CloudFront 的經驗， 我們接著導入了 EdgeCast （感謝 KKBOX 大傘）， 考慮了 Akamai， 還找了個二房東臨時導入了中華電信CDN （感謝不具名的二房東）， 另外也導入了 KKBOX multi-CDN solution。 如果說，要立即對於一個領域有一些經驗與看法， 最快的方式就是執行、導入、面對問題、解決問題… CDN for video streaming 就是在這樣的情況下，一路踫壁往前進。
After AWS re:Invent 2016
Key message will be to show our commitments to provide more services which our customers need on the cloud. Customer obsession.
– AWS Evangelist
1. Services for our offline computing issues
re:Invent 第二場 keynote, AWS CTO, 帶來了更多驚喜的服務出來， 其中的 AWS Batch, AWS Step Functions 以及 AWS Glue 實在太讓我意外了。
- AWS Batch 讓你專注在想執行的 command，由 AWS 來幫你啟動必要的 container (ECS)。
- AWS Step Functions 讓你可以以更偷懶的方式達成 SWF 可以做的事（如果你還沒有用 SWF 的話），還提供 workflow 的視覺化呈現！
- AWS Glue 把你從 ETL Lambda functions 地獄救出來…
AWS Batch 是個有意思的服務。 名字叫 Batch，但帶有 cron job 的意味，但它最重要的特色是：
AWS Batch dynamically provisions the optimal quantity and type of compute resources (e.g., CPU or memory optimized instances) based on the volume and specific resource requirements of the batch jobs submitted.
換句話說，它允許你在每一個 batch job 裏頭指定執行的機器的等級或是硬體規格， 然後它會自動根據每一個 batch job 的設定，動態準備好相對應的機器來做運算， 運算完畢後，再自行關掉。 這整個過程中，你不需要事先開好機器。 運算可以是 EC2 on-demand instance, EC2 spot instance 或是 ECS。
2. Ideas for our online computing issues
除了 API Gateway，Kinesis 也是 Lambda 的好朋友。
API Gateway & Lambda 在 EBC 裏頭談到的未來發展。
Elastic GPUs 是個了不起的一步。
3. Ideas for our CloudFront or CDN issues
（以上待補完。如果你感興趣，請留言催促我或加油打氣~）
Afterthoughts
1. Serverless is everywhere.
我猜，Serverless 會持續大放異彩，它不會取代掉自行架設 API server 這個作法， 但是它會大大的改變一些遊戲規則，尤其對於 startups 來說。
AWS 已經提了幾年 Serverless 這個口號了呢？我不曉得。 我只知道，在今年的 re:Invent 裏頭，到處都看得到它的影子：
- Greengrass: IoT 上也可以跑著與雲端上一樣的 Lambda。
- Snowball Edge: 硬碟公事包（原諒我給寫這麼一個粗俗的藝名）上也可以跑 Lambda。
- Lambda@Edge: 想要更快更輕量，更接近你的用戶所在地的 Lambda？試試這個就對了。
- Alexa: 想透過 Alexa Skills Kits 寫寫客製化的 hands-free UI？
- Kinesis Stream: 資料流可以直接串接 Lambda 而完成第一階段的 ETL。
- AWS Batch & AWS Step Functions: 更隨意的透過 Lambda 來組合出你要的 offline computing。
- AWS Glue: 更簡易消化 data processing / data engineering 的任務。
如果說，machine learning 是接下來二十年的黑科技， 那麼 serverless 無疑會是接下來的十年裏，非常重要的基礎建設中的一環。
2. EBC is your good friend.
Executive Briefing Center，簡稱 EBC， 是個藉由 re:Invent，在你的 account manager 的安排下， 讓你有機會與 AWS service team 直接面對面談個 40 分鐘的私人會議。 它是私人的，因為只有與會的你與 AWS 開發團隊。 它是個會議，因為你們會被關在一個會議小包廂，直接時間結束或討論完畢。
一般來說，親臨會議，大部分人是抱著看熱鬧，想親身體驗氣氛或風向，想與主講人聊聊天的。 事實上，你坐在地球的任一個角落，只要有網路，而且沒有在什麼「長城」之後的話， 你是可以直接透過網路就看到（直播）錄影，追蹤即時的 tweets/posts， 之後拿得到投影片，甚至更懶可以直接看別人寫的 blog 評論，就獲得一些知識了。 嚴格來說，如果你是想學點什麼的話，不需要去參加會議，只要上網就行了。
EBC 則很不一樣。 它讓你可以直接與 AWS service 的官方開發團隊踫面。 一般會是一位 manager，旁邊會跟著一位 technical engineer，兩個人一起出席。 於是呢，你有機會在很用力的當了一年的 API Gateway + Lambda 白老鼠後， 直接提供第一手的問題與觀點，與開發的人對談。 聽聽他們怎麼看待你的問題，也讓他們聽聽你怎麼描述你的問題與需求。
EBC 是我覺得整個 re:Invent 最有價值的其中一個議程。 至少，你在聽 session 時會睡著，在 EBC 裏頭開會時，可是腦袋清楚得很！ 所以，派人去 re:Invent 時，要怎麼挑你的團隊組成，應該有個底了吧 :)
3. Nearly every service has some company’s backup.
AWS 是個非常有意思的公司，客戶至上（Customer Obsession）是它的金科玉律。 即使在 AWS 官方的徵人網站上，你點去看看裏頭的那一頁 Leadership Principles 時， 會發現到 Customer Obsession 就列在第一點。
某個程度上來說，我們可以說 AWS 的每一個 service 後頭都有一匹客戶的背書。 所以，當有一個新的 service 或是 feature 被釋放（GA?）出來時， 大抵你可以直接假設， 後頭已經有一匹巴不得這個 service 或 feature 早點出來的開發團隊了。 這個觀點有個非常重大的意義與影響。
我們來舉個假設性的例子好了。 你覺得 AWS 為什麼要來提這個 Serverless 呢？ 這個是它原創的嗎？應該不是。 那是不是可以假設，在過往它接觸到的成千上萬的客戶中， 有一些跡象促使 AWS 開始想 serverless 了呢？ 有很高的機率，答案是 Yes！
所以，當一個新的 service 或 feature 問世時， 如果你第一時間覺得很無感，或是覺得它還太陽春，無法滿足你的需求時， 不妨換個角度想想。 也許，你潛在的競爭對手已經開始在改變他們使用 AWS 的方式了！ 也許，某個角落已經有一群人（公司）正在透過這個簡單的 feature 加速某個開發流程了！ 也許，你再兩年就要開始請你家的新人去 K 這方面的官方文件了！
也許，這會是 AWS 成為 cloud computing 霸主， 而 Google, Microsoft 以及 IBM 等只會成為 cloud computing 追隨者的關鍵差別。
4. Let’s play as customers hardly.
Customer Obsession 是可以從另一個角度來看的， 如果我們試著運用一個 creative thinking 的小技巧： reverse。
AWS 官方宣稱它是這麼一家客戶至上的公司， 有一位 AWS 內部員工甚至這樣告訴我：
「有時候我覺得，我們 AWS 根本沒有什麼 roadmap， 有的只是大量來自用戶的需求， 然後從中訂出我們的開發項目與時程出來…」
– AWS anonymous
所以，如果你是在 AWS 工作的主管， 你最在意的其中一件事會是什麼呢？ 我猜，是有沒有從客戶那邊收集到夠明確而有意義的需求或是問題清單。 反過來說，如果你是 AWS 客戶，是不是應該用力扮演好你的角色呢？！
讓我們一起扮演好拉著 AWS 往某個方向前進的客戶， 提供更多的資訊（與壓力）讓 AWS 朝向我們希望它會開發或是發生的服務或項目， 讓我們既明示且暗示來誘導 AWS service 的開發與 bug fixing 是朝我們想要的方向發展~
過去，我們夥同其它 AWS 客戶（我們還沒有大到可以單獨影響 AWS） ， 在努力的回饋下（這有一些技巧），讓 AWS SWF 支援了 priority。
5. We host our fast forward and minicon, and you?
AWS re:Invent 完，我們仿效 SIGGRAPH Technical Papers Fast Forward， 也在公司內部辦了個 AWS re:Invent 2016 Fast Forward。 使用 Google Slides 共筆下完成了投影片， 共同分享。
另外兩位同事提議了 FF 結束後，讓大家來認領不同主題，接著發起 n 場 AWS re:Invent minicon。 不小心創造了社內 AWS re:Sharing~
