關於 prometheus, grafana docker ，我們在網路上蒐集到這些相關的討論、資訊與評價

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

NT590 特價中

Kubernetes(也被稱為”K8S”)是目前最熱門的話題之一，職場需要許多擁有 K8S 技能的工程師。

透過本課程獲得這些技能！ 這是一個非常好的機會去做一個真正的 K8S 專案，讓自己在真正的專案上達到高專業的水準。

在整個課程中，你將就真實的需求工作 – 但你不需要已懂如何寫程式或懂任何特定的程式語言 – 課程已經為你準備了一套 Docker images，你的工作是使用 Kubernetes 讓這些 images 執行。

該系統是一個基於微服務( Microservice )的架構，在這個課程中，我們將研究在管理這些複雜系統時需要做出的設計決策和權衡。 請注意，本課程不是關於如何設計微服務(儘管我們肯定會討論這一點) ; 開發工作已經完成，我們需要讓系統在營運叢集( production cluster )上執行。

經由分析叢集的執行時期效能( run time performance )，我們還將發現開發人員在程式碼中犯了一些糟糕的錯誤！

你可以在你的本地開發電腦(PC/Mac/筆記本電腦)上完成課程的第一部分。 第二部分(從第 13 章開始)將移到雲端。 你將使用一個真正的 AWS 帳戶，我們將繼續使用 ELK/Elastic Stack 設立監控，並使用 Prometheus 和 Grafana 進行監管。

我為各種不同的人設計這門課程——無論你是 DevOps 工程師，還是開發人員，或者你對整個領域還很陌生，我都會一路解釋。 只需要一些使用電腦的基本知識，或許一點命令行經驗就足夠了。

在 13 – 17 章，你將需要一個 AWS 帳戶，如果你想自己在系統上實驗的話。 如果你是 AWS 的新手，請不用擔心，課程講師將一路罩你——但是亞馬遜會在你運用系統時跟你收費(就像所有 /大多數雲端供應商一樣)。 預估為此支付不超過10美元(這是一個安全的高估) ，但是你需要自己管理這個花費，並且必須在會話( session )結束時刪除你的 Kubernetes 叢集。 不要因此而放棄，這是很好的投資。

https://softnshare.com/kubernetes-microservices/

#NetDevOps

今天這篇文章是一個數據調查文，主要內容是探討基於 NetDevOps 的文化下，網路維運人員使用哪些工具來協助日常的網路工作。

這份 2020 的報告總共有 333 的投票者，總共有一個月的投票時間。
整個文章總共有 49 個表格，非常的多...
這邊就列舉幾個大家可能比較有興趣的表格來幫大家預覽，當然對於整體有興趣的人還是不要忘了點選全文瀏覽！

每個項目都列舉前六名，標準基於使用正式於生產環境的票數
感興趣或是已經使用的工具
1. Ansible
2. Grafana
3. Netbox
4. ELK
5. EVE-NG
6. Promethes

感興趣或是已經整合的主題
1. Source of Truth
2. Network Health Moniroting
3. IaC
4. DevOps
5. CI
6. CI/CD

使用何種解決方案來自動化處理設定檔案
1. Ansible
2. 內部開發工具
3. NAPALM
4. Nomir
5. Terraform
6. 網路供應商的自主工具

如何控管設定檔案的改變
1. VCS
2. Rancid/Oxidized
3. 內部開發工具
4. 網路供應商的自主工具
5. FTP/SCP/TFTP
6. Solarwind NCM

管理哪些網路廠商的設備
1. Cisco IOS/IOS XE/Viptela
2. Cisco NX-OS/ACI
3. Juniper
4. Cisco IOS XR
5. Cisco ASA
6. Palo Alto

使用何種工具來模擬虛擬網路設備或是功能驗證
1. GNS3
2. VMWare
3. EVE-NG
4. 網路供應商工具
5. Docker Compose
6. Vagrant

網通業者的生態與軟體業者是截然不同的，很多軟體業習慣的操作流程與直覺並不是這容易的直接套用到網通業者的環境中。
舉例來說，使用公有雲創建 VM 並且於 VM 叢集上搭建出一個初始的工作流程並不難，Kubernetes 套上去後，就可以用容器的方式把各種應用，譬如 Prometheus, Grafana, logging, tracing, message queue 等服務都搭建到各個伺服器上。
對於網通業者來說，今天掌管的目標是 Switch 跟少部分的 Server，光 Switch 要買哪一家就是一個問題。
Switch 不太像 X86 架構一樣，想換什麼 OS 就換什麼 OS 這麼輕鬆，不走 whitebox 的架構下，一旦採購了某家廠商的解決方案，有可能就終生是對方的形狀了。這也是很多人都在提倡希望透過標準化來避免 vendor lock-in 的狀況。
上述的報告也可以看到前六名管理的機器中有四名都來自 Cisco 的機器，這種情況下很多事情都會受限於 Cisco 機器本身的設定與狀況，並不是想要做什麼就做什麼。

為了讓這一切變得簡單，如果可以透過標準化的方式去定義 switch 的架構，讓這一切變得如操作 Server 般簡單時，網通業者就會有另外一種方法來管理環境。
如果相關的軟體都有開源專案可以使用，這樣維運人員就可以用更省錢的方式來安裝與控管這一切的網通設備，聽起來真的很棒
現實生活上則是，網路產業對於 uptime 的需求非常的強，一旦出問題不是單純服務不能連，而是可能影響數千數萬甚至更多的使用者。這種情況下如果團隊全部使用開源專案而沒有 SI 公司的支援與維護，誰敢冒這個險去使用這些呢

最後要說的是，隔行如隔山，永遠不要用自己習慣的工作流程去看待別的產業，很容易被打臉。

https://dgarros.github.io/netdevops-survey/reports/2020