Oracle副總裁談2018年容器原生應用程式的發展

2017年對原生容器界來說是不可思議且非常重要的一年。 Kubernetes毫無爭議地贏得了容器化管理和協調的戰爭，開源軟體已經跨組織獲得了廣泛的認可，而且雲供應商（至少是大部分）都響應號召更多的開源雲中立技術。而2018年的所有夢想都是建立在所有這些行業標準化和進步的基礎上的。

在回顧了2017年的激動和進步[1]之後，我發現在容器原生應用程式開發中（或者是Kubernative？-繼續閱讀）存在很多很多的機會，下麵就個人對於2018年的一些預測，跟大家分享一下！

由雲原生計算基金會（Cloud Native Computing Foundation）牽頭的雲原生開源承諾和使用在即將過去的一年中有了大幅增長。在2018年，企業在繼續加快開源的承諾的同時，也將面臨一個新的挑戰——即如何更快，更舒適的“消化”開源軟體（我們大家在節日期間都可能面臨的挑戰！）。雖然企業在逐漸同化吸收這些技術，但是對於企業來說持續的“吃不下”或持續的“吃太多”（此處的CI / CD指的都是不好的那種）的風險都非常大。

因此，問題來了——企業將如何更快更好地消化開源呢？答案就是：透過轉向基於開源軟體的託管服務——同時請立刻停止自己的瞎搞！2017年將作為紀念“I Stood Up My Own K8s”自我麻醉的最後一年。我們沒有理由在2018年花費寶貴的開發和DevOps的時間執行和維護自己的開（瞎）源（搞）平臺。

在2017年，大家經常看到業內推出的為開發團隊推出的離散和不相關的各種雲服務“浪潮”，這不利於整合的，連貫的開發體驗。所謂“解體”就是“失去凝聚力或力量的過程”，或者說“即將到來的碎片化”過程——這也是開發人員正面臨的如何將這些零散的雲服務整合成一個整體的問題。舉個例子，許多雲提供商就像一個充滿食材的大型雜貨店，但是當你真正想要做的只是eat時，他們往往會誘導你去購物，準備，做飯和清理等。是的，每隔一段時間（可以是365天裡的每一天或每一週）就自己做一頓美味又難忘的飯菜真是太爽了——當然並非所有的飯菜都得自己做。2018年，企業將轉向雲服務供應商提供的綜合體驗全套餐- 包括吃喝拉撒的全面配對和“享受”之後的全面清理！

如果所有雲提供商都提供相同的基於開放原始碼的服務（例如，Docker，K8s）——所有這些服務僅為你使用的IaaS資源而定價，那麼你將如何選擇？對於2018年的許多企業來說，影響選擇的因素將歸結為“ilities”——比如：“可擴充套件性”，“安全性”，“可用性”，“可靠性”和“可用性”等。通常這可以被描述為“企業級”，或者我們已經把它描述為“成熟的開源”。

這類似於從大學畢業，並開始欣賞好東西——無論是你吃的食物，你喝的酒或飲料，你開的車，或者你穿的衣服。開源的最大特點就是免費並且充滿樂趣，但是當你需要在其上執行企業應用程式，你就需要考慮一些可靠的東西 – 而這恰恰是“ilities”的強項。2018，質量為王（你懂的）。

如果2017的KubeCon / CloudNativeCon大會只是一個導火線，2018年將是我們從pods，kubectl’s，和masters轉移到開放的服務中介，service meshes和circuit breakers的一年。截至目前，我們會選擇像Istio一樣的專案。企業將利用來自早期的擴充套件微服務從業者，並應用一套標準的安全性，可觀察性和可靠性的樣式，這些樣式已被證明是成功的，且是行星級微服務部署所必不可少的。

當你開始習慣Kubernetes概念時，我們要明白最先進的技術往往是基於簡化的假設，即我們將從Kubernetes的基礎開始。這就是平臺標準的力量，現在已經可以成為供應商和銷售商認證的Kubernetes。

Java仍然是世界上最受歡迎的開發和應用程式平臺之一——所以讓我們再繼續添磚加瓦，以加快其釋出週期和雲創新。隨著應用程式過渡到基於容器的，模組化的微服務和功能，Java的在2018年將解決開發人員對更頻繁釋出的需求，同時支援由雲驅動的不斷變化的環境所需的靈活許可，以及從診斷到雲創新。

無伺服器已經成為迄今為止最大的封閉和專有雲本地技術領域之一。這迫使企業在雲端計算鎖定或採用Lambda等早期服務工具之間進行選擇。2018年這一切都將改變為一套開放的無伺服器專案，比如我們自己的Fn專案和CNCF的努力。“Open on Open”是在2018年將無伺服器開放的唯一方法——也是在Kubernetes基礎之上的整合堆疊上構建無伺服器解決方案。

而在2018年，也許我們可以在我們的技術命名法中脫離“無伺服器”這個術語，而把註意力集中在“功能”上。但我不會完全指望它。

如果2016年是關於雲原生的，那麼到2017年將會向上升到容器原生，那2018年呢？看起來我們將要上升到Kubernetes原生了。Kubernetes將成為使人們與他們的產品互動的媒介。尋找關鍵產品的快速出現和廣泛的可用性的K8S運營商。如果Kubernetes有標準的管理和編排結構，那麼越來越多的企業會要求透過該層面進行標準化管理，供應商會透過新增Kubernetes運營商來進行響應，使他們的互動成為“Kubernetes-native”——或者更簡單的“Kubernative？”

隨著開發團隊意識到在這個新的容器原生世界，向以Docker為中心的現代CI / CD[2]的過渡，讓你的工具鏈具有Docker感知能力，並且Kubernetes-native為他們提供了生產力優勢，以提高釋出節奏和釋出週期。CI / CD不再是一個獨立的工具，更多的是完整的容器生命週期平臺，可以無縫整合整個構建，部署和執行DevOps迴圈。因此透過內建的容器登錄檔整合和一鍵式原生Kubernetes部署自動化自然可以實現。

目前正在解決Kubernetes成長的難題：易處理，可管理和合規性。在過去幾年中，我們已經看到了在採用Docker和Kubernetes這樣強大的軟體後，運營團隊和企業管理團隊總會遇到第二階段的“困難”問題。

好訊息是，已經有一整套用於工作和行業活動在一個整合的操作工具堆疊上進行監視，觀察和記錄專案日誌，如Prometheus，Open Tracing，Jaeger以及在CNCF中領先的Fluentd。此外，Kubernetes Federation的工作正在開始解決更複雜的多叢集多管理[3]操作挑戰，如管理和自動擴充套件全球應用程式或按需部署現場叢集。

相關連結：

1. https://blogs.oracle.com/developers/meet-the-new-application-development-stack-kubernetes-serverless-registry-cicd-java

2. https://www.thenewstack.io/tag/Continuous-integration-and-deployment

3. https://blogs.oracle.com/developers/kubernetes-serverless-and-federation-oracle-at-kubecon-2017

原文連結：https://thenewstack.io/container-native-application-development-in-2018-an-oracle-executives-take/