關於 開發者工具關閉 ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://ably.com/blog/no-we-dont-use-kubernetes

八月第一篇，就來個有趣的文章，來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes，不但當前沒有使用，甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊，千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。

我個人覺得這篇文章滿好的，因為是認真的去比較導入 Kubernetes 帶來的改變，而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云，人家要我也要，人家不要我也不要...

文章分成兩部分，前述介紹當前 Ably 的環境架構是什麼，而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下，會發現導入 Kubernetes 沒有帶來實質上的好處。

文章開頭先簡述了一下 Kubernetes 這幾年的風潮，從最初 Google Borg 的開發開始談起，作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用，
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中，透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果，對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。

Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider，並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container，取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。

對於 Ably 來說，團隊中沒有任何 scheduler 相關的服務來調度各種服務，這意味每個 VM 就代表一種服務，所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務，用來確保運作的 Container 如果掛掉後可以被重啟，甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。

流量方面，因為每個 Autoscaling Group 就代表一個服務，所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題，畢竟每個機器本身都會被 VPC 賦予一個 IP 地址，所以使用上沒有什麼太大的問題。

接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變，分別有 (原文很多，這邊摘要不然文章會太長)
題外話，由於 Ably 的 Infra Team 數量有限，所以要考慮 K8s 只會考慮 K8s Service，如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM，畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說，透過這種方式能夠盡可能的榨乾機器的資源，整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源，這種被稱為 nosy neighbors 的常見問題已經不是首次出現了， Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用，而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務，不過這個做法跟團隊目前的作法已經完全一致，所以就資源管理這一塊，團隊看不到使用 Kubernetes 的優勢。

2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量，基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務，所以其收費是針對客戶實際上用多少服務來收，如果開了過多 EC2 VM，則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量，
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整，根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點，但是閒置並不代表沒有任何服務部署再
上面，因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說，k8s 有兩個動態調整的部分，動態節點與動態服務，而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。

3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案，基本上團隊只要能夠維持每個服務與背後的機器的關係圖，網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務

K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP，這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller，這些 Container 可以跟 AWS LB 直接整合，讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定，所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。

4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本，後續相關機制就會將 VM 給替換掉，然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果，雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。

上次四個分析基本上就是，使用 k8s 沒有帶來任何突破性的好處，但是 k8s 本身還有其他的功能，所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處

Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭，「除非經過評估，否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊，同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說，光 Storage 每家的做法都不同，而 K8s 沒有辦法完全將這些差異性給抽象畫，這意味者開發者終究還是要針對這些細節去處理。

Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由，畢竟這種用法就跟當初 Google Borg 用法一致，是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時，底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫，所以這個優點也沒有辦法幫助到團隊

Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC，所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。

Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群，社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下，一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s，但是真正理解 k8s 的人微乎其微，所以想要透過社群來幫忙解決問題其實比你想像的還要難，畢竟裡面的問題太雜，很多時候根本很難找到一個真正有效的答案。

Added Costs of Kubernetes
為了轉移到 K8s, 團隊需要一個全新的 team 來維護 k8s 叢集以及使用到的所有基本服務。舉例來說，EKS, VPN CNI, AWS LB 帶來的網路好處並不是啟動 EKS 就會有的，
還必須要安裝相關的 Controller 並且進行設定，這些都是額外的維運成本。
如果找其他的服務供應商來管理 Kubernetes，這意味公司就要花費更多的$$來處理，所以對團隊來說，金錢與工作量都會提高，不同的解決方式只是這兩個指標的比例不同而已。

結論:
1. Ably 覺得 Kubernetes 做得很好，但是團隊目前沒有任何計畫去使用它，至少目前這階段沒有看到任何實質好處
2. 仔細評估後會發現，導入 k8s 其實也會帶出不少管理上的問題，反而並沒有減輕本來的負擔

0608華爾街日報

*【G7劃定跨國企業最低稅率，實施道路恐將崎嶇不平】
富裕國家就跨國企業最低稅率達成一項協議，但未來的實施道路恐將崎嶇不平，多國政府可能會靜觀其他國家、尤其是兩黨勢均力敵的美國國會將如何行動。
https://tinyurl.com/yyu832b5

*【美國FDA批准近20年來首款阿茲海默症新藥】
首款有望減緩阿茲海默症剝奪記憶速度的藥物，獲得美國健康監管機構的批准，這是在經過多年研究和數以十億計的投資後的一個轉折點。
https://tinyurl.com/yyo8nyel

*【美國將與台灣重啟貿易投資談判】
拜登政府將與台灣展開貿易與投資談判，推進美國與臺北的關係，這可能增加美國與中國之間的摩擦。
https://tinyurl.com/y5qzxoqp

*【G7呼籲強制要求公司披露與氣候有關的金融風險】
七大工業國呼籲，要求公司報告氣候變化對其業務的影響，這可能會加快在達到與投資者相關的環境、社會和治理數據披露的全球標準方面的進展。
https://tinyurl.com/y6cy3mqm

*【跨國公司考慮撤離香港】
由於憂心香港未來能否繼續成為在中國及周邊地區營商的最佳據點，一些跨國公司正遷往別處。作為全球具有重要地位的商業城市，香港的前景愈發飄忽不定。
https://tinyurl.com/y3exu3rf

*【強監管之下，中國的比特幣挖礦主導地位還能保住嗎？】
多年來，即便中國企業家已經成為生成比特幣的主力軍，但合法的比特幣交易在中國一直未獲批准。最近有關打擊加密貨幣的警告凸顯了這種貨幣在中國的脆弱地位，可能會促使一些加密貨幣礦商將業務轉至西方。
https://tinyurl.com/y3w7935y

*【中國對科技公司的整頓迅速鋪開】
中國針對科技公司的最新一輪監管行動表明，馬雲麾下的阿里巴巴並非唯一受到監管審視的企業。
https://tinyurl.com/y4uyhj8d

*【中國三孩政策下，押注嬰兒潮還是老齡化？】
中國新生兒大增的希望渺茫，但醫療健康需求上升將是大勢所趨。
https://tinyurl.com/y3llttz3

*【中國5月出口同比增速放緩至27.9%，進口加快至51.1%，均不及預期】
與前值相比，中國5月份出口增速有所放緩，不過，進口增速顯著加快，貿易順差也有所擴大。與市場預期相比，該三個分項全面不及預期。
https://tinyurl.com/yyaklbm7

*【中國5月外儲連增兩月，也強於預期】
中國央行週一午後公佈的數據顯示，5月底外匯儲備餘額為3.2218兆美元，環比增加236.23億美元。隨人民幣匯率連續升值，5月份外匯儲備連增兩個月，也強於預期。
https://tinyurl.com/y3jpmftb

*【小紅書6月4日微博發問後賬號被封，遭中國網信辦調查】
小紅書的微博賬號被封，其背景是中國網絡監管機構調查該賬號在1989年天安門廣場事件紀念日發布的一則帖子。小紅書是一家與Instagram類似的熱門中國初創企業，其股東包括中國兩大科技巨頭。
https://tinyurl.com/y663uk3o

*【蘋果開發者大會正式發布iOS 15，庫克宣佈FaceTime和錢包等軟體更新】
蘋果公司首席執行官庫克為為期一周的全球開發者大會拉開了序幕。在蘋果公司網站上播出的虛擬大會宣佈了今年計劃推出的一些軟體更新。
https://tinyurl.com/y4aw7xkj

*【亞馬遜創始人貝佐斯將搭乘Blue Origin的首次載人太空之旅】
亞馬遜公司創始人貝佐斯計劃下個月作為Blue Origin搭載的首批乘客之一進入太空，Blue Origin是貝佐斯創辦的一家太空旅行公司。
https://tinyurl.com/y3f8qkxk

*【Google將支付近2.7億美元罰金和解法國反壟斷案】
法國競爭監管機構表示，除了處以2.2億歐元（2.677億美元）的罰款外，該機構還接受了Google為解決此案提出的承諾，其中包括承諾讓競爭對手更容易使用其在線廣告工具。
https://tinyurl.com/y3rampt8

*【美國追迴向Colonial Pipeline駭客支付的數百萬美元比特幣】
美國執法官員說，他們追回了向上個月勒索攻擊Colonial Pipeline Co.的駭客支付的數百萬美元數字貨幣，那次攻擊導致供應美國東海岸汽油和柴油燃料的主要輸油管道關閉。
https://tinyurl.com/y5mpf94c

*【亞馬遜今年將在義大利增加3,000個工作崗位】
隨著義大利消費者越來越依賴互聯網購物，亞馬遜公司計劃擴大在義大利北部的業務規模，該公司將在今年年底前在義大利增加3,000個常設工作崗位。
https://tinyurl.com/yxnofgzs

*【美國5月新增非農就業崗位55.9萬，失業率降至5.8%】
美國5月份新增就業崗位55.9萬個，失業率降至5.8%。這些數據表明，美國勞動力市場正從疫情影響中復甦，同時有跡象表明企業難以為空缺崗位招到足夠人手。
https://tinyurl.com/y59qvkq7

【WWDC後IDFA已死?? 對廣告買量生態的影響是什麼?】

早上看了一些資料，整理了蘋果WWDC發布未來iOS14，對於IDFA幾乎禁用的可能影響：

首先說明一下IDFA：

※IDFA 能讓開發人員和行銷人員出於廣告目的追蹤使用者活動。 廣告客戶可使用廣告識別碼放送再行銷廣告活動，並記錄購買或下載轉換次數。

而在iOS14推出後，只要用戶下載App，就會跳出一個視窗，翻成中文大概是這樣：

『飛鳥涼不涼想要權限去追蹤你在其他App或網站的行為，你的資料將被用來投放客製化廣告。』

由於這是一個用戶"拒絕"也不會有任何損失的選項，所以許多新聞媒體認為這代表了「IDFA」已死。在iOS 13以前，用戶必須自己去系統中關閉這個選項，現在則是每下載一個App就會跳出來問你一次。

----

所以可能的影響是什麼?

●用戶單獨關閉IDFA，就無法排除掉老用戶。也就是說同樣的廣告可能一直接觸到相同用戶而造成成本不斷飆升。影響最大的應該是iOS的誘因式廣告模式(譬如以前下載遊戲送LINE Point)，因為無法排重，相同的用戶可以不斷重複領取獎勵。

●有些應用可能會預設要求用戶開放IDFA才能安裝，但這就看各別APP的誘因與吸引力了。

●Google/Facebook的廣告影響大嗎? 我認為應該不大。因為這兩大平台應該有其他無數的方式幫用戶設立標籤、使用演算法去排除掉禁用IDFA的用戶重複接觸廣告。

尤其像Facebook這種擁有強大帳戶體系的大平台，影響應該更小。從FB的開發者文件中可看到，FB支持三種移動廣告ID，IDFA、Adroid廣告ID，以及FB用戶ID。

『如果人們通過Facebook登錄到您的應用，則可以使用其Facebook用戶ID進行定位。』(https://developers.facebook.com/docs/app-ads/targeting/mobile-advertiser-ids?locale=zh_TW)

這也是為什麼，很多遊戲目前還是只提供FB作為唯一第三方帳戶。理論上來說，這可以讓用戶資料運用與廣告投放達到最大效益。而在未來，也許iOS14的推出反而會讓更多開發者仰賴FB的帳戶體系也說不定。

●即使Google/Facebook有自己的追蹤方式，但畢竟不是跨平台的。對遊戲買量來說，在iOS上集中投放單一廣告平台能避免重複購買所帶來的浪費。在Google廣告原本在iOS體系中的廣告效益就不如臉書的情況下，可以預期FB可能是最大的受益者。

喔對，當然還有Apple Search Ads。

●對第三方數據追蹤工具如Appsflyer的影響：造成小型廣告聯播網加速退出iOS市場。Appsflyer其SDK也是利用IDFA進行追蹤。所以如果用戶拒絕提供IDFA，而又沒有像Faceook這樣的帳號統治力，那在第三方數據平台上的呈現將會被歸類為自然流量。以Appsflyer的說法，歸因平台雖然還是有許多方式來抓取臨時參數，但會造成約1.5%的歸因失敗變為自然流量。

簡單來說，如果iOS所有用戶都禁用IDFA，則將會增加15%的自然流量，這樣是不用付給廣告代理商或代操公司的，因為它們都是以第三方數據追蹤工具後台來計價。

中小型廣告聯播網、媒體代操公司將會面臨更大的生存問題。

--

總結：世界不會有太大改變，有資源的公司依舊強勢，弱小的廠商加速凋零。

PS.以上歡迎大家提供不同看法，多多補足不同見解~感謝!

#No168
#準備回南部過爆熱端午節˙