Oracle副总裁谈2018年容器原生应用程序的发展

最新推荐文章于 2024-02-17 14:35:54 发布

Docker_

最新推荐文章于 2024-02-17 14:35:54 发布

阅读量1.2k

点赞数

2017年对原生容器界来说是不可思议且非常重要的一年。 Kubernetes毫无争议地赢得了容器化管理和协调的战争，开源软件已经跨组织获得了广泛的认可，而且云供应商（至少是大部分）都响应号召更多的开源云中立技术。而2018年的所有梦想都是建立在所有这些行业标准化和进步的基础上的。

经过几年的单个云厂商恶性竞争后，企业级开发团队迎来了新的春天，他们将获得很多的灵活性和更多的选择，因为这些开源技术在业内云服务提供商中普遍存在。随着容器技术的成熟，企业在这些新选择的基础上可以有更好的选择，而微服务和容器技术将会越来越常见。

在回顾了2017年的激动和进步[1]之后，我发现在容器原生应用程序开发中（或者是Kubernative？-继续阅读）存在很多很多的机会，下面就个人对于2018年的一些预测，跟大家分享一下！

1. 托管服务替代开源DIY

由云原生计算基金会（Cloud Native Computing Foundation）牵头的云原生开源承诺和使用在即将过去的一年中有了大幅增长。在2018年，企业在继续加快开源的承诺的同时，也将面临一个新的挑战——即如何更快，更舒适的“消化”开源软件（我们大家在节日期间都可能面临的挑战！）。虽然企业在逐渐同化吸收这些技术，但是对于企业来说持续的“吃不下”或持续的“吃太多”（此处的CI / CD指的都是不好的那种）的风险都非常大。

因此，问题来了——企业将如何更快更好地消化开源呢？答案就是：通过转向基于开源软件的托管服务——同时请立刻停止自己的瞎搞！2017年将作为纪念“I Stood Up My Own K8s”自我麻醉的最后一年。我们没有理由在2018年花费宝贵的开发和DevOps的时间运行和维护自己的开（瞎）源（搞）平台。

2. 整合取代解体

在2017年，大家经常看到业内推出的为开发团队推出的离散和不相关的各种云服务“浪潮”，这不利于整合的，连贯的开发体验。所谓“解体”就是“失去凝聚力或力量的过程”，或者说“即将到来的碎片化”过程——这也是开发人员正面临的如何将这些零散的云服务整合成一个整体的问题。举个例子，许多云提供商就像一个充满食材的大型杂货店，但是当你真正想要做的只是eat时，他们往往会诱导你去购物，准备，做饭和清理等。是的，每隔一段时间（可以是365天里的每一天或每一周）就自己做一顿美味又难忘的饭菜真是太爽了——当然并非所有的饭菜都得自己做。2018年，企业将转向云服务供应商提供的综合体验全套餐- 包括吃喝拉撒的全面配对和“享受”之后的全面清理！

3. 质量第一（“ilities”年）

如果所有云提供商都提供相同的基于开放源代码的服务（例如，Docker，K8s）——所有这些服务仅为你使用的IaaS资源而定价，那么你将如何选择？对于2018年的许多企业来说，影响选择的因素将归结为“ilities”——比如：“可扩展性”，“安全性”，“可用性”，“可靠性”和“可用性”等。通常这可以被描述为“企业级”，或者我们已经把它描述为“成熟的开源”。

这类似于从大学毕业，并开始欣赏好东西——无论是你吃的食物，你喝的酒或饮料，你开的车，或者你穿的衣服。开源的最大特点就是免费并且充满乐趣，但是当你需要在其上运行企业应用程序，你就需要考虑一些可靠的东西 - 而这恰恰是“ilities”的强项。2018，质量为王（你懂的）。

4. 容器管理蒸蒸日上

如果2017的KubeCon / CloudNativeCon大会只是一个导火线，2018年将是我们从pods，kubectl’s，和masters转移到开放的服务中介，service meshes和circuit breakers的一年。截至目前，我们会选择像Istio一样的项目。企业将利用来自早期的扩展微服务从业者，并应用一套标准的安全性，可观察性和可靠性的模式，这些模式已被证明是成功的，且是行星级微服务部署所必不可少的。

当你开始习惯Kubernetes概念时，我们要明白最先进的技术往往是基于简化的假设，即我们将从Kubernetes的基础开始。这就是平台标准的力量，现在已经可以成为供应商和销售商认证的Kubernetes。

5. Java越来越屌

Java仍然是世界上最受欢迎的开发和应用程序平台之一——所以让我们再继续添砖加瓦，以加快其发布周期和云创新。随着应用程序过渡到基于容器的，模块化的微服务和功能，Java的在2018年将解决开发人员对更频繁发布的需求，同时支持由云驱动的不断变化的环境所需的灵活许可，以及从诊断到云创新。

6. 无服务器解锁云锁定

无服务器已经成为迄今为止最大的封闭和专有云本地技术领域之一。这迫使企业在云计算锁定或采用Lambda等早期服务工具之间进行选择。2018年这一切都将改变为一套开放的无服务器项目，比如我们自己的Fn项目和CNCF的努力。“Open on Open”是在2018年将无服务器开放的唯一方法——也是在Kubernetes基础之上的集成堆栈上构建无服务器解决方案。

而在2018年，也许我们可以在我们的技术命名法中脱离“无服务器”这个术语，而把注意力集中在“功能”上。但我不会完全指望它。

7. 原生Kubernetes要搞事情

如果2016年是关于云原生的，那么到2017年将会向上升到容器原生，那2018年呢？看起来我们将要上升到Kubernetes原生了。Kubernetes将成为使人们与他们的产品互动的媒介。寻找关键产品的快速出现和广泛的可用性的K8S运营商。如果Kubernetes有标准的管理和编排结构，那么越来越多的企业会要求通过该层面进行标准化管理，供应商会通过添加Kubernetes运营商来进行响应，使他们的交互成为“Kubernetes-native”——或者更简单的“Kubernative？”

8. 开发生产力促使工具链拥抱容器和Kubernetes

随着开发团队意识到在这个新的容器原生世界，向以Docker为中心的现代CI / CD[2]的过渡，让你的工具链具有Docker感知能力，并且Kubernetes-native为他们提供了生产力优势，以提高发布节奏和发布周期。CI / CD不再是一个独立的工具，更多的是完整的容器生命周期平台，可以无缝集成整个构建，部署和运行DevOps循环。因此通过内置的容器注册表集成和一键式原生Kubernetes部署自动化自然可以实现。

目前正在解决Kubernetes成长的难题：易处理，可管理和合规性。在过去几年中，我们已经看到了在采用Docker和Kubernetes这样强大的软件后，运营团队和企业管理团队总会遇到第二阶段的“困难”问题。

好消息是，已经有一整套用于工作和行业活动在一个集成的操作工具堆栈上进行监视，观察和记录项目日志，如Prometheus，Open Tracing，Jaeger以及在CNCF中领先的Fluentd。此外，Kubernetes Federation的工作正在开始解决更复杂的多集群多管理[3]操作挑战，如管理和自动扩展全球应用程序或按需部署现场集群。

更重要的是，将应用感知型决策逻辑应用于成本，区域倾向，性能，服务质量和合规性约束等部署选择的棘手问题。