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

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

工程師應該直接被layoff了qq

今天輪到 GCP 囉…

Cloud Networking issues in us-east1

regex 的鍋

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

update1

1. 可能影響太大了，變成舊的bucket還是可以用path style
2. 看不懂那插圖是什麼意思，磁帶機？
3. Amazon polly 感覺比google 小姐講的好，但這種技術文章還是沒辦法直接用聽的

k8s真的太複雜了，有很多是沒踩到雷不會知道

就市場趨勢考量吧xd，現在感覺也沒什麼競爭對手(swarm感覺不太行)

或許十年以後的年輕人覺得OS就是k8s，unix是類似kernel或compiler很底下的東西

我也是這麼覺得… k8s 和實機環境差太多，包了一層很奇怪的抽象。這層抽象的必要性很讓人懷疑，有 Google App Engine 的即視感。

Google 內部的 infrastructure 不太適合給外界用

反正不會有台灣

仔細看就會發現是拼裝車...

AWS 不是也有 EKS?

我研究一下後發現 k8s 也只有 GCP 可以用啊...

對耶，居然沒提醒，大概是網址不太一樣 XD

K8s 好用的前提應該是建立在有人幫忙管理 cluster 吧...

重覆貼....

k8s 還不夠, 還要再加上 service mesh 搞自己...

硬體買軟體很像EMC買vmware

也許 nginx 會步上 mysql 的命運

DB 上 docker 的好處是？跑在 K8S 上?

database 都有？！ 這可神了

database, nexus repo server, nginx server跑了 9 個多月了, 沒crash

docker 有多穩？ 可以撐一年不會 crash 嗎？

大家都在猜背後是什麼技術做的, 還有猜是 postgres

In both occasions neither OpsManager nor Mongo’s support agents were able to help us much, and we ended up solving the problem ourselves – in one case thanks to a member of the team picking up the phone from a desert on the outskirts of Abu Dhabi. 怨念很深

反正還是很賺錢沒差1

1. 兩邊都寫，直到穩定
2. query 一開始只用舊的，後來會部份用新資料，最後才會全套用。

35PB 我猜大概八成以上都是 archive 的資料，這些資料就比較好搬了

以這次35PB遷移經驗來說，Thomas Park坦言，光是要將這些資料全部搬遷到AWS環境，就花了1年多才完成，同時搬移的過程，還要確保整個資料倉儲服務不能中斷，能持續穩定運作，繼續提供原有的數據蒐集與分析服務。

這種情況通常怎麼做？例如：
1. 寫入資料時一律寫到新的資料庫
2. Query 時同時 Query 新/舊資料？

除了資料倉儲之外，Amazon也將過去沿用了20年關鍵核心財務系統用的Oracle資料庫，也都一併搬上AWS，總共搬遷多達93個資料庫、185個實例，累積120TB的資料量，現在都改使用DynamoDB雲端資料庫。經過改用新的資料庫以後，除了更易於管理，更高可靠，並且加快近一倍的反應處理時間，也替Amazon省下70%整體成本。

財務資料庫這種需要複雜的 query 怎麼轉到完全無法 query 的 NoSQL DynamoDB ??