Life is a YOLO game

Sudo 開發日記 2016-04-29

May 03, 2016

工作內容

  • 持續推進 app 其他元件的進度。
  • 下一週送審第一版後會開始重構,我隱約感覺這會是 React Native 的重頭戲,也會是下週分享的重點。

其他新東西

1. 關於 AWS 架構的反思

最近迷上 AWS 那 用多少,收多少 (一個月十美金撐著四個 php 網站 + 一個 Dokku 建立的 Heroku-like 平台,根本物超所值) 又極為彈性的架構,一股衝動上來想要把所有的現有架構全部搬到 AWS 上,卻落入了 過度設計 的陷阱。

上週曾試著使用 AWS Lambda 寫一個模擬 web cron 的小 app。在使用 AWS Lambda 之前,我是透過一個簡單的 Rails app 去達成一樣的目的。

為什麼你不使用 Linux cron 就好了呢?

這是我跳脫 Linux cron 架構之後最常被問到的問題。原先想要從 Linux cron 搬出來的原因是 Linux cron 太依賴主機,在這個 主機是畜牲,不是寵物 的虛擬化平台年代,每一台主機都應該具備 immutable 的特性, 就算主機消滅了,只要透過系統化的步驟,就可以讓服務在可控制的時間內重新上線

搬出來之後,我研究了 Rails app 的 scheduler,研究了 Rails 如何與 Slack 串接然後發送通知。實際串接一個已上線的 Drupal 網站測試兩個月之後,我觀察到以下情形:

  1. 我根本不 care Slack 送來的通知,因為我內心深處知道一定又是一個成功的 cron。這讓 Slack 通知變得非常雞肋。
  2. 如果 cron 執行失敗了,會另外發送電子郵件提醒,而 Drupal cron 失敗的機率又非常低。

於是,三個月之後,歷經 Linux cron、SetCronJob、AWS Lambda 之後,我又回到 Linux cron,配合 Uptime Robot 接收網站下線警告。這是我最初的架構,也是最穩定、最簡單的架構。

工程師應該要想辦法降低自己的工作負載,而不是讓自己一直過勞。 — 佚名 實際上是我忘記誰說的了 XD

其實 AWS Lambda 讓我想起 Parse 之前推出的 Cloud code,兩者簡直是一模一樣的服務。只是隨著 Parse 被 Facebook 死刑定讞,那些過往雲煙就讓它隨風飄逝吧。


Henry Wu
Written by Henry Wu who lives and works in Taipei producing some nasty bugs.
Author: Henry Wu License: MIT License: CC BY-NC-ND 4.0