采用微服务和容器架构的五个想法

作为New Relic容器Fabric项目(我们的内部容器编排和运行时平台)的首席站点可靠性工程师(SRE),我花了大量时间与现有和潜在客户一起回答关于我们如何使用和管理容器来创建由数十个微服务组成的平台的问题。

我们肯定认为自己是容器的早期采用者,我们几乎在2014年夏天发布了第一个可生产的容器版本后就开始在容器中包装服务。与我交谈过的许多客户都刚刚开始——或者正在考虑开始——这样的旅行,他们想知道我们所知道的一切。他们想知道我们如何使它工作,以及我们如何架构它。但是,我想强调的是,他们需要知道我们从我们在这个过程中所经历的事情中学到了什么。

考虑到这一点,以下是我想与任何考虑容器和微服务的人分享的5个要点:

1。发展永不停止

认真对待您的采用项目,把它像一个产品。给它一个名字,甚至一些内部品牌,一个清晰的产品愿景。它应该被管理并赋予生命。

我们当前版本的容器结构并不是我们第一次尝试自定义编排和交付。我们在2014年构建了我们的原始版本,一旦我们达到了我们认为需要的程度,我们就停止了开发。我们没有开发人员喜欢使用和构建的部署平台的完整愿景,它只满足我们对一致抽象层的需求。

所以两年过去了,我们才开始重新投资我们的集装箱平台。我们的第一个版本并没有停止使用,但是我们没有捕获Docker快速开发阶段中出现的许多增量改进。

我们一个运行时间最长的客户在同一时期经历了类似的容器编排/微服务过程,并且他们比我们今天走得更远。当我们问他们是如何走到这一步时,他们的回答非常简单:“我们只是一直在努力。”

2。逐步构建它,并从早期采用者开始

当你转移到容器时,采用一种新技术(如Kubernetes)并不意味着你直接进入深水区,将你的整个生产机群移动到巨大的可获得的集群中。把东西一块一块一块地做起来不是更容易吗?

当我们开始使用Container Fabric时,我们将rollout限制为最简单的用例,我们可以服务无状态HTTP服务——没有持久性、没有非HTTP协议,只有一个部署方案。这将平台的特性占用减少到我们知道我们可以在合理的时间范围内有效地服务。

这很重要,因为容器调度平台不能提供一切。我们仍然需要监视平台、对其部署更改、处理秘密、配置自动负载平衡和捕获日志——所有这些都是富服务平台附带的内容。限制目标服务类型使我们更容易推断平台的组件。

因此,如果您确定需要某种容器编排,请仔细查看容器平台提供的内容,并考虑缺少什么。您需要在该平台之上构建什么来支持您的特定服务和基础设施上下文?

此外,要了解团队的文化和可用性。谁是贵公司的早期采用者?哪些团队已经准备好进入一个新的范式?哪些团队正在构建适合于微服务体系结构的服务?哪些团队受困于遗留的巨大单体应用,需要更多的时间、计划和实验?

3、一个型号尺寸并不能适合所有人

当涉及到容器和微服务时,有些系统不适合这个模型,如果您从一开始就认识到这一点,就会更容易。新系统中的技术通常是,移植旧系统的努力可能比它的价值更麻烦。

我们的平台继续主要服务于HTTP服务,但我们也开始处理更多的流处理服务。我们仍然不做持久存储或数据库。(数据库团队使用Megabase处理这个问题。)

最新的技术和体系结构都是关于快速迭代和分散控制的,因此,如果这些东西对您的业务目标并不重要,那么就让这些旧的遗留系统慢慢退役,直到您有逻辑的业务需要迁移它们为止。

4、技术变化就是组织机构的变化

当New Relic团队将他们的服务转移到Container Fabric上时,他们的操作工作量通常会降低。在某些情况下,团队会减少大量的工作,使他们能够在其他项目上获得更多的回报。这是自动化减轻工作负担的最好例子,我们很高兴看到这一点。迁移过来的团队可以更自由地构建让客户满意的软件

考虑迁移到容器和微服务体系结构的组织应该问自己以下问题:

您的操作组向开发人员提供什么产品,该产品使用什么抽象层?

这对你的生意是合适的还是容器更合适?

容器是否更好,以至于您愿意更改抽象,从而更改您的操作团队提供的整个产品,以便使用它们?

您准备好创建新的角色来管理这个新的抽象的规模和可靠性了吗?

没有组织像这样一夜之间发生变化。从理想的新体系结构到第一次生产部署的过程需要改变许多人的想法并创建新的过程——这并不总是有趣的。

5、开发软件需要的是人的经验

一个丰富的、复杂的容器调度平台需要几百年的经验来构建、维护和扩展。这些平台和体系结构要求您接受新的上下文,并要求您的组织在设计中接受权衡取舍,以便您调整它以适应您的用例。采用容器化的微服务体系结构是一项很重要的工作,它可能会改变您所有团队的工作平衡;这会影响他们的生活方式;它有时会影响他们在工作中的幸福感。除非您真正考虑到平台采用的这些人的方面,否则迁移将会比需要的困难得多。

由于我们的组织结构,我们已经为成功的迁移做好了准备。新Relic的每个服务都由一个团队拥有,他们计划、计划、部署和操作它。这种结构已经存在多年,而容器Fabric平台使这些完全所有者团队的工作更简单,让他们能够提升操作抽象层和更接近业务目标。

容器,尤其是它们的调度器平台的承诺通常是“这是每个人都应该开发软件的方式——它充满魔力”。这通常是真实的容器平台确实使一些非常强大的功能,并且值得认真对待。但请记住,它们都以一种固执己见的方式解决平台产品化问题。如果这些观点也可以是你自己的,那么你就需要合理解释。

原文发布于微信公众号 - 程序你好(codinghello)

原文发表时间:2018-06-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ThoughtWorks

容器化时代对测试的机遇 | TW洞见

今日洞见 文章作者/图片来自ThoughtWorks:梁真,图片来源于网络。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有...

36114
来自专栏SDNLAB

从SDN以及Docker看网络模型发生的变革

编者按:作者从SDN以及Docker所带来的变化出发,分析网络模型发生的变革。Docker以及其相关的应用平台的出现,让人们开始思考,其实网络不仅仅可以是一个单...

3336
来自专栏云计算D1net

成功实施DevOps的七个有力工具

现如今,每个软件企业都在谈论DevOps,他们希望从DevOps中获得好处。DevOps本身不是开发工具,而是开发文化的一次革新,为了能够成功地实施DevOps...

3419
来自专栏大魏分享(微信公众号:david-share)

从2015年服务器操作系统厂商收入排名谈U2L

2015年服务器操作系统收入排名 Garnter在2016年5月20日发布了服务器操作系统收入分析报告。里面包括Linux、UNIX和Windows三大类操作系...

3123
来自专栏SDNLAB

AT&T联合SKT和Intel启动Airship OpenStack项目

2257
来自专栏云计算D1net

主流云技术解读:重点不在开发而在架构

云技术可以使用的语言有java,c++等。云技术的开发,并没有发展什么新语言,而是在其他语言的基础上,比如Java语言。与其他技术,最显著的区别,不是在开发上,...

3307
来自专栏云加头条

云端架构师养成系列之二:云端负载均衡上手与实践

上周四,腾讯云技术社区继续推出了【云端架构师养成】系列分享的第二期:云端负载均衡上手与实践,邀请到的嘉宾是负责该产品的产品经理方坤丁与工程师龚飞斐。 [1496...

4009
来自专栏WeTest质量开放平台团队的专栏

建一座安全的“天空城” :揭秘腾讯 WeTest 如何与祖龙共同挖掘手游安全漏洞

《九州天空城3D》上线至今,长期稳定在 APP Store 畅销排行的前五,本文将介绍腾讯 WeTest 手游安全团队在游戏上线前为《九州天空城3D》挖掘安全漏...

1680
来自专栏云计算D1net

为什么你的私有云可以很像PaaS?

在IT界数年针对私有云架构的优点的不断的争论之后,一个切实可行且企业可用(enterprise-ready)的私有云架构终于来到了我们面前。并且与其它在过去的一...

4344
来自专栏企鹅号快讯

直播、NFC、分包加载……小程序这两次新能力,有哪些开发者们可以玩的东西?

小程序释放的能力一波接一波,对于开发者而言,真的是高潮一波接一波,微信已经越来越像一个移动端的操作系统。 如今,理论上来说,基于微信几乎可以完成所有想完成的开发...

2905

扫码关注云+社区