Red Hat如何评论NFV,容器和微服务

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介:

尽管NFV的概念已经存在多年,但根据Red Hat的Brian Gracely的说法,网络功能虚拟化(NFV)仍然还在曲线发展中。

010e15086de872754fa7b21424c4fbaaefa9ee3d

Red Hat的产品战略总监Gracely谈到了运营商部署NFV的一些困难,以及容器和微服务的成熟度。

FierceTelecom:在最近的一次采访中,沃达丰的Fran Heeran表示,该行业应该花更少的时间专注于NFV和更多时间进行云计算。您如何看待NFV的现状,以及它的发展方向?

Brian Gracely:嗯,我认为这有几个部分。我们有一组工程团队专注于Red Hat的NFV。我们主要使用OpenStack,因此“我们如何虚拟化这些功能,或者我们如何虚拟化该软件服务?”或者“我们如何将其纳入虚拟机,而不依赖于专有硬件?”这些问题都很重要。

一些电信运营商正在努力获得足够的带宽和希望使用通用的x86体系结构的机器替代底层的各种异构的专用设备,而不是从Juniper或思科那里获得定制的ASIC。要实现这一目标还是有挑战的,这是专用硬件与通用硬件之间一场战争。但是“我们如何将以前的硬件功能转变为软件功能?” 这一方面我认为还是取得了很好的进展。

另一方面,我认为,当他们进入某种云化时,其中有一部分技术人员在工作了一段时间后看到新的东西出现了,他们会说“哦,我们应该摆脱这些旧东西,去做新的东西。” 即使在NFV领域,我们也看到人们正在质疑“我是否坚持在虚拟机上执行此操作,还是将其转移到容器技术上?” 因为容器和Kubernetes似乎有点新鲜和热门。这恰好是技术好奇心和技术一起发展的步伐。

当他们开始说“我们应该将我们的NFV移动到云端”时。就在那时我们说“嗯,你想做什么?你认为你会参与应用软件业务吗?你会为移动电话或其他东西建立新的应用程序吗?”

现在,技术人员正在从技术的好奇心转向准备进入该业务阶段,因为该业务与提供网络服务,无线服务和安全服务完全不同。这就是我看到一些公司挣扎的地方,因为他们认为,“我们希望成为与现在不一样的人”,但他们并没有意识到要达到另一个目标是多么大的跳跃。

这些都是技术都无法帮助的地方。抓住新领域中的开源项目并不意味着您就知道如何通过该域名获利。

该技术可以帮助您实现目标,但在云提供商和电信公司看来他们希望技术更快地发展,以至于他们有时会忽略学习曲线。

每个软件公司都会面临同样的挑战。就像我说的那样“你想做这个行业,你想要在这个市场领域占有一席之位吗?”

FierceTelecom:在另一次采访中,Colt的网络负责人Mirko Voltolini表示他认为容器还没到使用的时候,并且VNF应该考虑到微服务。你对这些想法有什么看法?

Gracely:对于VNF最初考虑的是,“我们希望将软件功能从硬件功能中分解出来。” 这就是为什么人们开始在这个领域进行虚拟化的原因,因为他们会说,“好吧,我仍然可以获得相同的软件功能,它可以是负载平衡器,代理服务器或任何VNF功能,但我的目的是可以在通用硬件上运行它。”

如果你看一下成熟度水平,虚拟化现在已经存在了10多年,现在可能接近15年了。但容器在不到五年的时间里已经变成了一种可行的技术。所以有人说容器并不是我想要的容器,我认为如果你将它们与虚拟化进行比较是公平的。

容器的创新步伐现在变得非常快,因为它不依赖于某个特定的供应商,也不仅仅只与VMware有关,而且我认为未来我们会看到容器的成熟度会迅速提升。

与他对话的第二部分是“我想转向微服务”,这实际上是一个软件开发,应用程序框架。“我不想构建一大块软件。我想把这一大块的东西分成几块,然后把它分解成一堆,我想我可以单独和集体地处理每一件。将软件分成几个块可能比在一大块软件上处理起来速度更快。“ 而这正是业界想要试图改变的事情。对于一些客户来说,这是他们可以处理的事情,他们从头开始,他们从一个新的应用程序开始,然后看着如何分解他们。

如果他们想把现有的应用程序拿走然后尝试分解它们,那么对于大部分的客户而言,这是非常困难的事情。因为他们现有这些程序不是以这种方式设计的,或者那些开发人员已经不在了,又或者他们无法访问源代码等很多原因。

如果他们说“嘿,容器和微服务还没有准备好迎接黄金时段,或者周围没有足够的工具”,我不同意他们的看法。因为这是让您的组织快速掌握使用这些东西的关键问题。

现实是有一条学习曲线来计算如何使用它们,这也许就是为什么他们会意识到缺乏成熟度的原因。但我认为,今天已经有很多公司这样做了。因此,并不是没有人能做到这一点。只是想要把容器做好需要专业的职业技能,致力于实现这一目标的决心。而且公司也应该并将其作为优先发展的业务。


原文发布时间为:2018-09-25

本文来自云栖社区合作伙伴“SDNLAB”,了解相关信息可以关注“SDNLAB”。

相关文章
|
19天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
1月前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
13天前
|
关系型数据库 MySQL Docker
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
73 24
|
15天前
|
关系型数据库 MySQL Docker
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
91 6
|
20天前
|
Kubernetes Cloud Native Docker
云原生之旅:从容器化到微服务
本文将带领读者踏上云原生的旅程,深入探讨容器化和微服务架构的概念、优势以及它们如何共同推动现代软件的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务应用,并解释相关的配置和操作。无论你是云原生新手还是希望深化理解,这篇文章都将为你提供有价值的见解和实操指南。
|
26天前
|
Kubernetes Cloud Native 开发者
云原生入门:从容器到微服务
本文将带你走进云原生的世界,从容器技术开始,逐步深入到微服务架构。我们将通过实际代码示例,展示如何利用云原生技术构建和部署应用。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的信息和启示。
|
26天前
|
Kubernetes Cloud Native 持续交付
容器化、Kubernetes与微服务架构的融合
容器化、Kubernetes与微服务架构的融合
45 1
|
26天前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
55 1
|
28天前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。
|
1月前
|
Cloud Native 云计算 Docker
云原生技术的崛起:从容器化到微服务架构
云原生技术的崛起:从容器化到微服务架构