#木的放映室 #文末抽書
‼️本活動ig抽一本、臉書抽一本‼️

#木的手拉手合作
📣《在診療室遇見老子》
出版社：今周刊
作者：野村總一郎 精神科醫師
譯者：郭子菱

📍書籍摘要
在生活中總有許多奇奇怪怪、不勝枚舉的shit事影響著我們，而在這個過程中我們也因而變得糾結、掙扎，甚至感到「活著一點也不輕鬆啊」，就像是在勉強支撐著自己一樣。你也是這樣嗎？

🔻認為自己很弱
🔻認為自己總是在吃虧、別人都對自己不好
🔻認為自己必須完美無缺、但卻總是得不到想要的
🔻堅持必須要按照自己的步調，但事與願違

相信大家從小到大都讀過「老子」，對小編來印象最深刻的部分就是老子的「無為」。

✨無為，是順其自然

你有曾經沒有任何動力的時刻嗎？而當能量很低、沒有任何動力做事情的時候，是否也讓你更為焦慮？覺得「我必須應該要動起來、必須應該要做些什麼」？

但在這種時刻，著急、焦慮、緊張似乎也無用，我們也只能夠等著能量儲存完畢，才有動力好好完成想完成的事情。而老子的概念則是當我們面對這樣的時刻時，放肆的「什麼都不做」吧！躺著也好、坐著也好、耍廢更好，聆聽自己的聲音，順其自然。

✨任何事物都是相對的

在跟別人比較的過程中，誰功成名就、成績很好、長得漂亮、受人賞識，這些都是因為「比較」而得出的結論與地位高低，但我們在這樣的比較中，常常失去了自己、忘了本身自我的價值，而一味的羨慕他人所擁有的。因為我們對自身帶有評價，也因此總感覺自己擁有的是「不夠好的」。

任何的價值都會因為環境、周圍的人而改變，價值的定義一直都是相對的、暫時的，能夠保持現狀、維持自我的狀態從容存在著，對自我的狀態不因外界而貶低自己，是一種帥氣。

📍觀後感
過去木的曾經談過毒性正能量，一開始收到這本書，也曾想過會不會是一本空泛的心靈雞湯，過度的正向與轉念是否會讓人收不下來。但是在閱讀的過程中，著實地療癒到了近期對生活感到厭世的小編，書中的概念，非常符合小編現在就是想要「躺著與廢著不動」好好休養生息的狀態(笑)。

當我們過度努力、想為自己的工作與生活拚搏出一個輸贏，不自覺地越來越容易比較，覺得努力沒有成果、再怎麼用力都達不到自己想要的樣子、別人有的總是比我好，這些念頭會壓垮自己，而當我們已經感到很痛苦，卻仍不放過自己的想持續前進。

這本書提醒我們，無論發生什麼好事壞事，永遠不要忘記「自己」，聆聽自己的聲音、減少評價自己、當我們持續盯著羨慕的人的時候，也別忘了花些時間看看自己，因為光是存在與做著自己能做的事情，就已經很好了(意思是你躺著站著坐著都可以)；不用一定要活得發光發熱，而是活得像自己就好。

📍木的推推理由
1️⃣如果你近期也對人生感到厭世、對工作無力、對生活感到失去控制，很推薦你閱讀這本書，一起試著學習「無為」，這本書會非常打動你。
2️⃣對自我要求很高、完美主義、每件事情都希望計畫滿分(跟小編一樣)的人，我們一起來透過閱讀這本書，練習放下與休息。

「再滂沱的雨勢，也終會停歇」

#木的抽書
（本活動IG抽一本、臉書抽一本）
1️⃣追蹤木的IG/木的臉書粉絲專頁
2️⃣Tag兩位好友，並寫下本文中哪個概念最打動你
3️⃣「分享」此篇文章於限時動態/臉書動態時報，並tag @moodradio_
4️⃣若有中獎，請務必主動聯繫我們，並提供分享頁面之截圖
(上述步驟務必都完成，才算是有抽獎資格唷)
‼️重複留言不予計算‼️

🌟9/17 12:00截止，並於9/17 22:00前於IG限時動態/臉書貼文留言處公佈得獎名單。

#今周刊 #在診療室遇見老子 #無為 #老子 #零批判 #順其自然 #做自己 #哪裡跌倒哪裡躺 #覺察 #意識 #生活 #努力 #自我成長 #心靈成長 #心理諮商 #台北諮商 #新北諮商 #郭玟秀諮商心理師 #黃旻諮商心理師 #圖文插畫家麗莎

三不五時都會聽到或看到，有人認為我的著作，沒有「別人的故事」「沒有案例分析」「沒有個案探討」，不算是有價值的書，也不值那書本價錢。

這類的評論或讀書分享，我知道很久了，也尊重，但我沒有想改變我自己的寫作「價值觀」和「風格」。

我可能會從善如流的接納出版社建議我寫些故事，讓讀者進入故事來投射感受和反應，也更確切地知覺到自己的課題、議題，所以我會編寫不同類型的故事，但還是會以「編寫」為主，不會直接的陳述或呈現我在進行個案諮商的過程，或之間的對話。

或許有人會認為這樣我不算一位專業人士，沒有向讀者交代我怎麼協助個案療癒及進行修復。但我認為我不需要去向人證明什麼，我寫作也不是要向人證明我很會療癒，或我很有本事。

你認為我有本事也罷，認為我沒本事也罷，認為我寫作沒個案故事不精彩也罷，都沒有關係，這些都是會有的反應，畢竟任何事物都會有每個人不同的感覺和意見。

但是我還是想說，我寫作的用意，是我想透過書本和每個閱讀者直接對話，像是在陪伴讀者回看自己的人生，探討自己心理內在的環境是如何養成，以及可以如何重整和慢慢滋養自己。若能因此覺知自己，有不同觀點去了解內在的自己，進而來得及為自己療傷止痛行動，那就太好了。

我一直不擅於也不傾向和別人一起去往別處看，一直在看別人的事情、一直分析別人。我也不傾向把別人的生命歷程，那些錯綜複雜的情況和脈絡，那些生命的不容易和不簡單，簡化成某些條例和摘要，用幾頁就講完。

而最重要的是，屬於每個人的生命經歷，若是可以，能由自己敘說是最好的。你才是你生命的專家。

就連我和朋友談話，我們也都在談彼此之間的感受和想法，很少花時間和力氣去談論別人，及分析檢討別人的人生。

這是我人生哲理的傾向，當然不代表是每個人的人生哲理。

所以，若希望我寫出個案故事及問題，再像病理摘要及分析的呈現，讓人了解如何剖析、如何去解決這樣類型的問題，我知道這樣的書籍很多，教科書也都有，有需要或興趣的人，其實不怕找不到。

但若要看「蘇絢慧」寫這樣的書，這不只不在我的寫作計畫裡，更是我不會進行的事。

我始終相信「凡事都可行，但不都有益處」，人生有限，我只能選擇我自己覺得想做且有益處的事情去做。

即使大家都這麼做了，也不意謂著我需要那麼做，我只需要做我的存在能做的即可，至於其它的事，自然也有其他人會做。

我認為，不需要要把每個人都弄成一個樣，或好像要呈現出某種被認定的標準，覺得因為別人都怎樣，你也應該怎樣⋯

如果，你喜歡我的寫作風格和目的，那麼我真心謝謝你，回應了我想做的。若無法，那也是事實，我們兩方的頻率、過去的養成、價值觀思維，尚無法有連結和相通的緣份，這也是要接納的。

但我相信，我的存在還是有我的價值。

你的需要，在這世界上還是有可以回應你的地方。

即使是作者和讀者的關係，相信在短暫交會之後，我們都還是有各自要成長的路程，也能夠有各自的良緣善緣，讓我們各自安好。

若我的書能在你的人生路途中，成為一點支持和鼓勵，或是一些滋養或啟發，這已是我覺得之所以寫作最美好的事。

至於覺得是否閱讀我的書是浪費人生時間，或是浪費錢，也都沒有關係，還是謝謝你願意為這一本書停下來，給我們本來陌生的兩個人，一次接觸的機會。

謝謝。

#但真心建議，若想看個案分析類的書，請放棄考慮我

#我只能寫我想寫的書

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 其實也會帶出不少管理上的問題，反而並沒有減輕本來的負擔