大部份的程式加上 parallel() 後不會變快，甚至還會變慢...

1. 從 ec2 instance 搬到 k8s 之後發現，現在 cluster 一死掉，就是全部服務一起死。不像以前 ec2 個個虛擬主機是獨立的，隨便掛一個都沒差

2. k8s 適合跑的應用都是 stateless，更廣泛一點說，就是 cloud native app。因為這樣，所以Pod、Job…等等元件要 scale 和重啟都好輕鬆啊！但其實有另一大塊是 stateful app 很難搞定，許多人乾脆 stateful 的通通不放 k8s 裡了。然後更妙的是 k8s cluster 本身就是個 stateful app，而且不符合 cloud native 的定義。這算是呼應第一點，當 cluster 壞掉時，你沒辦法很容易啟動新的 cluster 原地復活。

3. k8s 太複雜了，而且未來只會更複雜，因為目前不斷有新的標準產生。依照過去十幾年的經驗，過度複雜的系統最後會被簡化過的新架構取代，感覺 k8s 也是個過渡性產品。

4. 與 k8s 成對的是 microservice，甚至有人還說: 如果沒要要用 microservice，何必用 k8s ? 問題是 microservice 這種分散式泡沫一定很快就會消失，因為前例太多了，像是 EJB、WebService、SOA... 等等

k8s 現在有很多小廠商提供產品和服務，大廠則是不斷推出相關的新產品，然後又有証照可考，未來很多企業都會導入的。從這角度來看似乎很正面，但這個超級像過去的 J2EE，有標準、有証照、有一堆免費和商用 container 可選 (以前 J2EE server 也叫 container，這不是巧合)。你看看 J2EE 現在還剩什麼廠商吧…

當然啦，技術本來就會隨時代迭代，這個十年可能就是 k8s 稱霸，而十年也夠久了，投身這門技術可以讓自己有競爭力，企業也會因為標準化，尋求人材時會簡單許多。要說短期內會出現的缺失，就是因為 k8s 變成顯學、標準化，造成大家不適用 k8s 的系統也會硬套，然後又難學難管理，白白增加成本。

上個月研究完 k8s 後, 就把公司的一堆小服務通通丟上去了.

不過我現在是半後悔狀態...

通常 second level cache 可做的事都會在更前面擋掉 (例如網頁的 cache) 所以 2nd cache 沒事不用去碰，用比較宏觀的角度去最佳化比較好

security best practice, No.1:

Always blocks pastebin in production, here are steps to configure security group via aws cli...

此人到處興風作浪，所到之處遍地荒野，無奈治不了他，只能寫寫網站吐吐槽 (loop)

還價值投資咧...

bug 修的差不多囉

我也破了...

初期主角太弱, 中年大叔我一直打不過boss, 難度有點高

謎題的話後面有二 三個地方太難找, 只好翻攻略.

整體來說不錯, 演出鳥了一點

我還以為是說 Xㄉ.... 咧

看起來是吐槽 Lombok ，跟 kotlin data class 沒什麼關係

σ弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌弌⊃

今天輪到 GCP 囉…

Cloud Networking issues in us-east1

靠北，我剛 enable 就收到十幾封信…

regex 的鍋

可以想像又要加新的壓力測試項目，cpu 變化偵測 (我猜早就有了)

這個好物！

全部用 kotlin 重寫了

JSON.parse('{"foo":42,"bar":1337}'); 這個居然比 json literal 還快，WTF

K8s 紅到可以讓 gcp 幹掉 azure 了

然後 EKS 不算在 managed service, 這很可以

怕什麼！

遲早會被擋的

醜...

value wrapper 讓學習曲線直線上升，誰會記得所有的值都要包一層？

部落格平台會倒, 不知道已經證明幾百遍了.

想寫/想出版還是自己架個站吧

最近怎麼這麼多 taiwan 上 hacker news

sign in with apple 的特點就是可以產生一組假的 email 給 app 用. 所以不行...

oh, 查到 有 js API1 ，也有 restful API ，那非 Apple 平台就可以用了。有整合 sign in with apple 希望不要再要求做 email sign in 了.

不過在 Android 上因為沒 sdk 所以大概很難用