關於 ci cd定義 ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://iximiuz.com/en/posts/devops-sre-and-platform-engineering/

本篇是一個由 Twitter 討論串引發的後續文章，作者想要聊聊 DevOps, SRE 以及 Platform Engineering 的差異。
文章中附有相關 Twitter 討論串的連結，對於原文有興趣的也可以去參閱一下 Twitter

註:就我個人觀察到的現象，台灣企業很少看到 Platform Engineer 的職位，有人知道有哪些公司有開這種職位可以留言分享一下

作者自述自己是個從事 SRE 工作但是內心卻是個軟體工程的技術專欄作家，因此就自己的過往經驗想分享一下對於這三者的看法，而這些討論就引起了一些回文
因此作者將這些概念整合下來寫下這篇文章來總結一下各方網友們的看法。

作者的軟體生涯中，從分工仔細的團隊到新創公司都經歷過，再還沒有認知到 DevOps/SRE 這類型名詞前就已經體驗過部署開發維運三合一的人生。

隨者愈來愈多人開始探討 DevOps 以及 SRE 這兩個詞，兩者之間的比較沒有停過，甚至還有專屬的兩個 awesome 系列 awesome-sre, awesome-devops 清單來列舉如何學習這兩個技術。
整個求職市場也因為這兩個名詞的出現而有變化，作者也因應這股潮流開始往下探索，因此最後就以自己自身的經驗來分享自己對於這些名詞的想法。

其中作者有提到一點也是我非常認同的，就是這些名詞代表什麼含義，這些職稱要做什麼都會隨者不同公司不同團隊而有變化，畢竟每個公司的產品跟商業走向都不同
期待能有一個一統天下的職稱跟工作內容反而才是不切實際的。所以接下來的探討就只是作者跟幾個網友們的討論，不要當作圭臬，也不要當作聖旨，自己有自己的想法比較重要。

# What is Development
1. 作者認為開發的概念非常簡單，就撰寫程式，唯一能夠為公司貢獻 $$$ 的職位，畢竟有人寫程式還有產品，沒人寫程式也沒什麼好部署的。
2. 推特網友表示: 只有 sales 才是幫公司賺錢的，剩下都是公司的支出
3. 作者從 2011 開始了軟體工程師生涯，過往作者都很期望自己可以去部署一下自己撰寫的程式，但是基本上都是團隊內的其他神秘人物會默默的部署這些程式到生產環境。

# What is DevOps
1. 作者不想探討何謂官方的正式定義，只想聊聊自己多年工作經驗的感想
2. 對作者來說， DevOps 是一個能夠讓開發者對於部署應用程式有更多機會與權力的文化，實作上沒有一定的準則
3. 作者還待過那些開發者都擁有 sudo 權限來部署應用的新創公司，不過現在這些流程都慢慢的被自動化 CI/CD 流程給取代。
4. DevOps 最初的想法應該是遠遠超過作者所描述的，不過作者就自己工作上的經驗，找工作的經驗，看職稱 JD 的經驗來看，DevOps 更像讓開發者打造的產物可以更有效率的被部署
5. DevOps 本身不應該去探討產品的商業邏輯，那是開發者要探討的。

# What is SRE
1. Google 推出了一系列的書來探討何謂 SRE，那系列書籍的想法偏向 SRE 是其中一種 DevOps 文化的實作方式。
2. 相對於 DevOps，作者更喜歡 SRE 帶來的職缺內容。
3. 作者對於提到 CI/CD pipeline 之類的職缺都感到無聊且沒興趣，而 DevOps 的工作職缺往往都充滿這些令人無聊的東西。
4. 相反的，作者更喜歡去專研系統問題，譬如探討為什麼會有 bug, memory leak, 效能不好...等
5. 作者認為 SRE 要負責去維護上線環境，確保使用上沒有問題。
6. Google 的 SRE 系列書籍還提到了關於 monitoring, alerting, SLO 等各種如何確保服務正常的機制。 Facebook 則是有非常著名的 Production Engineer 的職稱，其跟典型的 SRE 基本上沒太大的差別。
7. 推特網友表示: SRE 專注於生產環境, DevOps 專注於 CI/CD 與開發效率與流程
8. 另外一名推特網友表示(這也是我目前最喜歡的答案): DevOps 從開發角度為起點， SRE 從維護上線環境出發，兩職缺於某處產生交集。

# What is Platform Engineering
1. 作者想起當年還是一家新創的唯一一位工程師時，那時候還要去租借實體機器來架設環境，所以那時候也撰寫了不少腳本來安裝機器，也要確保機器之間的網路可以正常運作。
2. 加入一間比較有規模的公司後瞭解到看來 infra 相關的工作是一個很類似 SRE/DevOps 但是又有些許不同的領域
3. 作者認為 Platform Engineering 目標就是要打造一個可以讓 Dev, Ops, SRE 能夠使用的環境
4. 作者感覺 Platform Engineering 要負責維護 data-center 內上千台的機器，確保這群機器能夠正常運作，維護外也要包含升級，設定等。

# What's about titles?
1. 作者前述探討的都是基於負責領域，比較不去談這些職稱應該要做什麼
2. 根據作者經驗，當公司規模逐漸變大時，分工就會愈來愈細，這時候 Dev, Ops, SRE, PE 等職缺就會開始逐漸專項化。
3. 重點就是， YMMV (Your Mileage May Vary )，不同情況，不同答案，不要太專注於一個死板板的解釋。

個人想法: 公司要開什麼職缺名稱就不管他了，工作內容才是最重要的，有錢的任性老闆也可以開一個"開源軟體整合工程師"但是要你整合 CI/CD 加上維運的工作。

ref: https://faun.pub/the-best-infrastructure-as-code-tools-for-2021-b37c323e89f0

這篇文章是一個 IaC (Infrastructure as Code) 的推廣文，文章分成幾個部分，從 IaC 的基本概念與應用談起，接者分析了幾個常見的 IaC 工具，最後探討了實際的使用案例

文章偏長，對於 IaC 概念很熟悉的讀者應該可以很快速地看完，以下針對部分進行一些摘要

The need for Infrastructure as Code
作者先描述過去幫機房部署新伺服器時的各種流程，機器少量時能夠透過人力慢慢處理，但是這類型的操作繁瑣，重複且惱人
為了讓這些流程處理得更佳順遂與一致，會有各式各樣的 scripts 等相關工具被開發出來，而這些流程慢慢的會往自動化的方式去發展。
IaC 文化的興起會使得有愈來愈多獲得共識的工具被開發出來，這使得 IaC 的使用門檻會有機會降低，愈來愈多的使用者能夠更簡易的透過 IaC 的方式來管理與維護自身的架構

Benefits and reasons to implement IaC
IaC 帶來的好處是非常顯著的，譬如
1. 將 Config 檔案當作整個環境的 sing source of truth
2. 每次的部署都是基於上述的 Config 來部署，能夠確保每次部署都獲得一樣的結果，避免人為的反覆長期操作帶來的錯誤
3. 透過程式化的方式去建置環境能夠更快速的去應變各種環境需求，對於 testing, developing, production 等各種變化都可以透過 config 的差異來快速搭建
4. Config 也可以透過 Git 的方式去管理來獲得更好的可稽核性與管理性。

Principles and best practices of Infrastructure as code
作者這邊列出了幾個實作上的推薦方式
1. 透過版本控制的方式來管理 IaC 的設定檔案，能夠讓維運人員使用開發者常見的開發合作流程來管理 IaC
2. 將 IaC 的工具整合到 pipeline 的 CI/CD 流程，讓 CI 流程去檢查 IaC 的設定是否符合預期以及 CD 流程來幫忙自動部署修改架構

Infrastructure as code tools
這個區塊作者列出了幾個常見的工具，包含 Terraform, CloudFormation, Puppet, Pulumi 等，接者又透過一張大表格來比較 Terraform/Pulumi/CloudFormation 三者的差異
Pulumi 這工具這一兩年開始聲勢比較多，跟 Terraform 一個最大的差異我想就是撰寫的方式，可以透過 Js, Go, Python...等程式語言來描述架構而並非使用 Terraform 自定義的 DSL 來管理。

最後面作者也列舉了六七個適合 IaC 的使用場景，有興趣的歡迎閱讀全文

Cloud Native 這個詞近年來非常熱門，CNCF 甚至也有針對這個詞給出了一個簡短的定義，然而對於每個使用者來說，要如何實踐這個定義則是百家爭鳴。我認為很認真地去探討到底什麼樣才算 Cloud Native 其實就跟很認真的探討什麼是 DevOps 一樣，就是一個沒有共識，沒有標準答案的問題。

本篇文章從 CNCF 的定義衍伸出 Cloud Native 帶來的優勢，並且針對這個領域介紹了十三種不同面向的科技樹，每個科技樹也都介紹了幾個常見的解決方案。

好處:
1. Speed
作者認為 Cloud Native 的應用程式要具有快速部署與快速開發的特性，擁有這些特性才有辦法更快地去根據市場需求而上線面對。眾多的雲端廠商都提供不同的解決方案讓部署應用程式愈來愈簡單，而 Cloud Native 相關的工具則是大量採用抽象化的方式去描述這類型的應用程式，讓需求可能更簡單與通用的部署到不同環境中。
2. Scalability and Availability
Cloud Native 的應用程式應該要可以無痛擴張來對面不論是面對一百個或是一百萬個客戶。底層所使用的資源應該都要根據當前的需求來動態配置，避免無謂的金錢成本浪費。此外自動化的 Failover 或是不同類型的部署策略(藍綠/金絲雀..等)也都可以整合到 Cloud native 的工具中。
3. Quality
Cloud Native 的應用程式建置時應該要保持不變性，這特性使得應用程式本身能夠提供良好的品質一致性。此外大部分的 Cloud Native 工具都是開放原始碼專案，這意味者使用時比較不會遇到 vendor lock-ins 的問題。

以下是作者列出來認為 Cloud Native 生態系中不可或缺的十三種面向，以及該面向中幾個知名專案。

相關領域
1. Microservices (Node.js/Kotlin,Golang)
2. CI/CD (Gitlab CICD/ Github Actions)
3. Container (Docker/Podmna/LXD)
4. Container Orchestration (Kubernetes/Google Cloud Run)
5. Infrasturcutre as Code (Terraform/Pulumi)
6. Secrets (Vault /Sealed Secrets)
7. Certificates (cert-manager/Google managerd certificates)
8. API Gateway (Ambassador/Kong)
9. Logging (EKF/Loki)
10. Monitoring (Prometheus/Grafana/Datadog)
11. Alerting (Prometheus Alertmanager/Grafana Alerts)
12. Tracing (Jaeger/Zipkin)
13. Service Mesh (Istio/Consul)

https://medium.com/quick-code/how-to-become-cloud-native-and-13-tools-to-get-you-there-861bcebb22bb