容器平台加速并简化云应用开发

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

容器平台风行一时,但是开发人员的期望也需要管理。Red Hat的OpenShift产品策略师提供了来自内部的看法。

如果开发人员不是在谈论微服务,那一定是因为他们正在谈论容器。随着移动应用与云应用开发技术的日益成熟,容器技术的使用也变得越来越普遍。那么为什么不呢?它们提供了简便的平台可移植性,可确保应用程序在从测试环境迁往生产环境时保持一致的运行性能。增加过程隔离可提高安全性,其技术也变得简单不可抗拒。

近期在波士顿召开的Red Hat峰会有5000多名开发人员参加,在会议期间,Red Hat OpenShift容器管理平台产品策略总监Brian Gracely接受了TechTarget的独家采访。

为了实现数字转型,据说我们需要了解一个可组合的容器平台的概念。您能告诉我们这是什么吗?

Brian Gracely:平台不仅能够帮助开发人员更快地部署他们的应用,还可以帮助运营让应用更顺畅地运行。众多平台本身还具有一定的差异——这是关于用户应当如何做,它将让用户走得更快。早期的平台限制太多,支持的语言不多,标准化程度不高。

我们认为Red Hat OpenShift是更加标准化的。它是基于容器的标准和诸如Kubernetes之类的编排标准。但是,如果用户不喜欢我们提供的开箱即用的监控功能,我们还提供了更高程度的模块化功能,用户可以有多种选项来进行定制且不会丢失任何功能。我们最终的意图是想要为用户提供一个易于操作的超棒开发体验,此外我们还希望为用户在其他方面提供一个更好的灵活性,如存储、网络以及监控等。

如果存在技术限制或供应商方面的原因,用户是否无法选择在平台中采用某一工具?

Gracely:供应商希望用户使用他们的技术,但是很多技术在成规模应用并出现标准之前还不够成熟。有些技术确实得到了发展;Docker来自于一家平台供应商,其技术发展成为了标准。一项技术是否能够得到发展,主要取决于其成熟度以及用户是否喜欢。

使用诸如OpenShift容器平台的IT部门是如何跨云平台实现应用安全部署以及减少开发、测试和运行新开发与现有应用程序的时间?

Gracely:我们在OpenShift上做了大量的工作。安全性始终一直是我们的第一要求。从Red Hat Linux企业版开始就是如此。从Red Hat公司角度来看,安全性是我们一切工作的基础,OpenShift平台亦是如此。所以当用户部署应用程序时,容器将是安全的,平台通信、应用程序之间的内部通信都进行了加密处理。我们还对用户的安全密钥进行了加密。我们确保围绕权限和身份验证的所有内容都内置在平台中。当用户使用这个安全的平台时,用户完全可以在自有数据中心内运行,在Azure、AWS或谷歌平台上运行。

容器平台、容器管理以及平台即服务是如何帮助开发人员和运营团队更好地了解业务流程,并最终帮助提高盈利能力?

Gracely:容器的一大优点就是他是与开发人员相关的首要技术之一。它为用户提供了一个大包应用的标准方法。它还与运营团队有着较高相关性,因为它将实现基础环境自动化。它将帮助用户扩展这些环境。用户现在所拥有的是这种语言的共同性,大家都知道那是在过去我们无法一直拥有的。谈谈开发团队和运营团队。

当底层基础设施和开发人员使用一种通用语言时,我可以从一个商业理念开始。我可以在实验中开发出一个最小可行的产品。我可以实现快速的部署、完全的自动化,而企业也能在几周甚至几天内看到结果。在我们的主题演讲中,有一位客户说他的观念就是从想法到执行直至走向客户只需几天的时间。拥有这种快速的技术将有助于我们的新想法和新产品快速可见和成为可能。

这对于老观念的人来说是一个严重的问题。

Gracely:在未来,对于规划的传统思维方式将成为一大阻碍。人们将不得不与时俱进。

云与移动应用程序的发布周期从几年变为几天。即所谓的“先快出货,后打补丁”。对于缺乏OpenShift或其他容器平台的情况下,这种无法进行全面测试的真正影响是什么?

Gracely:最终用户现在已经习惯了这种持续更新的理念。从本质上来说,我们围绕OpenShift解决这一问题的方法是采用一个Docker或Kubernetes项目,我们确保在某一个特定时间内及时抓住它。我们集成了这些组件,完成了大量的测试,而其结果就是用户最终能够获得经过测试、运行基本稳定的软件。

接下来的一部分就是,“如何在不停止服务的情况下完成应用更新?”这就是我们针对自动化工具(如在Ansible和云形式中)所开展大量工作的意义所在,这些自动化工具能够帮助用户完成持续不断的升级。有时候,人们称其为Blue-Green升级,即可以升级一定数量的用户,从而确保应用程序正常运行,然后再完成剩余用户的升级。业内存在着这样一个认知,如果我只是用之前的方法为用户提供相同的软件,我不会让这个方法更简便,那样做也不会发挥作用。我们一直在这两个方向上同时投入。

开发人员在项目开发阶段使用容器平台的最大错误是什么?

Gracely:我们看到开发人员使用旧的传统模式,而没有思考是否有新方法来实现其现代化。我认为容器开发人员和应用开发人员的最大努力应该是关注如何开展核心业务。不要总是因为任何最新、最小的东西而分心。容器中有很多东西。新开发框架中也有很多东西。擅于掌握那些能帮助你解决实际业务问题的技术和方法。容器就是这样一种非常灵活的技术。

本文转自d1net(转载)

相关文章
|
设计模式 Linux 程序员
Linux驱动的软件架构(一):驱动的软件设计模式理念
Linux驱动的软件架构(一):驱动的软件设计模式理念
239 0
|
设计模式 Java
时光倒流:解析Java设计模式中的备忘录模式
在软件开发领域,设计模式是一组经过验证的最佳实践方法,用于解决各种常见问题。备忘录模式是一种行为型设计模式,其目标是在不破坏对象封装的前提下,捕获对象的内部状态,并将其保存在外部以备将来恢复。在本文中,我们将深入了解备忘录模式的核心思想、应用场景以及它在Java中的实际运用。
160 0
剑指offer(数组相关面试题)
剑指offer(数组相关面试题)
|
监控 前端开发 网络协议
小六六学Netty系列之再遇Netty
前言 文本已收录至我的GitHub仓库,欢迎Star:github.com/bin39232820… 种一棵树最好的时间是十年前,其次是现在
167 0
|
存储 Kubernetes 网络协议
Kubernetes网络分析之Flannel
Flannel是CoreOS开源的CNI网络插件,下图flannel官网提供的一个数据包经过封包、传输以及拆包的示意图,从这个图片里面里面可以看出两台机器的docker0分别处于不同的段:10.1.20.1/24 和 10.1.15.1/24 ,如果从Web App Frontend1 pod(10.1.15.2)去连接另一台主机上的Backend Service2 pod(10.1.20.3),网络包从宿主机192.168.0.100发往192.168.0.200,内层容器的数据包被封装到宿主机的UDP里面,并且在外层包装了宿主机的IP和mac地址。
3379 0
|
XML Java 数据格式
Spring 5.0中文版-3.9
3.9 基于注解的容器配置 在配置Spring时注解是否比XML更好? 基于注解配置的引入引出了一个问题——这种方式是否比基于XML的配置更好。简短的回答是视情况而定。
1004 0
|
6天前
|
存储 关系型数据库 分布式数据库
PostgreSQL 18 发布,快来 PolarDB 尝鲜!
PostgreSQL 18 发布,PolarDB for PostgreSQL 全面兼容。新版本支持异步I/O、UUIDv7、虚拟生成列、逻辑复制增强及OAuth认证,显著提升性能与安全。PolarDB-PG 18 支持存算分离架构,融合海量弹性存储与极致计算性能,搭配丰富插件生态,为企业提供高效、稳定、灵活的云数据库解决方案,助力企业数字化转型如虎添翼!
|
17天前
|
弹性计算 关系型数据库 微服务
基于 Docker 与 Kubernetes(K3s)的微服务:阿里云生产环境扩容实践
在微服务架构中,如何实现“稳定扩容”与“成本可控”是企业面临的核心挑战。本文结合 Python FastAPI 微服务实战,详解如何基于阿里云基础设施,利用 Docker 封装服务、K3s 实现容器编排,构建生产级微服务架构。内容涵盖容器构建、集群部署、自动扩缩容、可观测性等关键环节,适配阿里云资源特性与服务生态,助力企业打造低成本、高可靠、易扩展的微服务解决方案。
1327 7