CNCF 雲原生容器生態系統概要

公有雲

公有雲國外以亞馬遜 AWS、微軟 Azure、谷歌 GCP、DigitalOcean 為代表，國內有阿裡雲、騰訊雲、華為雲，此外 IBM、Oracle、Fujitsu 都有自己的雲產品，Joyent 也是國外很有名的雲端計算公司；Packet 是物理機雲服務商，直接為使用者提供物理機資源。

私有雲

私有雲是指使用者在自己的資料中心搭建的雲服務，除了自己研發之外，常見搭建私有雲的方法有 VMware（商業化的虛擬化軟體） 和 OpenStack（Python 編寫的開源 IaaS 平臺軟體）；此外 MaaS 提供物理機自動安裝和管理服務，分為免費版和收費版；Foreman 是虛擬機器和物理機的系統配置工具。

建設私有雲的成本很高，但是當公司成長到一定規模的時候，私有雲建設也是必要的一件事。除了能縮減成本，也能提高技術實力，而且也有更多的靈活性滿足內部的各種需求。

Host Management / Tooling

自動化配置工具，保證容器執行的系統配置的一致性，並提供升級、補丁等功能，一般也可以用來 Bootstrap 容器服務。

這裡的幾家軟體功能大同小異：

這篇部落格[2]和這篇文章[3]比較了 CFEngine vs Puppet vs Chef vs Ansible vs Salt 這幾個工具的異同，如果糾結如何選型，推薦閱讀。

其實，對於大多數需求，根據開發語言、配置檔案風格等選擇其中一種就行。

Infrastructure Automation

IaaS 平臺提供了基礎設施服務，但是對於複雜的場景來說，直接使用這些服務提供的介面還是會很麻煩，所以有了基礎設施自動化。這部分做的事情就是能夠讓基礎設施的配置自動化，一次完成多個資源的部署，提高效率。

總的來說，這些工具就是在雲平臺或者 Kubernetes 平臺上再封裝一層，讓使用者能夠透過一次定義，在不同平臺部署多個資源或者服務，並做到版本升級和跟蹤。如果雲平臺提供相關服務（比如 AWS 的 CloudFormation）直接使用即可，如果是混合雲，則需要選擇 Juju、Terraform 這樣的管理工具。

Container Registries

容器的映象 Registry 是容器平臺的基礎需求，畢竟所有的容器應用就是透過映象來定義的，映象服務分為自建和公有服務兩種。

很多公司提供了它們公開的容器 Registr 服務，比如 Docker 官方的 Registry，亞馬遜 ECR（Elastic Container Registry）、Azure 和 Google 雲 Registry、此外 Quay、Project Atomic、JFrog Artifactory 也是比較著名的容器映象服務提供商。

Harbor 是開源的企業級容器映象管理平臺，Portus 專門為 Docker Registry 提供授權服務。

國內一般企業會選擇自建 Registry，因為國外的 Registry 訪問速度都很慢，而國內並沒有非常流行的 Registry 服務（當然很多容器服務公司都會提供 Registry 服務），另一方面自建 Registry 的技術並不複雜。

Secure Images

隨著映象和容器標準化的完善，映象和容器的安全也越來越受到企業的關註。雖然在大多數情況下，安全往往是軟體開發者最後才關心的事情，但是容器安全卻是不容忽視的一個環節。

Notary 和 TUF（the update framework） 是 CNCF 旗下的兩個專案，TUF 是開源的安全和驗證標準，Notary 是它的一個實現，Notary 可以用來驗證映象的安全性，也可以用來安全地釋出軟體包。

Key Management

和安全相關的另一個問題是機密資訊，包括密碼資料、金鑰等。

Keywhiz、Pinterest 開源的 Knox、Lyft 開源的密碼儲存工具 Confidant 和 HashiCorp 開源的 Vault 想要解決機密資訊的儲存，它們透過加密的方式把內容儲存到後端儲存中，而且提供了 Auditing 等額外功能。

SPIFFE 和 SPIRE 是一對的，SPIFFE 定義了服務的認證標準和認證資訊的標準，SPIRE 是它的一個實現，但是目前還沒有達到生產可用。

容器執行時這塊是容器核心的技術，關註的是主機容器的技術模組，分為計算、儲存、網路三塊。

Container Runtime（容器執行時）

我們知道，整個容器技術就是因為 Docker 的出現才變得炙手可熱，可以說 Docker 重新定義了容器，也成為了容器技術的代名詞。但是隨著容器的標準化，Docker 把核心元件抽象出 containerd，作為容器執行時，而更多公司也推出自己的容器實現，容器一詞的含義開始擴充套件，而且也逐漸標準化了。

隨著容器執行時的穩定，普通使用者對其關註會逐漸下降。如果把執行時比作核心，那麼容器排程系統就是作業系統，開發者應該更關心作業系統的功能和效能，只有遇到特殊需求或者問題時才會關註核心。

OCI（Open Container Initiative）是一個促進容器標準化的組織，主要工作是容器 Runtime 和映象的標準化協議，這部分內容可以參考我之前的介紹文章[4]。

CRI-O 是 Kubernetes 推出的東西，它是 kubelet 和 OCI Runtime 之間的橋梁，它內部採用 OCI 標準，因此可以相容各種 Runtime（比如 runC、Clear Container等），對上它提供 CRI 介面供 kubelet 呼叫。這樣的話，CRI-O 的存在能夠讓 kubelet 使用任何 OCI 相容的 Runtime，從而繞過 Docker、Rkt 這種完整容器管理工具。

Cloud Native Storage（雲原生儲存）

容器從一齣現就非常契合微服務中無狀態服務的設計理念，因此初期甚至給了一些人容器只適合無狀態服務的印象，但是隨著容器技術的成熟和使用者理念的變化，容器目前已經全面進入有狀態服務領域。因為容器存活時間很短的特點，容器的狀態（儲存的資料）必須獨立於容器的生命週期，也因為此，容器的儲存變得非常重要，雲原生儲存這塊介紹了很多相關的技術。

作為 IT 領域的核心技術，儲存早在容器火起來之前就已經有發展了很多年，從單機的各種檔案系統、到網路儲存，再到現在比較熱門的分散式儲存、以及雲端計算催生的塊儲存、檔案儲存、物件儲存，不同需求不同分類的儲存早就五花八門了：

除了這些開源的儲存技術之外，還有很多容器儲存圈的技術公司：

因為不同使用者對儲存需求不同，採取的儲存方案也不同，不管是開源方案、商業方案還是自研方案，或者是檔案儲存、物件儲存還是塊儲存，怎麼把這些技術用到容器平臺，以及保證標準化和統一化的介面，是非常有挑戰性的事情，目前也有很多努力：

Cloud Native Network

網路最重要的功能是提供不同計算資源的連通，隨著虛擬化和容器技術的發展，傳統的網路方案已經無法滿足雲端計算快速增長、不斷變化的網路需求。不同使用者對網路的要求也越來越高：

因此，在雲端計算和容器這塊湧現出很多網路解決方案和廠商，試圖解決這些問題：

也有很多的商業公司為企業提供網路解決方案：

Scheduling & Orchestration

排程和叢集管理一直是容器技術的熱點領域，競爭也非常激烈。打個可能不那麼恰當的比喻，如果把容器 Runtime 比作引擎，那麼容器叢集管理工具就是汽車。使用者購買的是汽車，儘管引擎非常重要，但是它終歸只是個可以替換的零件。

叢集管理競爭還在，並沒有最終的唯一勝利者，但總的來說 Google 公司的 Kubernetes 處於絕對的領先狀態，也是目前社群發展最快的平臺，隨著 Docker 官方支援 Kubernetes，以及 Azure 和 AWS 。目前社群三個主流的容器排程平臺是：

對於公有雲上的容器服務，各大雲服務商也有對應的產品：

Coordination & Service Discovery

有了容器叢集管理工具，容器的規模逐漸變多，另外一個需要解決的問題是服務之間怎麼互相發現對方。因為叢集的容器是不斷變化的，IP 地址也是不穩定的。這個問題再往下思考，就是叢集的狀態應該怎麼儲存，才能讓所有節點能當前叢集自己想要的資訊，而且保證不會發生衝突和錯誤。

目前，叢集的狀態都會儲存在一個分散式的鍵值儲存裡，這個儲存保證資料的一致性，目前三款常用的鍵值儲存工具是：

有了分散式鍵值儲存保證一致性，還需要工具把叢集資料自動寫入到裡面，並且需要格式化地讀取和解析資料。圍繞這一話題，周邊也有很多工具：

除外，還有兩個公司開源的服務發現工具要提一下：

總的來說，這些工具保證這個叢集的動態資訊能統一儲存，並保證一致性，這樣每個節點和容器就能正確地獲取到叢集當前的資訊。

Service Management

伴隨著容器技術而變得火熱的一個話題是微服務，每個服務作為容器或者 Pod 執行，不同服務之間透過服務發現知道對方的地址進行通訊。隨著叢集規模的增大、服務數量的增多，使用者的需求也不斷增加，微服務架構也面臨更多的問題：

這些東西都是每個微服務平臺必須要考慮的，如果放在每個服務程式碼中實現某些功能，不僅增加了每個服務的複雜性，也會導致重覆的工作，所以，微服務需要更好的框架和平臺統一提供這些功能。總的來說，微服務雖然降低了單個服務的複雜性，但是把複雜性下沉到微服務管理平臺層面。

針對這些問題，有很多軟體和方案。對於負載均衡來說，HAProxy、Nginx 和 F5 都是常用的方案，Traefik 是後起之秀，專門為微服務設計；RPC 框架用來在微服務內部進行通訊，因為比 HTTP API 效率高而被大量使用，常用的用 Google 開源的 GRPC 、Apache 旗下的 Thrift 框架、Netflix 開源的自帶負載均衡的 Ribbon 和 Avra 資料序列化框架。

微服務 Gateway 是統一化管理 API 註冊接入、許可權認證、限速、日誌等功能，是微服務對外的介面。

這個領域也有一些公司在提供產品，比如 Datawire 就專門為 Kubernetes 應用提供 API Gateway 和自動化原始碼部署的工具。

微服務開發框架 Hystrix 是 Netflix 開源的專案，能夠幫助程式處理微服務互動的超時處理和容錯的問題，提供熔斷、隔離、降級等功能，但是隻能用於 Java 語言專案，需要在程式中修改程式碼。

特別要強調一下微服務領域最近比較熱門的概念：Service Mesh，它的主要想法是把微服務通用的功能單獨抽象為一層，部署在容器管理平臺中，對應用透明，並且透過簡單自動化的介面來控制整個微服務的連通、灰度訪問、升級、降級等功能。

Service Mesh 相較於之前微服務框架的最大優勢是它對業務是透明的，不需要像 Netflix 提供的很多微服務工具那樣對應用有侵入性，因此就不再和任何語言系結，可以看做整個網路棧的另一個抽象層。

PaaS/Container Service

因為容器技術的隔離性，以及對應用非常友好，因此可以直接拿來做 PaaS 服務，當然也有種叫法是 CaaS（Container as a service）。很多初創公司的業務也就是這塊，基於容器提供應用的釋出、升級、運維等管理工作。大部分公司做的事情都大同小異，因為最終的需求是一樣的：讓應用的開發、部署、擴充套件、升級、運維更輕鬆，使用者無需關心基礎架構，只需要考慮如何去實現業務邏輯就行，主要的區別在於側重點，有些側重私有的資料中心部署和管理，有的側重 Docker 容器的管理，有的測試 Kubernetes 等容器叢集的維護，有的提供應用平臺，有的和公有雲平臺深度整合……

Heroku 是老牌的公有雲型別的 PaaS 平臺，介面友好，成熟穩定，所有操作提供命令列實現自動化，提供完整的監控和日誌方案。

Cloud Foundry 和 OpenShift 是兩款重要的開源 PaaS 平臺，其中 Cloud Foundry 是 Pivotal 開源，支援多種語言、框架、雲平臺，旨在讓開發者能夠忽略架構問題，快速部署和擴充套件應用；OpenShift 是 Red Hat 開源的，功能和 Cloud Foundry 差不多，網路上有很多兩者的對比文章，這裡不再贅述。目前兩者都已經開始擁抱容器、Docker、Kubernetes 技術，希望能和容器深度整合。它們的特點是功能強大，可擴充套件性強，但是相應的，複雜程度也高。

隨著 Kubernetes 的快速發展，很多以 Kubernetes 為容器管理平臺和應用管理的公司也都出來了，Datawire 基於 Kubernetes，側重於微服務的管理；Containership 也是 Kubernetes 的管理平臺，可以在多個雲平臺自動化部署和統一管理；Giant Swarm 提供混合雲和多租戶的 Kubernetes 管理；Kubermatic 能夠給使用者提供一鍵 Kubernetes 叢集安裝和多叢集管理服務；Gravitational 提供多 Regions 的 Kubernetes 叢集管理。

Atomist 和 Cloud 66 側重於 DevOps 流程；Flynn 是基於 Docker 容器技術的開源 PaaS 軟體，相比 Cloud Foundry 算是輕量級的實現；Hyper.sh 比較有趣，它們以容器介面來提供虛擬機器服務。

其他一些平臺提供的服務如下：

這塊內容主要是容器創業公司，提供的都是基於 Docker、Kubernetes 或者其他容器技術的方案，因此做的事情大同小異，就不再一一介紹了，感興趣的可以根據圖中列出的公司自行瞭解。

Serverless/Event-based

容器技術把微服務的概念吵得火熱，隨後也讓 Serverless 這個詞出現了大眾的面前。既然容器能夠遮蔽基礎設施，讓開發者只關心交付的應用（容器映象），那麼我們可不可以更進一步，讓開發者也不要關心交付的映象，只關註業務的核心邏輯呢？這就是 Serverless 的想法，開發者定義好基於事件觸發的業務邏輯，其他一切都交給平臺，當使用者發出請求或者其他事件發生時，平臺會根據事先的配置自動執行響應的業務邏輯程式碼，從而實現真正的按需服務。如果說容器關心的是應用，那麼 Serverless 關心的則是函式。Serverless 不是沒有伺服器，而是不用關心伺服器和系統。

Serverless 是一個很新穎的技術，雖然理念非常好，但現階段還不適用於所有的應用，主要是因為它的效能問題，以及距離成熟使用還缺少很多工具和方案，另外開發流程要接納這種理念還需要一段時間。

AWS Lambda 服務算是商業產品中比較成熟的，它的出現讓 Serverless 從概念化和實驗化的東西變成了可行的方案。微軟家的雲平臺也推出了 Azure functions；Google 家對應的產品叫做 Cloud Functions，從命名來看亞馬遜略勝一籌。

OpenFaaS、Fission 和 Kubeless 都是基於 Docker 和 Kubernetes 開源的 Serverless 開發框架，如果要想打造自己的 Serverless 平臺可以參考。

基於雲原生的平臺建立起來之後，我們要保證整個平臺能夠正常工作，保證執行在其上的服務不會因為平臺錯誤而導致不可用，而且還要知道應用整體的執行情況，提前對某些可能出錯的地方進行報警，一旦出錯能夠提供合適的資訊便於除錯和修複……這些都是觀察（observability）和分析（analysis）要做的工作，為了方便下麵統一使用監控（monitoring）一詞。

NOTE：對於監控、觀察、分析、日誌等詞語的使用並沒有非常嚴格的定義，監控是 IT 行業比較傳統的叫法，表示對應用和系統執行情況的資料統計和展示。目前有個叫法是觀察，分為metrics/monitoring、logging 和 tracing 三個部分。為了容易理解，我們使用監控一詞來代替，它廣義地包含了以上所有內容。

監控對於系統來說非常重要，沒有監控的平臺就像沒有儀錶盤的飛機。監控的標的有幾點：

Monitoring

簡單來說，監控就是瞭解應用和系統執行情況。

我們最常見的監控是對主機的監控，瞭解 CPU、記憶體、磁碟 IO、網路等資源的使用資料，以此瞭解主機是否正常，是否需要加硬碟或者擴充套件叢集，是否有記憶體洩露等等。另外一個監控是應用的監控，不管是資料庫、快取伺服器、訊息佇列、代理和快取伺服器，還是自己編寫的應用，我們需要知道它們的執行情況，這個監控依據每個應用而定，監控方法、監控的資料以及解讀方法對不同的應用來說會千差萬別。

而容器的出現，讓監控出現了另外一個維度：容器和平臺的監控。我們不僅要知道每個主機的執行資料，還需要知道每個容器的資料，這個容器使用的 CPU、記憶體、磁碟 IO 和網路等，這個新的需求也就催生了新的監控思想和工具。

Zabbix 是老牌的監控工具，功能強大，最近介面也改進了不少；Nagios 和 Graphite 是另外兩個經典的監控工具。Sensu 是一款較新的監控工具，Riemann 也能夠進行分散式系統的集中式監控處理。

InfluxDB 和 OpenTSDB 都是時序資料庫，後者是基於 HBase 的。

AWS CloudWatch 是AWS 自家的監控工具，當然是負責 AWS 雲上的服務監控；Azure Log Analytics 是微軟家日誌監控工具。很多商業公司也提供各種各樣的監控產品：AppNeta、Axibase、APPDynamics、Datadog、Dynatrace、NewRelic 和 Splunk 都提供應用級別的監控和資料分析業務。

再介紹一下經常聽到的監控工具：

圖中列出的監控公司和工具還有很多，這塊的創業公司也很多，因為監控的資料不像業務資料那樣機密，因此很多公司願意使用 SaaS 監控服務。

Logging

日誌容易理解，就是程式執行輸出的資訊，它們是除錯的利器，當程式出錯的時候，有效的日誌分析能夠快速定位問題。同時日誌也能承擔一部分的監控功能，反應系統執行是否正常。

Fluented 是一個開源的基於資料流（stream）的日誌收集框架；Graylog 是另外一個開源的選擇，它們的思想都是把日誌從系統各處收集起來進行統一分析、過濾和管理；Elastic 提供 ELK（Elasticsearch、Logstash、Kibana） 技術棧負責日誌收集，也提供線上的企業級 SaaS 服務。

Tracing

隨著微服務的採用，使用者的一個請求可以中間會經過多個不同的微服務才最終得到應答。傳統的監控、日誌都是針對單個元件的分析，用來瞭解當前元件的健康和執行狀態，並不能給我們一個整體的動態的情況。

對於微服務來說，我們需要知道一個請求到底經過了哪些元件，每個元件耗費了多少時間，錯誤發生在中間的哪個步驟，每次呼叫的網路延遲是多少等等。對於使用不同語言、開發框架、資料庫、和系統的微服務，我們需要有統一的跟蹤標準，這就是 tracing 要做的事情。分散式的 Tracing，一般都受到 Google Daper 系統的設計影響。

OpenTracing是一個開放的 Tracing 介面標準和檔案，提供了各種語言客戶端的實現，支援的 Tracing 工具包括 Jaeger、Appdash 和 Zipkin（Twitter 開源）；Cloud Sleuth 是 Spring Cloud 全家桶中一員，主要負責 Tracing 功能。

這些 Tracing 工具都需要在應用中編寫對應的程式碼，和 Logging 和 Metrics 類似，使用者可以自定義要 Tracing 程式碼塊的範圍和父子關係。此外，也有很多工具會自動化嵌入服務元件之間的 Tracing 資料，比如之前講過的 Istio。

Database & Data Analytics

資料庫一直是軟體領域的核心元件，所以包括了很多老牌的資料庫軟體，比如 MySQL、DB2、Oracle DB、PostgreSQL、MariaDB 等關係型資料庫。基於這些傳統的資料庫也有很多周邊的工具和軟體，比如 Vitess 這種資料庫叢集工具；阿裡巴巴開源的 SQL 資料庫連線池工具 Druid，它還同時提供了監控功能。

NoSQL 的發展也讓很多新型的資料庫出現在了我們的視野：有 Redis、Couchbase 這一類的 KV 資料庫；也有 MongoDB、RethinkDB、RavenDB 為代表的檔案類資料庫；Cassandra、Hbase、Vertica（列式關係資料庫）、Scylla（KVM 之父的作品，旨在成為下一代的 Cassandra 資料庫） 這樣的 Column 資料庫。它們最重要的特點是能夠輕鬆進行叢集擴容，不支援 SQL 查詢，因此介面上都以其他形式滿足使用者各種各樣的資料需求。

其他相關的資料庫產品包括：

資料庫是整個軟體技術的基礎，現在有個很流行的觀念是：資料是一家公司最重要的資產之一。我們對資料庫的要求也是更快、更多、更好，所以會有很多資料庫相關的產品來解決各種各樣的資料儲存和處理需求。

Streaming

流處理與批處理對應，要求對海量資料的實時採集、計算和查詢，很多業務場景要求盡可能快得對資料進行分析，從而做出決策，比如感測器、流量監控、股市行情、遊戲資料分析等，對此類需求也催生了很多實時處理工具。

Kinesis 是亞馬遜官方的流資料處理平臺，是其雲端計算產品的一部分；Cloud Dataflow 是 Google 的流處理產品；開源方面，Apex 是 Apache 旗下開源的新型實時資料處理平臺；Heron 是 Twitter 開源的資料處理平臺，是 Apache Storm 的繼承者；Spark 和 Flink 支援流處理的同時也支援批處理操作，兩者定位非常相似，但內部實現的差距挺大。

Kafka 和 RabbitMQ 這類訊息佇列可以做到資料的快速收集；NiFi 是另一個 Apache 專案，是一個資料整合和分發系統，專門為資料流設計。

SCM（Source Code Management）

雖然容器讓產品以映象的作為產出，但是程式碼還是要維護的，最有名的社群原始碼管理平臺自然是 GitHub，GitLab 是開源自建 SCM 的推薦選擇，Bitbucket 和 GitHub 定義類似，提供免費也提供商業版本的服務。

Application Definition

應用定義並沒有明確的定義，大概要做的事情是遮蔽底層基礎設定、雲平臺以及容器執行時，封裝一個標準化的應用定義，從而實現應用自動化執行在任何地方。

CI/CD

持續整合和持續部署主要用於自動化地處理所有的 ops 的工作，包括從程式碼提交一直到應用部署到線上的整個過程的自動化。CI 側重於構建和測試，CD 側重於部署。

網路也有很多文章對 CI/CD 的軟體進行比較，比如這篇 《Jenkins vs travis vs teamcity vs codeship vs gitlab vs bamboo[5]》，其他的工具就不一一介紹了，感興趣可以自行搜尋。

如果做個總結的話，2017 年 CNCF 雲原生生態目前有如下的趨勢：

CNCF 列出的生態只是一個參考，很多軟體和公司並沒有出現在這裡，在構建雲原生應用時不必拘謹於此。構建雲原生架構是一個過程，不同的階段會選擇不同的工具和平臺，並沒有完全”標準”的做法。

另外一個沒有出現在這裡，但是隨平臺規模增長變得越發重要的話題是效能分析和最佳化，因為這個話題並沒有統一的標準和方案，只能具體問題具體分析，而且整個過程比較複雜，所以很少有提供一站式方案的軟體和公司。

每個特定的問題都有多個工具和解決方案，這樣的情況就要求我們必須做出選擇，知道每個工具要解決什麼問題，有哪些取捨，和其他元件是否容易整合，社群活躍度……然後根據自身的情況和需求，找到最適合自己當前發展的工具。切不可一心求新求全，不然會帶來嚴重的後果：

推薦的方式是循序漸進，以滿足最核心需求為主去選擇合適的技術，優先使用比較穩定、檔案豐富和社群活躍的。充分瞭解選擇版本哪些功能是非常穩定可以直接使用的；哪些功能不太穩定，但是可以在開發和測試環境中小規模使用的；哪些功能是不穩定，需要測試開發或者等待社群進度的。如果有應用需要從舊環境遷移，編寫自動化工具，並提供回滾的功能，以灰度釋出的方式逐步遷移到容器叢集。對於新技術，可以花時間去跟進，在合適的時候及時引進。

切不可聽到別的公司使用了某個技術，自己就一定要用。如果沒有問題要解決，引入新工具只會帶來新的問題而已。

相關連結：

1. https://github.com/cncf/landscape

2. https://www.intigua.com/blog/puppet-vs.-chef-vs.-ansible-vs.-saltstack

3. https://www.upguard.com/articles/the-7-configuration-management-tools-you-need-to-know

4. http://cizixs.com/2017/11/05/oci-and-runc

5. https://blog.takipi.com/jenkins-vs-travis-ci-vs-circle-ci-vs-teamcity-vs-codeship-vs-gitlab-ci-vs-bamboo/

6. https://medium.com/memory-leak/cloud-native-landscape-celebrates-first-anniversary-69a4eb829505

7. https://medium.com/@copyconstruct/monitoring-in-the-time-of-cloud-native-c87c7a5bfa3e

8. https://medium.com/memory-leak/this-year-gartner-added-serverless-to-its-hype-cycle-of-emerging-technologies-reflecting-the-5dfe43d818f0

原文連結：http://cizixs.com/2017/12/30/cncf-cloud-native-landscape