2018最难招聘的11类IT人员

回复

dataman 发起了问题 • 1 人关注 • 0 个回复 • 185 次浏览 • 2018-03-02 10:41 • 来自相关话题

悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系

dataman 发表了文章 • 0 个评论 • 125 次浏览 • 2018-03-01 10:16 • 来自相关话题

导读:


PaaS发展已经经过几代,经历了从笨重臃肿到轻量,那么基础设施、平台和工作流之间怎样的耦合关系是恰当的?本文还单独拎出其中的Kubernetes,讨论它在整个应用生命周期中,如何实现了如今独一无二的地位。


Datawire团队最近的一次交流,是关于“PaaS”这一术语的真正含义,以及它与开发人员体验(DevEx)和工作流之间的关系,带来了许多可以分享的内部对话。从和客户一起工作,到会议上与人的聊天中,我感觉到,其他团队对于部署应用程序时“平台”和工作流之间的关系也有些不确定,我希望以建设性的方式,能提供一些清晰的认知,或者至少能够学到一些东西。



基础设施、平台、工作流三者缺一不可

Daniel Bryant是一名独立的技术顾问,专注于通过价值流识别、管道的创建和有效的测试策略实施,来实现组织内的持续交付。Daniel的技术专长在于DevOps工具、云/容器平台和微服务实现。他还参与了几个开源项目,为InfoQ、O 'Reilly和Voxxed撰稿,并定期出席OSCON、QCon和JavaOne等国际会议。


从基本原则开始说起,所有基于web的软件开发都涉及到三层:


基础设施:这一层提供原始计算资源的抽象,如裸金属、vm、操作系统、网络、存储等,这些资源最终将负责处理与应用程序相关的代码和数据。这里避免使用“物理”这个术语,因为尽管所有的东西最终都是在硬件上运行的,但是我们越来越多地看到基础设施的抽象转移到软件定义的所有东西(Software-Defined-Everything,SDx)。


平台:这一层提供了粗粒度的系统级构建块,它可能是运行时特定的,比如一个集成的JVM或CLR的计算实例,还有数据存储、中间件、IAM、审计等等。值得一提的是,相信你总是将应用程序部署到某种形式的平台上,即使没有有意识地组装它。


工作流:这一层是如何设计、构建、测试、部署、运营应用程序的总和。每个开发人员都有一个工作流(即使它是隐性的),从个人的独立网站构建者,到一个在复杂的企业系统中工作的数千人团队。

当我和朋友和客户谈论这个模型时,我通常会就概念和结构达成某种形式的协议。当开始讨论这些概念之间的耦合时,特别是与PaaS有关时,分歧就开始了。
 


这些是你正在寻找的平台

我经常听到“PaaS有一个内置的工作流程”,或者“如果你正在运行一个PaaS,那么你不需要知道基础设施。”我并不特别同意这些说法,并且在努力建立共同的理解。PaaS经历了几代模式的发展:


第一代:Heroku和它的朋友们。这种类型的PaaS隐藏了底层云基础设施(通过可部署的slugs和“Dynos”),并提出了非常有见地的工作流程,与平台耦合。对于简单的单体Ruby应用程序,这非常棒,可以在几分钟内熟练部署工作流程,并且所有知识都可以转移到下一个项目复用。


第二代:Cloud Foundry(DEA版)和它的朋友们。这种类型的PaaS可以部署在企业的基础设施上,并且带来企业自己的buildpacks和运行时。工作流仍然集成在一起,但是该平台开始通过上下文路径路由(context path routing )等概念启用多服务应用程序(和工作流程)。


第三代:Cloud Foundry(Diego版)以及当前版本的Google App Engine和AWS Elastic Beanstalk(两者分别从第一代和第二代PaaS演变而来)。这些PaaS对基础架构的依赖更低,企业可以携带自己的容器,并且文档清楚了解运行时和计算环境的限制。这里的工作流程正在转向支持分布式系统(微服务),并鼓励开发人员从目前“推荐的做法”中构建自己的持续交付管道的工作流程,可能使用Concourse或Spinnaker等工具。


第四代:Kubernetes,Docker Swarm,Mesos,HashiCorp Nomad,AWS ECS等等(我明白这些并不是真正的PaaS)。这种类型的平台基础设施是不可知的。谁没有参加过会议并且看到Kubernetes在Raspberry Pi集群上运行?而且总是接触到构成集群的底层计算和网络基础设施(AWS Fargate例外)。也可以部署任何类型的容器或流程。这个平台出现了构建“云原生”应用的愿望,这些应用程序本质上是分布式的。这里的“最佳实践”工作流程尚未定义,或者更准确地说,目前仍与技术协同发展 - 并且我们正在对CI / CD进行最新的了解并改进。


因此,这是一个有趣的开源和商业工具正在出现的领域:想一下Datawire的Forge和Telepresence 工作流工具,Ambassador的交通转移/部署,Weaveworks的Flux和Scope,Heptio和Bitnami的ksonnet,微软的Draft 和 Helm,Containous traefik负载均衡器/ API网关。

我相信平台与工作流程耦合之间产生了混淆,因为很多企业部署了粗粒度(单体?)风格的应用程序,其中工作流与平台紧密结合。即第一代和第二代PaaS,或者工作流松散耦合,但定义明确,我们没有注意到这种摩擦 - 即在传统基础架构或第三代PaaS上构建和部署特定语言的组件。


第四代平台面临挑战,技术仍在成熟,架构及相关组织最佳实践也在共同发展中--分别考虑微服务和无服务器,以及 inverse Conway maneuver。业务对速度,稳定性和可见性的压力也越来越大,这通常是通过将业务流程(形成跨职能业务部门)分解并将决策权下放给一线工作团队来实现的。这以商业运动为代表,例如 holacracies 和 Teal organizations。

回顾上面的软件开发层面,需要指出的一个关键点是,基础设施和平台正在变得越来越分散和分离,但它们是通过集中化的力量实现的 - 例如基础设施中的AWS,以及平台中的Kubernetes(Apps SIG)社区,它定义了常用的协议,标准和接口。工作流程也变得分散,但我认为现在还没有集中的力量,即一种通用的描述性语言,一套工具和预定义(可插入)的工作流程步骤。


构建(Snowflake)定制工作流程
 
随着拥抱Kubernetes的组织越来越多,团队创建定制的开发者体验工作流程,通常在单个组织内的团队中存在差异,导致解决方案很脆弱,以及有限的共享学习。这些团队试图将他们的工作流程编写成最终在Kubernetes之上建立一个平台。部署到平台上至关重要,但平台和工作流的概念应该分开考虑和设计。紧密耦合平台和工作流程会导致不灵活的开发人员工作流程。


相信Kubernetes的“平台”在2018年已经变得越来越清晰。Kubernetes本身已经很好地成熟了,而Envoy,Conduit和Cilium等公司的服务网格正在填补平台的一些缺失的部分。但是,围绕开发人员的体验还有很多想法需要去做。我们看到Weaveworks GitOps和Atlassian BDDA(Build-Diff,Deploy-Apply)等方法论中将最佳实践编纂在内,相信在应用程序开发(AppDev)领域会出现类似的东西。

 

Kubernetes可能会接管应用程序的整个生命周期

今天形成了Kubernetes无处不在的云原生景观。三家主要云提供商,AWS、Google和微软Azure都支持Kubernetes,甚至Docker和Cloud Foundry也在使用它。

是什么使Kubernetes独一无二?传统意义上,通常是开源技术创造了商品化的产品替代主流闭源技术。 但Kubernetes一直是个例外。 “Linux是UNIX的竞争者,Apache web服务器是Apache IIS的竞争对手。那么谁是Kubernetes的竞争对手?并没有与之竞争的闭源产品,”CoreOS首席技术官兼联合创始人Brandon Philips 说。


实质上,Kubernetes在与人们创建的所有脚本进行竞争,以将他们在笔记本电脑上开发的源代码部署到生产环境中。有成千上万的方法可以做到这一点:CI / CD工作流程,bash脚本,配置管理工具等。为了获得生产所需的所有东西,数周的开发一直是个痛苦的周期。这就是Kubernetes来拯救的地方。它通过创建 API 来缩短这个周期,提供了适用于任何类型的一致性和可重复性。

“这是Kubernetes的重点,”Philips表示,“随着时间的推移,我们可能会接管应用程序的整个生命周期,从idea到监控到应用程序工作流程,到最终退出应用程序。我们已经看到用户在扩展Kubernetes api。Philips认为,这将继续,“天空是我们所依赖的抽象的极限。 “看看它在未来几年的发展将会很有趣。”
 

 
原文链接:

1、Kubernetes and PaaS: The Force of DeveloperExperience and Workflow

 https://thenewstack.io/kuberne ... flow/

2、Over Time, Kubernetes May Take Over theEntire Lifecycle of Applications

  https://thenewstack.io/time-ku ... ions/



相关阅读:

号称“天生一对”的容器+微服务,能躲开微服务的悖论陷阱吗?


跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看


看好还是看衰?8位业界大咖这么看Serverless的2018


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
导读:


PaaS发展已经经过几代,经历了从笨重臃肿到轻量,那么基础设施、平台和工作流之间怎样的耦合关系是恰当的?本文还单独拎出其中的Kubernetes,讨论它在整个应用生命周期中,如何实现了如今独一无二的地位。


Datawire团队最近的一次交流,是关于“PaaS”这一术语的真正含义,以及它与开发人员体验(DevEx)和工作流之间的关系,带来了许多可以分享的内部对话。从和客户一起工作,到会议上与人的聊天中,我感觉到,其他团队对于部署应用程序时“平台”和工作流之间的关系也有些不确定,我希望以建设性的方式,能提供一些清晰的认知,或者至少能够学到一些东西。



基础设施、平台、工作流三者缺一不可

Daniel Bryant是一名独立的技术顾问,专注于通过价值流识别、管道的创建和有效的测试策略实施,来实现组织内的持续交付。Daniel的技术专长在于DevOps工具、云/容器平台和微服务实现。他还参与了几个开源项目,为InfoQ、O 'Reilly和Voxxed撰稿,并定期出席OSCON、QCon和JavaOne等国际会议。


从基本原则开始说起,所有基于web的软件开发都涉及到三层:


基础设施:这一层提供原始计算资源的抽象,如裸金属、vm、操作系统、网络、存储等,这些资源最终将负责处理与应用程序相关的代码和数据。这里避免使用“物理”这个术语,因为尽管所有的东西最终都是在硬件上运行的,但是我们越来越多地看到基础设施的抽象转移到软件定义的所有东西(Software-Defined-Everything,SDx)。


平台:这一层提供了粗粒度的系统级构建块,它可能是运行时特定的,比如一个集成的JVM或CLR的计算实例,还有数据存储、中间件、IAM、审计等等。值得一提的是,相信你总是将应用程序部署到某种形式的平台上,即使没有有意识地组装它。


工作流:这一层是如何设计、构建、测试、部署、运营应用程序的总和。每个开发人员都有一个工作流(即使它是隐性的),从个人的独立网站构建者,到一个在复杂的企业系统中工作的数千人团队。

当我和朋友和客户谈论这个模型时,我通常会就概念和结构达成某种形式的协议。当开始讨论这些概念之间的耦合时,特别是与PaaS有关时,分歧就开始了。
 


这些是你正在寻找的平台

我经常听到“PaaS有一个内置的工作流程”,或者“如果你正在运行一个PaaS,那么你不需要知道基础设施。”我并不特别同意这些说法,并且在努力建立共同的理解。PaaS经历了几代模式的发展:


第一代:Heroku和它的朋友们。这种类型的PaaS隐藏了底层云基础设施(通过可部署的slugs和“Dynos”),并提出了非常有见地的工作流程,与平台耦合。对于简单的单体Ruby应用程序,这非常棒,可以在几分钟内熟练部署工作流程,并且所有知识都可以转移到下一个项目复用。


第二代:Cloud Foundry(DEA版)和它的朋友们。这种类型的PaaS可以部署在企业的基础设施上,并且带来企业自己的buildpacks和运行时。工作流仍然集成在一起,但是该平台开始通过上下文路径路由(context path routing )等概念启用多服务应用程序(和工作流程)。


第三代:Cloud Foundry(Diego版)以及当前版本的Google App Engine和AWS Elastic Beanstalk(两者分别从第一代和第二代PaaS演变而来)。这些PaaS对基础架构的依赖更低,企业可以携带自己的容器,并且文档清楚了解运行时和计算环境的限制。这里的工作流程正在转向支持分布式系统(微服务),并鼓励开发人员从目前“推荐的做法”中构建自己的持续交付管道的工作流程,可能使用Concourse或Spinnaker等工具。


第四代:Kubernetes,Docker Swarm,Mesos,HashiCorp Nomad,AWS ECS等等(我明白这些并不是真正的PaaS)。这种类型的平台基础设施是不可知的。谁没有参加过会议并且看到Kubernetes在Raspberry Pi集群上运行?而且总是接触到构成集群的底层计算和网络基础设施(AWS Fargate例外)。也可以部署任何类型的容器或流程。这个平台出现了构建“云原生”应用的愿望,这些应用程序本质上是分布式的。这里的“最佳实践”工作流程尚未定义,或者更准确地说,目前仍与技术协同发展 - 并且我们正在对CI / CD进行最新的了解并改进。


因此,这是一个有趣的开源和商业工具正在出现的领域:想一下Datawire的Forge和Telepresence 工作流工具,Ambassador的交通转移/部署,Weaveworks的Flux和Scope,Heptio和Bitnami的ksonnet,微软的Draft 和 Helm,Containous traefik负载均衡器/ API网关。

我相信平台与工作流程耦合之间产生了混淆,因为很多企业部署了粗粒度(单体?)风格的应用程序,其中工作流与平台紧密结合。即第一代和第二代PaaS,或者工作流松散耦合,但定义明确,我们没有注意到这种摩擦 - 即在传统基础架构或第三代PaaS上构建和部署特定语言的组件。


第四代平台面临挑战,技术仍在成熟,架构及相关组织最佳实践也在共同发展中--分别考虑微服务和无服务器,以及 inverse Conway maneuver。业务对速度,稳定性和可见性的压力也越来越大,这通常是通过将业务流程(形成跨职能业务部门)分解并将决策权下放给一线工作团队来实现的。这以商业运动为代表,例如 holacracies 和 Teal organizations。

回顾上面的软件开发层面,需要指出的一个关键点是,基础设施和平台正在变得越来越分散和分离,但它们是通过集中化的力量实现的 - 例如基础设施中的AWS,以及平台中的Kubernetes(Apps SIG)社区,它定义了常用的协议,标准和接口。工作流程也变得分散,但我认为现在还没有集中的力量,即一种通用的描述性语言,一套工具和预定义(可插入)的工作流程步骤。


构建(Snowflake)定制工作流程
 
随着拥抱Kubernetes的组织越来越多,团队创建定制的开发者体验工作流程,通常在单个组织内的团队中存在差异,导致解决方案很脆弱,以及有限的共享学习。这些团队试图将他们的工作流程编写成最终在Kubernetes之上建立一个平台。部署到平台上至关重要,但平台和工作流的概念应该分开考虑和设计。紧密耦合平台和工作流程会导致不灵活的开发人员工作流程。


相信Kubernetes的“平台”在2018年已经变得越来越清晰。Kubernetes本身已经很好地成熟了,而Envoy,Conduit和Cilium等公司的服务网格正在填补平台的一些缺失的部分。但是,围绕开发人员的体验还有很多想法需要去做。我们看到Weaveworks GitOps和Atlassian BDDA(Build-Diff,Deploy-Apply)等方法论中将最佳实践编纂在内,相信在应用程序开发(AppDev)领域会出现类似的东西。

 

Kubernetes可能会接管应用程序的整个生命周期

今天形成了Kubernetes无处不在的云原生景观。三家主要云提供商,AWS、Google和微软Azure都支持Kubernetes,甚至Docker和Cloud Foundry也在使用它。

是什么使Kubernetes独一无二?传统意义上,通常是开源技术创造了商品化的产品替代主流闭源技术。 但Kubernetes一直是个例外。 “Linux是UNIX的竞争者,Apache web服务器是Apache IIS的竞争对手。那么谁是Kubernetes的竞争对手?并没有与之竞争的闭源产品,”CoreOS首席技术官兼联合创始人Brandon Philips 说。


实质上,Kubernetes在与人们创建的所有脚本进行竞争,以将他们在笔记本电脑上开发的源代码部署到生产环境中。有成千上万的方法可以做到这一点:CI / CD工作流程,bash脚本,配置管理工具等。为了获得生产所需的所有东西,数周的开发一直是个痛苦的周期。这就是Kubernetes来拯救的地方。它通过创建 API 来缩短这个周期,提供了适用于任何类型的一致性和可重复性。

“这是Kubernetes的重点,”Philips表示,“随着时间的推移,我们可能会接管应用程序的整个生命周期,从idea到监控到应用程序工作流程,到最终退出应用程序。我们已经看到用户在扩展Kubernetes api。Philips认为,这将继续,“天空是我们所依赖的抽象的极限。 “看看它在未来几年的发展将会很有趣。”
 

 
原文链接:

1、Kubernetes and PaaS: The Force of DeveloperExperience and Workflow

 https://thenewstack.io/kuberne ... flow/

2、Over Time, Kubernetes May Take Over theEntire Lifecycle of Applications

  https://thenewstack.io/time-ku ... ions/



相关阅读:

号称“天生一对”的容器+微服务,能躲开微服务的悖论陷阱吗?


跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看


看好还是看衰?8位业界大咖这么看Serverless的2018


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

号称“天生一对”的容器+微服务,能躲开微服务的悖论陷阱吗?

dataman 发表了文章 • 0 个评论 • 97 次浏览 • 2018-02-27 10:20 • 来自相关话题

导读:
容器和微服务是不是天生一对?容器化环境是否能更好地实施微服务?本文作者走访了数位亲身实践者,给出了一些进行容器化微服务管理的6大建议。如果您也在评估考虑微服务技术,此文不要错过。
 
 
01微服务的悖论
 
Gianna作为高级软件工程师加入了Avidoo公司,这是一家生产力平台。在与其他团队的会议上,她提出了微服务的问题,以及团队是否开始采用。她立即得到了强烈的反应。
 
拜伦表示:“我们尝试过采用微服务,但是它们不起作用。
 
“这带来了可怕的混乱!”另一位同事补充说。
 
Gianna三次眨巴眼睛,期待着某种阐述,但没有一个往下接着说。
 
Gianna沉默了一会儿,问:“发生了什么事?
 
“起初很棒。每次我们被要求做新的东西时,我们都可以添加一个服务,并使用想要实验的任何语言和框架。
 
我们将REST API 公布在需要与之协作或在其数据库上工作的系统上。但过了一段时间,事情开始越来越频繁地割裂,开发速度放慢了。

Gianna叹了口气。听起来像她的团队一直在建立一个分布式的巨石应用,而他们打算建立的是微服务。

 
分布式巨石应用和其他庞然大物

Gianna所遇到的问题太常见了。微服务是灵丹妙药,IT经理和工程师倾向于区分哪些优势与他们的组织相适应。
 
却忘记了天下没有免费的午餐这件事。除了优势之外,精心打造的微服务架构也有被微辞的一面。没有任何“错误”的微服务,只有微服务不能提供的好处,或者由于它们的缺点而造成的不可接受的风险。
 
使用微服务的优势

选择采用微服务应该首先决定哪种优势适合自身的企业。以下是一些突出的优点:
 
1.增强团队的自主性
许多公司围绕团队成员具备的知识或组件组织团队。在创造真正的客户价值时,这要求团队之间进行大量的协调,不可能同时处理一个特性。







利用单一专业团队创造价值
 
微服务通过cover一个功能来促进自治。因此,一个团队可以完全拥有它,而不需要多个团队一起,这有助于减少跨团队的协调。






利用多学科团队创造价值

 2.更大的容错

团队自治的地方也应该有自治的特点。一个功能通常依赖于另一个。在大多数环境中,通信通过REST接口,按需和pull-based。当这种互动是关键任务时,依靠这种通信的服务要么必须有合理的fall-back,要么就会失败。这种不健康的模式常常被系统运行状况检查所证明,如果系统的一个依赖性不健康,系统运行就会失败。除了导致部署顺序难以管理之外,它还说明了系统依赖性的困难。







运行时依赖关系
 
使用正确的软件架构(如event sourcing),可能补充CQRS,可以完全消除大多数功能之间的运行时依赖。这主要是由于从pull-based系统向push-based系统的转变。
 
3.细粒度的软件生命周期管理
 
开发和业务人员一个共同的愿望是,尽快用新程序替换应用程序中的某个功能。无论是因为要求改变或者重写,又或由于紧张的上市周期需求而导致的技术债务,都使得开发速度落后了。有人可能天真地认为,这些是可以快速被替代的,但其实不然。经常更换功能导致不得不对其所依赖的许多系统进行更改,反之亦然。







缺乏细粒度的软件生命周期管理
 
通过高度调节系统间通信,可以完全切换一个或多个功能,而不必触发任何依赖系统。

 
4.灵活的技术选择

不可否认,这是一个棘手的问题。在需求或个人兴趣的推动下,入职和培训员工切换到通用技术有助于团队间的流动性。但是对于使用不同技术的几个部门的员工,坦白地说,这可能导致大规模的罢工。







迫使技术做出选择
 
只要这些技术可以集成到自动化测试和部署工作流程中,一个团队就可以保持自己的技术选择。为什么要改变一个团结在对C#所有东西都非常热爱的胜利团队呢?只要他们能够产出符合平台监控,日志记录和通信规则的组件。
 
那么为什么他们失败了?
 
因为不知道应该如何去做微服务。采用微服务并不会失败,因为人们不知道如何去做,他们经常不记得首先要解决什么问题。与其他任何决定一样,采用微服务会带来一些成本。软件架构师往往会忘记,他们不应该帮助企业的管理者采用微服务,而应该帮助他们解决真正的业务问题。恰当地衡量这些方面的成本和收益对企业的需求至关重要。
 

02微服务和容器:6大长期管理技巧

部署基于容器的微服务仅仅是个开始,如何有效管理它呢?在我们最近发布的有关微服务和容器入门的文章中,Cloud Technology Partners公司副总裁兼首席云架构师 Mike Kavis分享了一个好消息:“部署容器非常容易。
 
他言简意赅的说:“尽管部署容器很容易,但是要多思考这些系统的运维。”
 
你可以用容器化的微服务深入到生产环境,但大多数专家不会推荐它,特别是如果这是你第一次使用这个强大的技术。
 
基于容器的微服务有相当多的优势:正如红帽技术布道者(Gordon Haff)最近写到的:“即使Match.com(编者注:一家相亲配对网站)也找不到微服务更好的合作伙伴。”但是 IT Heaven所做的大部分工作都需要强大灵活的计划,持续管理企业的容器化微服务架构。你的企业中可能存在一条学习曲线,需要实施智能最佳实践,确保高效运营。
 
SolarWinds公司的负责人Kong Yang说:“第一天之后,所有事情都变得更加复杂。
 
我们询问了Yang、Kavis等人,他们对有效管理容器化微服务的最佳建议。
 
1.保持简单
面对不断增加的复杂性,想要保持高效吗?那就保持简单,愚蠢。这种设计和工程原理,通常被认为是航空和系统工程师Clarence “Kelly” Johnson的指导原则。
 
对于Johnson来说,KISS和管理哲学一样重要,“我们的目标是通过对棘手问题的常识应用来更快更高效地获得结果。
 
对于IT团队来说,这些想法有一个可见的翻译,特别是在微服务和容器方面。
 
“为确保今后的成功运营,让每个微服务做一件事,做得非常好。不要将附加功能扩大到现有的执行良好的微服务里。”
 
2.尽早把管理计划落实到位
微服务和容器可以实现更快,更灵活,更弹性,响应速度更快的软件团队。但首要的事情是,在部署到生产之前制定一个计划。这样一个计划的范例框架如下:
开发部署,安全和运维的最佳实践微服务和容器利用现代化的日志记录和监控解决方案探索容器管理工具(又名编排平台,如Kubernetes),在云端和非云端点上了解自身的环境定期实行post-mortems,不断学习和提高
 
3.选择一个编排平台 

编排工具对于容器化微服务的长期成功至关重要。
 
“每个微服务都需要与管理应用程序共享其状态。这可以决定微服务的生命周期。” ShieldXNetworks 首席技术官 Manuel Nedbal说。“例如,一旦微服务不报告或者正在被超载,就可以用一个新服务替换或者被复制。”
 
4.制定一套最低限度的运营能力

一个容器管理平台不会为你做所有的工作。Retriever Communications首席技术官Nic Grange 说,除了像Kubernetes这样的编排系统之外,还需要确保每个容器化的微服务都遵循“最低限度的运营能力”,以便在这样的环境下运行良好。他提供了以下这些功能的关键示例列表:
编排系统需要能够访问每个微服务上的API,确定它是否准备好接收流量,以及是否健康。需要告知微服务何时正常关闭的方法。需要微服务公开指标和日志记录。在大多数情况下,微服务需要能够水平扩展,并且在某些情况下具备集群意识。
 
Grange也为开发人员分享了一些好消息:特定语言的微服务模板库(如go-kit for Go)和dropwizard for Java,可以节省大量的开发这些最低功能的前期工作。
 
Grange说:“这些让开发人员更容易做正确的事情,获得许多开箱即用的功能,而不必编写更多的代码。
 

5.实施持续集成和持续交付

Sungard Availability Services CTO& 高级架构师 Kevin McGrath 表示,持续集成和持续交付实践对于基于容器的微服务的长期管理是一个巨大的好处,尤其是作为支撑企业编排工具的基础。
 
McGrath说:“如果没有CI / CD,微服务的维护将会因为手动流程而变得不堪重负,无法按预期进行扩展,并且最终将比基础设施和人力资源中的整体应用成本更高。”
 
随着时间的推移,CI / CD将帮助团队释放编排或管理工具的潜力,尤其是在管理如何在主机池中分配CPU,内存和存储时。
 
McGrath解释说:“一旦CI / CD成为产品生命周期一个自然的组成部分,管理系统就非常好,它们处理各种基础架构需求,并将其作为工程师的逻辑配置参数。“对于运维来说,要全面了解主机,容器和服务的资源消耗情况,以便更好地了解需要更多资源的位置。当服务不再与特定的基础设施绑定,而是与基础设施需求相联系时,这一点非常重要。”
 

6.不断重新审视并重新投资业务

容器和微服务不是一劳永逸的技术。DigitalOcean公司的工程经理 Mac Browning 建议说,为了正确使用他们,需要不断在如何运行基于容器的微服务上进行投资。这个建议适用于企业的人员、流程和工具。编排平台是一个好的开始。
 
Browning说:“如果完全投资并使用像Kubernetes这样的编排平台,那就意味着要花时间和资源来跟上项目和更新,并在自己的部署中体现这些变化。“由于企业微服务现在集中运行,这项投资将对所有要运行的服务产生积极影响,而不是一个或两个特定的单一服务。”
 
 
原文链接:1、The Microservices Paradox
https://blog.xebialabs.com/2018/01/30/the-microservices-paradox/2、Microservices and containers: 6management tips for the long haul
https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul 
 
关注数人云了解更多技术信息
推荐阅读
跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看
看好还是看衰?8位业界大咖这么看Serverless的2018
看好还是看衰?8位业界大咖这么看Serverless的2018 查看全部
导读:
容器和微服务是不是天生一对?容器化环境是否能更好地实施微服务?本文作者走访了数位亲身实践者,给出了一些进行容器化微服务管理的6大建议。如果您也在评估考虑微服务技术,此文不要错过。
 
 
01微服务的悖论
 

Gianna作为高级软件工程师加入了Avidoo公司,这是一家生产力平台。在与其他团队的会议上,她提出了微服务的问题,以及团队是否开始采用。她立即得到了强烈的反应。
 
拜伦表示:“我们尝试过采用微服务,但是它们不起作用。
 
“这带来了可怕的混乱!”另一位同事补充说。
 
Gianna三次眨巴眼睛,期待着某种阐述,但没有一个往下接着说。
 
Gianna沉默了一会儿,问:“发生了什么事?
 
“起初很棒。每次我们被要求做新的东西时,我们都可以添加一个服务,并使用想要实验的任何语言和框架。
 
我们将REST API 公布在需要与之协作或在其数据库上工作的系统上。但过了一段时间,事情开始越来越频繁地割裂,开发速度放慢了。

Gianna叹了口气。听起来像她的团队一直在建立一个分布式的巨石应用,而他们打算建立的是微服务。

 
分布式巨石应用和其他庞然大物

Gianna所遇到的问题太常见了。微服务是灵丹妙药,IT经理和工程师倾向于区分哪些优势与他们的组织相适应。
 
却忘记了天下没有免费的午餐这件事。除了优势之外,精心打造的微服务架构也有被微辞的一面。没有任何“错误”的微服务,只有微服务不能提供的好处,或者由于它们的缺点而造成的不可接受的风险。
 
使用微服务的优势

选择采用微服务应该首先决定哪种优势适合自身的企业。以下是一些突出的优点:
 
1.增强团队的自主性
许多公司围绕团队成员具备的知识或组件组织团队。在创造真正的客户价值时,这要求团队之间进行大量的协调,不可能同时处理一个特性。


微信图片_20180227101017.jpg


利用单一专业团队创造价值
 
微服务通过cover一个功能来促进自治。因此,一个团队可以完全拥有它,而不需要多个团队一起,这有助于减少跨团队的协调。

微信图片_20180227101045.jpg


利用多学科团队创造价值

 2.更大的容错

团队自治的地方也应该有自治的特点。一个功能通常依赖于另一个。在大多数环境中,通信通过REST接口,按需和pull-based。当这种互动是关键任务时,依靠这种通信的服务要么必须有合理的fall-back,要么就会失败。这种不健康的模式常常被系统运行状况检查所证明,如果系统的一个依赖性不健康,系统运行就会失败。除了导致部署顺序难以管理之外,它还说明了系统依赖性的困难。


微信图片_20180227101133.jpg


运行时依赖关系
 
使用正确的软件架构(如event sourcing),可能补充CQRS,可以完全消除大多数功能之间的运行时依赖。这主要是由于从pull-based系统向push-based系统的转变。
 
3.细粒度的软件生命周期管理
 
开发和业务人员一个共同的愿望是,尽快用新程序替换应用程序中的某个功能。无论是因为要求改变或者重写,又或由于紧张的上市周期需求而导致的技术债务,都使得开发速度落后了。有人可能天真地认为,这些是可以快速被替代的,但其实不然。经常更换功能导致不得不对其所依赖的许多系统进行更改,反之亦然。


微信图片_20180227100334.jpg


缺乏细粒度的软件生命周期管理
 
通过高度调节系统间通信,可以完全切换一个或多个功能,而不必触发任何依赖系统。

 
4.灵活的技术选择

不可否认,这是一个棘手的问题。在需求或个人兴趣的推动下,入职和培训员工切换到通用技术有助于团队间的流动性。但是对于使用不同技术的几个部门的员工,坦白地说,这可能导致大规模的罢工。


微信图片_20180227101222.jpg


迫使技术做出选择
 
只要这些技术可以集成到自动化测试和部署工作流程中,一个团队就可以保持自己的技术选择。为什么要改变一个团结在对C#所有东西都非常热爱的胜利团队呢?只要他们能够产出符合平台监控,日志记录和通信规则的组件。
 
那么为什么他们失败了?
 
因为不知道应该如何去做微服务。采用微服务并不会失败,因为人们不知道如何去做,他们经常不记得首先要解决什么问题。与其他任何决定一样,采用微服务会带来一些成本。软件架构师往往会忘记,他们不应该帮助企业的管理者采用微服务,而应该帮助他们解决真正的业务问题。恰当地衡量这些方面的成本和收益对企业的需求至关重要。
 

02微服务和容器:6大长期管理技巧

部署基于容器的微服务仅仅是个开始,如何有效管理它呢?在我们最近发布的有关微服务和容器入门的文章中,Cloud Technology Partners公司副总裁兼首席云架构师 Mike Kavis分享了一个好消息:“部署容器非常容易。
 
他言简意赅的说:“尽管部署容器很容易,但是要多思考这些系统的运维。”
 
你可以用容器化的微服务深入到生产环境,但大多数专家不会推荐它,特别是如果这是你第一次使用这个强大的技术。
 
基于容器的微服务有相当多的优势:正如红帽技术布道者(Gordon Haff)最近写到的:“即使Match.com(编者注:一家相亲配对网站)也找不到微服务更好的合作伙伴。”但是 IT Heaven所做的大部分工作都需要强大灵活的计划,持续管理企业的容器化微服务架构。你的企业中可能存在一条学习曲线,需要实施智能最佳实践,确保高效运营。
 
SolarWinds公司的负责人Kong Yang说:“第一天之后,所有事情都变得更加复杂。
 
我们询问了Yang、Kavis等人,他们对有效管理容器化微服务的最佳建议。
 
1.保持简单
面对不断增加的复杂性,想要保持高效吗?那就保持简单,愚蠢。这种设计和工程原理,通常被认为是航空和系统工程师Clarence “Kelly” Johnson的指导原则。
 
对于Johnson来说,KISS和管理哲学一样重要,“我们的目标是通过对棘手问题的常识应用来更快更高效地获得结果。
 
对于IT团队来说,这些想法有一个可见的翻译,特别是在微服务和容器方面。
 
“为确保今后的成功运营,让每个微服务做一件事,做得非常好。不要将附加功能扩大到现有的执行良好的微服务里。”
 
2.尽早把管理计划落实到位
微服务和容器可以实现更快,更灵活,更弹性,响应速度更快的软件团队。但首要的事情是,在部署到生产之前制定一个计划。这样一个计划的范例框架如下:
  • 开发部署,安全和运维的最佳实践
  • 微服务和容器利用现代化的日志记录和监控解决方案
  • 探索容器管理工具(又名编排平台,如Kubernetes),在云端和非云端点上了解自身的环境
  • 定期实行post-mortems,不断学习和提高

 
3.选择一个编排平台 

编排工具对于容器化微服务的长期成功至关重要。
 
“每个微服务都需要与管理应用程序共享其状态。这可以决定微服务的生命周期。” ShieldXNetworks 首席技术官 Manuel Nedbal说。“例如,一旦微服务不报告或者正在被超载,就可以用一个新服务替换或者被复制。”
 
4.制定一套最低限度的运营能力

一个容器管理平台不会为你做所有的工作。Retriever Communications首席技术官Nic Grange 说,除了像Kubernetes这样的编排系统之外,还需要确保每个容器化的微服务都遵循“最低限度的运营能力”,以便在这样的环境下运行良好。他提供了以下这些功能的关键示例列表:
  • 编排系统需要能够访问每个微服务上的API,确定它是否准备好接收流量,以及是否健康。
  • 需要告知微服务何时正常关闭的方法。
  • 需要微服务公开指标和日志记录。
  • 在大多数情况下,微服务需要能够水平扩展,并且在某些情况下具备集群意识。

 
Grange也为开发人员分享了一些好消息:特定语言的微服务模板库(如go-kit for Go)和dropwizard for Java,可以节省大量的开发这些最低功能的前期工作。
 
Grange说:“这些让开发人员更容易做正确的事情,获得许多开箱即用的功能,而不必编写更多的代码。
 

5.实施持续集成和持续交付

Sungard Availability Services CTO& 高级架构师 Kevin McGrath 表示,持续集成和持续交付实践对于基于容器的微服务的长期管理是一个巨大的好处,尤其是作为支撑企业编排工具的基础。
 
McGrath说:“如果没有CI / CD,微服务的维护将会因为手动流程而变得不堪重负,无法按预期进行扩展,并且最终将比基础设施和人力资源中的整体应用成本更高。”
 
随着时间的推移,CI / CD将帮助团队释放编排或管理工具的潜力,尤其是在管理如何在主机池中分配CPU,内存和存储时。
 
McGrath解释说:“一旦CI / CD成为产品生命周期一个自然的组成部分,管理系统就非常好,它们处理各种基础架构需求,并将其作为工程师的逻辑配置参数。“对于运维来说,要全面了解主机,容器和服务的资源消耗情况,以便更好地了解需要更多资源的位置。当服务不再与特定的基础设施绑定,而是与基础设施需求相联系时,这一点非常重要。”
 

6.不断重新审视并重新投资业务

容器和微服务不是一劳永逸的技术。DigitalOcean公司的工程经理 Mac Browning 建议说,为了正确使用他们,需要不断在如何运行基于容器的微服务上进行投资。这个建议适用于企业的人员、流程和工具。编排平台是一个好的开始。
 
Browning说:“如果完全投资并使用像Kubernetes这样的编排平台,那就意味着要花时间和资源来跟上项目和更新,并在自己的部署中体现这些变化。“由于企业微服务现在集中运行,这项投资将对所有要运行的服务产生积极影响,而不是一个或两个特定的单一服务。”
 
 
原文链接:1、The Microservices Paradox
https://blog.xebialabs.com/2018/01/30/the-microservices-paradox/2、Microservices and containers: 6management tips for the long haul
https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul 
 
关注数人云了解更多技术信息
推荐阅读
跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看
看好还是看衰?8位业界大咖这么看Serverless的2018
看好还是看衰?8位业界大咖这么看Serverless的2018

跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看

dataman 发表了文章 • 0 个评论 • 105 次浏览 • 2018-02-24 10:06 • 来自相关话题

 
导读:
热闹的狗年春节正在渐渐走远,春节过去按照惯例  又到了一年跳槽季。究竟什么情况下应该跳?IT又有哪些热门趋势,以及哪些岗位、职业、工作方式正在被冷落?此文可以说是全球顶尖HR智囊团给出的指导建议了。
 
随着技术的成熟、新技术的出现、以及企业通过全职IT员工与合同工相结合来降低成本,我们看到今年的招聘工作出现了一些变化。
 
有些人把零工经济看作一种灵活的新工作方式,一种呼吁独立企业家的方式,另一些则认为这是经济大衰退的普遍后果。无论如何,零工经济正在经历成长的痛苦。根据 Intuit 公司的一份报告,预计到2020年,40%的劳动力将成为其中的一部分。
 
今年有一件事没有改变:对大多数公司来说招聘顶尖人才仍然是困难的,需求大大超过了供给。这影响了我们研究的许多领域,包括薪酬和保有。
 
无论你是想扩充团队还是寻找一份自己的工作,都要读下去,看看哪些招聘方式是热门的,哪些正在落伍。
 
 热门:灵活的工作场所
 
一些专家和研究表明,即使是那些希望全职员工在总部工作的公司,工作场所的灵活性也在上升。
 
华盛顿特区 Phone2Action CEO 杰布·里奥(Jeb Ory)说:“能够在家、咖啡馆、或者更长的假期里挤出一两天工作的情况正在增加。”  “由于技术的流动性,公司需要办公室办公和灵活的远程工作相结合的方式。”
 
Nutanix 全球人才收购总监 Lynette Estrada 说,在科技行业,远程工作是2017年的一个期望。
 
 “我们已经看到,工作场所的灵活性成为科技行业的一个主要趋势,无论是IT行业还是其他所有岗位上,” Estrada 说。在她自己的公司,“公司鼓励员工和他们的经理讨论灵活的工作时间,包括一周内在家工作,或者在有外部承诺的情况下提前离开,”Estrada 说。她说,目标是实现更大的工作与生活的平衡,这可以帮助保持和避免精疲力竭。
 
 冷门:全职远程工作
 
虽然包括在分支办公处工作的工作场所灵活性在上升,但完全远程的情况并不常见。IBM、雅虎、Reddit 和惠普这些引人注目的公司,它们都会将员工拉回办公室,除非某些员工有特殊的工作需要。
 
“当涉及到IT招聘时,我们看到了一个趋势,那就是建立100%的全职员工队伍,” Ory说。“软件公司专注于打造团队,以解决他们所需要的各种技术和产品需求,而建立信任是一个高效团队的关键要素,这种信任来源于日复一日近距离的接触。”
 
很明显,基于办公室的工作方式并不是万能的解决方案。一些公司报告说,使用完全分散的员工提高了生产力。人员流动率、一次性项目和一些特殊的短期需求,继续需要时而在现场、但通常远程工作的供应商,从而迅速采用最优秀的人才。
 
Fuze 公司(基于云的通讯协作制作音频和视频工具的公司)CEO 柯林·多尔蒂(Colin Doherty)说:“这件事需要有一个平衡。”他说:“在传统的办公环境中,领导者通过观察人们的屏幕,以及其他的视觉线索,从而有客观的证据,证明谁参与了谁的工作,谁在什么时候出现。”“对于企业来说,真正的挑战不在于员工是否需要在办公室工作,而是无论在什么地方,如何鼓励员工参与工作。”
 
 热门:混合劳动力/灵活的人员雇佣
 
混合 IT 团队提供了全职员工的标准基线,可以选择在需要时添加或驳回供应商。
 
根据 CompTIA 在2017年发布的 Cyberstates 报告,在不久的将来,全职 IT人员和供应商或临时工的团队会经历数字化转型。报告称:“新元素有望重塑混合劳动力的概念。”“除了通过“gig”平台将不同类型的员工混合在一起之外,融合可能会越来越多地涉及人工智能、机器人、虚拟助手和其他类型的基于知识的系统的使用。”
 
外包软件供应商 SenecaGlobal CEO EdSzofer 说,他看到了更多的混合模式,包括与离岸IT外包团队的混合。“这解决了技术技能短缺的问题,并为企业提供了稳定和灵活的世界级技术人才来源。”
 
 冷门:零工经济大肆炒作
 
 
雇主和求职者都报告说,合同工作市场非常活跃。零工经济正经历一个尴尬的阶段。
 
“零工经济继续破坏传统商业模式的概念和作为整体的行业,” SAP 全球产品管理副总裁黛西·埃尔南德斯(Daisy Hernandez)说。更成熟的大公司正在研究如何从经济转型中获得一些好处,并试验或评估如何将其纳入到新的业务领域。然而,也有一些令人清醒的现实,即零工经济面临的挑战和不足。
 
尽管在招聘、速度和规模方面都有优势,但缺点也显而易见,比如缺乏福利和职业发展,以及其他不太明显的问题。
 
她说:“建立在零工经济模型基础上的公司,还面临不断培训新供应商、安排后勤,在可用性和质量上不一致等挑战。”“关于零工经济是否会接管或适用于各种行业、角色和工作,仍未形成定论。”
 
 热门:软技能
 
根据高管、分析师和招聘人员的说法,应聘者的技术能力在IT行业中占据了主导地位,而软技能的需求则更大。
 
“软技能”是“招聘中最重要的趋势”,SenecaGlobal 的 Szofer 说。“对于计算机专业的毕业生和持有证书的人,专业技能确实是必需的。然而,精明的公司招聘的是必须能够清晰地沟通,仔细倾听,并成为一个强大的团队合作者。
 
约翰•波拉克(John Pollak)是一名安全行业的人力和人才副总裁,他对招聘经理提出了一些建议:“甄别角色和技能,”他说。“在初创公司,每个员工都有巨大的影响力。我们帮助人们建立技能,但性格和态度很难改变。”
 
 冷门 : 你不需要的额外津贴
 
因为公司在招聘和留住顶尖人才方面遇到了困难,一些公司会抛出花哨的福利来美化他们的职位招聘。但这可能无济于事。
 
 “在西雅图和湾区这样的热门科技地区,这种痛苦尤其严重,公司正成为短期思维的牺牲品,”总部位于西雅图的拓展公司 CEO 曼尼•麦地那(Manny Medina)说。“他们通过提供疯狂的套餐来吸引明星队员,但从长远来看,这是危险的。”你会遇到各种各样的问题,随着时间的推移,会导致团队的不满。
 
一些接受本文采访的专家指出,员工想要的是工作的意义,而不是制度化的“乐趣”。“人力资源需要专注于交流的目的,而不仅仅是提供额外的福利。”80%的员工都没有在做理想的工作。
 
 热门:安全领域的工作
 
尽管发生了引人注目的安全攻击事件,许多公司仍然没有做好准备。尽管如此,仍有比安全专家多得多的职位空缺。
 
安全是所有公司最关心的问题。不幸的是,安全人员实在缺乏,所以找到安全人员是一个挑战。
 
TEKsystems 的 Jason Hayman 说,今年他看到了对 Python、Ruby 和 Java 开发人员的需求增加,以及信息安全方面的专业人士。
 
“实时测试新的应用程序,并能够将安全测试集成到流程中,加快了市场的运行速度,” Hayman说,“帮助那些看到更快增长的组织做出反应,并扩大需求。”
 
 冷门:实际的工作保障
 
根据 Payscale 对科技行业薪酬的调查,一些最知名的科技公司任职时间最短,包括Facebook、Uber 和亚马逊,都不到两年。
 
也就是说,他们也可能是最积极的雇佣者,Payscale 注意到,这有助于工作的跃迁,更好的薪水和机会,而不是消耗。
 
但人力资源研究公司 WorkplaceTrends 研究主管丹•施瓦贝尔(Dan Schawbel)表示,在所有行业中,就业机会都略有下降,从4.6年下降到4.2年。“也就是说,如果你开始一份工作,你平均会在那里呆上4年。”22%的员工计划今年换工作。
 
 热门 : 技能更新
 
在员工调查中,求职者报告说,最理想的工作福利之一,是在公司能够追求个人职业发展。
 
Execu 搜索集团的一份报告显示,超过一半的受访者认为,职业发展的机会是他们接受工作的首要原因。近60%的人表示,“获得项目,帮助他们实现技能更新”将有助于留住现有员工。
 
IT服务管理软件制造商 SysAid CEO 萨拉•拉哈夫(Sarah Lahav)表示:“员工们希望感觉到公司正在投资他们,但他们也希望感受到公司在投资他们的未来。” “即使员工离开公司,提供继续教育或专业课程也是非常重要的。”
 
 冷门:从公司外部招聘
 
技能差距的要求不会很快消失,安全和数据科学领域的职位越来越难填补。
 
普华永道的数据显示,对于具有分析能力的角色,雇主通常需要3到5年的工作经验和大学学历。但是,有教育、兴趣和经验的人相对于需求来说是很紧张的,所以想出几个能得到想要的人才的策略是很好的。”
 
Gartner 建议使用黑客马拉松之类的竞赛来发掘人才,并开发现有员工的多样性。
 
Gartner 的一份报告,“多用途列表”相当于一家戏剧公司的多面演员。“他们同时在多个作品中扮演不同的角色,无论是领导角色、配角还是幕后角色,他们都能在每一场演出中发挥出色的表现。”
 
 热门:从硅谷引进人才
 
电视节目对棒球的意义,就是硅谷对于IT行业的意义。但是最近的趋势表明,在全国各地出现的创新和技术中心正在为湾区提供资金。
 
根据 Hired.com 在2017年公布的全球科技薪酬状况,“在调整了旧金山的生活成本之后,像奥斯汀、墨尔本、西雅图和多伦多这样的城市对科技工作者来说是越来越有吸引力的地方。”在奥斯汀,软件工程师的平均年薪是110K美元。但当你考虑到两个城市的生活成本差异时,这就相当于在旧金山赚到80万美元。
 
在奥斯汀这样的地方,钱会走得更远,科技公司也会比加州的公司更愿意引进外地的候选人。总部位于奥斯汀的公司尤其愿意安置合适的人才,60%以上的工作岗位都是提供给奥斯汀以外的人。相比之下,旧金山湾区公司只有30%提供给非本地候选人。
 
 冷门:寻找顶尖人才
 
在全国范围内,科技公司和其他依赖IT人才的行业表示,他们找不到合格的候选人来快速满足他们的需求。“当有需求的求职者进入招聘市场时,他们通常会以闪电般的速度被抢购,” Robert Half 2017 技术薪酬指南报道。“他们想招聘的IT专业人士可能已经在面试其他几家公司了——或者考虑多份报价。”
 
“这是一场人才争夺战,” WorkplaceTrends 的 Schawbel 说,“这是工资上涨和公司留住员工的问题。”“这些混合在一起,就是工资增长的原因。人才缺口正在扩大。60%的企业无法找到有技能的候选人。
 
 热门:基于AI招聘
 
任何求职者,他们会告诉你申请多个职位比以往任何时候都容易。只要点击下,你的简历和工作样本就会被发送出去。但是招聘经理和招聘人员说他们被应用程序淹没了,招聘人员发现很难区分这些数据。

Ory 表示:“以应急为基础的招聘服务数量有明显增长,而且在线服务的爆炸式增长也是就业机会的重要来源。“我们现在看到更多的简历,而且有责任根据实际的工作要求转移到雇主面前对候选人进行审查。”
 
招聘人员正在利用应用算法和机器学习来帮助找到合适的人选。人工智能可以帮助复制成功的职业介绍,绕过那些不适合某些职位的应聘者。
 
除了对优秀的候选人进行培训之外,一个人工智能的招聘人员,可以使用自然语言的理解来回答候选人的问题,为候选人提供更新,甚至安排面试。
 
 冷门:缓慢过时的招聘经验
 
人力资源公司 Robert Half 报告说,有57%的受访者认为求职中最让人沮丧的是,面试后长时间等待回复他们是否得到了这份工作。如果两周后没有回复,大约70%的受访者表示他们对这个职位失去了兴趣。
 
根据这份报告,招聘经理也很痛苦。一个IT技术人员需要大约4周半的时间来填补,超过40%的技术领导说这时间太长了。
 
“他们在求职时暴露在技能测试和评估中技能,比其他任何招聘技术都要多,但这也是他们未来最不愿意看到的技术,”根据 WorkplaceTrends 的未来招聘研究报告。
 
约70%的雇主计划更多地投资于候选人的经验。
 
 热门:增加对人才的补偿
 
根据人力资源管理协会(美国)的数据,今年全国工人的薪酬预计增长3%左右。
 
尽管工资在上涨,但大多数人还是愿意接受新的机会。根据 StackOverflow 的数据,大约75%的开发者都在关注他们的下一份工作。当招聘经理发现很难填补职位空缺时,工资会上升以满足需求。
 
Schawbel说:“从人才的角度来看,目前公司面临的最大挑战是留住人才。”“让人们留下来变得越来越难,所以你必须有一个更有竞争力的薪资,福利待遇也变得更加重要。”
 
 冷门:性别和种族的多样性
 
就工作机会而言,千禧一代有优势也就不足为奇了。那些年龄在25到30岁之间的人获得了最多的工作机会。 45岁以后,平均工资和工作数量都在下降。50岁之后,大多数IT专业人士认为薪水的大幅下降与他们的经验相符。
 
那么性别和种族的多样性呢?
 
根据国家妇女与信息技术中心的数据,女性在技术人员中所占的比例不到三分之一。截至2016年,只有约20%的 CIO 职位由女性担任。
 
这里有一个种族多样性的快照:最近的美国人口普查报告显示,只有7%的 IT人员是非裔美国人,而这一比例是整个劳动力的11%。
 
拉美裔工人占IT劳动力的7%,整体劳动力占总劳动力的16%。亚洲IT工作者的表现更好,约为18%,亚裔总体劳动力比例为6%。大约70%的IT工作者是白人(76%的工人)。
 
“在硅谷,性别多样性、种族多样性和代际冲突都是一个大话题,” Schawbel 说。“我们仍然认为缺乏多样性,尽管证据显示,更多样化的劳动力创造了更多的生产力和创造力。”公司变化非常缓慢。没有公开的证据表明他们对此做了很多。
  查看全部
 
导读:
热闹的狗年春节正在渐渐走远,春节过去按照惯例  又到了一年跳槽季。究竟什么情况下应该跳?IT又有哪些热门趋势,以及哪些岗位、职业、工作方式正在被冷落?此文可以说是全球顶尖HR智囊团给出的指导建议了。
 
随着技术的成熟、新技术的出现、以及企业通过全职IT员工与合同工相结合来降低成本,我们看到今年的招聘工作出现了一些变化。
 
有些人把零工经济看作一种灵活的新工作方式,一种呼吁独立企业家的方式,另一些则认为这是经济大衰退的普遍后果。无论如何,零工经济正在经历成长的痛苦。根据 Intuit 公司的一份报告,预计到2020年,40%的劳动力将成为其中的一部分。
 
今年有一件事没有改变:对大多数公司来说招聘顶尖人才仍然是困难的,需求大大超过了供给。这影响了我们研究的许多领域,包括薪酬和保有。
 
无论你是想扩充团队还是寻找一份自己的工作,都要读下去,看看哪些招聘方式是热门的,哪些正在落伍。
 
 热门:灵活的工作场所
 
一些专家和研究表明,即使是那些希望全职员工在总部工作的公司,工作场所的灵活性也在上升。
 
华盛顿特区 Phone2Action CEO 杰布·里奥(Jeb Ory)说:“能够在家、咖啡馆、或者更长的假期里挤出一两天工作的情况正在增加。”  “由于技术的流动性,公司需要办公室办公和灵活的远程工作相结合的方式。”
 
Nutanix 全球人才收购总监 Lynette Estrada 说,在科技行业,远程工作是2017年的一个期望。
 
 “我们已经看到,工作场所的灵活性成为科技行业的一个主要趋势,无论是IT行业还是其他所有岗位上,” Estrada 说。在她自己的公司,“公司鼓励员工和他们的经理讨论灵活的工作时间,包括一周内在家工作,或者在有外部承诺的情况下提前离开,”Estrada 说。她说,目标是实现更大的工作与生活的平衡,这可以帮助保持和避免精疲力竭。
 
 冷门:全职远程工作
 
虽然包括在分支办公处工作的工作场所灵活性在上升,但完全远程的情况并不常见。IBM、雅虎、Reddit 和惠普这些引人注目的公司,它们都会将员工拉回办公室,除非某些员工有特殊的工作需要。
 
“当涉及到IT招聘时,我们看到了一个趋势,那就是建立100%的全职员工队伍,” Ory说。“软件公司专注于打造团队,以解决他们所需要的各种技术和产品需求,而建立信任是一个高效团队的关键要素,这种信任来源于日复一日近距离的接触。”
 
很明显,基于办公室的工作方式并不是万能的解决方案。一些公司报告说,使用完全分散的员工提高了生产力。人员流动率、一次性项目和一些特殊的短期需求,继续需要时而在现场、但通常远程工作的供应商,从而迅速采用最优秀的人才。
 
Fuze 公司(基于云的通讯协作制作音频和视频工具的公司)CEO 柯林·多尔蒂(Colin Doherty)说:“这件事需要有一个平衡。”他说:“在传统的办公环境中,领导者通过观察人们的屏幕,以及其他的视觉线索,从而有客观的证据,证明谁参与了谁的工作,谁在什么时候出现。”“对于企业来说,真正的挑战不在于员工是否需要在办公室工作,而是无论在什么地方,如何鼓励员工参与工作。”
 
 热门:混合劳动力/灵活的人员雇佣
 
混合 IT 团队提供了全职员工的标准基线,可以选择在需要时添加或驳回供应商。
 
根据 CompTIA 在2017年发布的 Cyberstates 报告,在不久的将来,全职 IT人员和供应商或临时工的团队会经历数字化转型。报告称:“新元素有望重塑混合劳动力的概念。”“除了通过“gig”平台将不同类型的员工混合在一起之外,融合可能会越来越多地涉及人工智能、机器人、虚拟助手和其他类型的基于知识的系统的使用。”
 
外包软件供应商 SenecaGlobal CEO EdSzofer 说,他看到了更多的混合模式,包括与离岸IT外包团队的混合。“这解决了技术技能短缺的问题,并为企业提供了稳定和灵活的世界级技术人才来源。”
 
 冷门:零工经济大肆炒作
 
 
雇主和求职者都报告说,合同工作市场非常活跃。零工经济正经历一个尴尬的阶段。
 
“零工经济继续破坏传统商业模式的概念和作为整体的行业,” SAP 全球产品管理副总裁黛西·埃尔南德斯(Daisy Hernandez)说。更成熟的大公司正在研究如何从经济转型中获得一些好处,并试验或评估如何将其纳入到新的业务领域。然而,也有一些令人清醒的现实,即零工经济面临的挑战和不足。
 
尽管在招聘、速度和规模方面都有优势,但缺点也显而易见,比如缺乏福利和职业发展,以及其他不太明显的问题。
 
她说:“建立在零工经济模型基础上的公司,还面临不断培训新供应商、安排后勤,在可用性和质量上不一致等挑战。”“关于零工经济是否会接管或适用于各种行业、角色和工作,仍未形成定论。”
 
 热门:软技能
 
根据高管、分析师和招聘人员的说法,应聘者的技术能力在IT行业中占据了主导地位,而软技能的需求则更大。
 
“软技能”是“招聘中最重要的趋势”,SenecaGlobal 的 Szofer 说。“对于计算机专业的毕业生和持有证书的人,专业技能确实是必需的。然而,精明的公司招聘的是必须能够清晰地沟通,仔细倾听,并成为一个强大的团队合作者。
 
约翰•波拉克(John Pollak)是一名安全行业的人力和人才副总裁,他对招聘经理提出了一些建议:“甄别角色和技能,”他说。“在初创公司,每个员工都有巨大的影响力。我们帮助人们建立技能,但性格和态度很难改变。”
 
 冷门 : 你不需要的额外津贴
 
因为公司在招聘和留住顶尖人才方面遇到了困难,一些公司会抛出花哨的福利来美化他们的职位招聘。但这可能无济于事。
 
 “在西雅图和湾区这样的热门科技地区,这种痛苦尤其严重,公司正成为短期思维的牺牲品,”总部位于西雅图的拓展公司 CEO 曼尼•麦地那(Manny Medina)说。“他们通过提供疯狂的套餐来吸引明星队员,但从长远来看,这是危险的。”你会遇到各种各样的问题,随着时间的推移,会导致团队的不满。
 
一些接受本文采访的专家指出,员工想要的是工作的意义,而不是制度化的“乐趣”。“人力资源需要专注于交流的目的,而不仅仅是提供额外的福利。”80%的员工都没有在做理想的工作。
 
 热门:安全领域的工作
 
尽管发生了引人注目的安全攻击事件,许多公司仍然没有做好准备。尽管如此,仍有比安全专家多得多的职位空缺。
 
安全是所有公司最关心的问题。不幸的是,安全人员实在缺乏,所以找到安全人员是一个挑战。
 
TEKsystems 的 Jason Hayman 说,今年他看到了对 Python、Ruby 和 Java 开发人员的需求增加,以及信息安全方面的专业人士。
 
“实时测试新的应用程序,并能够将安全测试集成到流程中,加快了市场的运行速度,” Hayman说,“帮助那些看到更快增长的组织做出反应,并扩大需求。”
 
 冷门:实际的工作保障
 
根据 Payscale 对科技行业薪酬的调查,一些最知名的科技公司任职时间最短,包括Facebook、Uber 和亚马逊,都不到两年。
 
也就是说,他们也可能是最积极的雇佣者,Payscale 注意到,这有助于工作的跃迁,更好的薪水和机会,而不是消耗。
 
但人力资源研究公司 WorkplaceTrends 研究主管丹•施瓦贝尔(Dan Schawbel)表示,在所有行业中,就业机会都略有下降,从4.6年下降到4.2年。“也就是说,如果你开始一份工作,你平均会在那里呆上4年。”22%的员工计划今年换工作。
 
 热门 : 技能更新
 
在员工调查中,求职者报告说,最理想的工作福利之一,是在公司能够追求个人职业发展。
 
Execu 搜索集团的一份报告显示,超过一半的受访者认为,职业发展的机会是他们接受工作的首要原因。近60%的人表示,“获得项目,帮助他们实现技能更新”将有助于留住现有员工。
 
IT服务管理软件制造商 SysAid CEO 萨拉•拉哈夫(Sarah Lahav)表示:“员工们希望感觉到公司正在投资他们,但他们也希望感受到公司在投资他们的未来。” “即使员工离开公司,提供继续教育或专业课程也是非常重要的。”
 
 冷门:从公司外部招聘
 
技能差距的要求不会很快消失,安全和数据科学领域的职位越来越难填补。
 
普华永道的数据显示,对于具有分析能力的角色,雇主通常需要3到5年的工作经验和大学学历。但是,有教育、兴趣和经验的人相对于需求来说是很紧张的,所以想出几个能得到想要的人才的策略是很好的。”
 
Gartner 建议使用黑客马拉松之类的竞赛来发掘人才,并开发现有员工的多样性。
 
Gartner 的一份报告,“多用途列表”相当于一家戏剧公司的多面演员。“他们同时在多个作品中扮演不同的角色,无论是领导角色、配角还是幕后角色,他们都能在每一场演出中发挥出色的表现。”
 
 热门:从硅谷引进人才
 
电视节目对棒球的意义,就是硅谷对于IT行业的意义。但是最近的趋势表明,在全国各地出现的创新和技术中心正在为湾区提供资金。
 
根据 Hired.com 在2017年公布的全球科技薪酬状况,“在调整了旧金山的生活成本之后,像奥斯汀、墨尔本、西雅图和多伦多这样的城市对科技工作者来说是越来越有吸引力的地方。”在奥斯汀,软件工程师的平均年薪是110K美元。但当你考虑到两个城市的生活成本差异时,这就相当于在旧金山赚到80万美元。
 
在奥斯汀这样的地方,钱会走得更远,科技公司也会比加州的公司更愿意引进外地的候选人。总部位于奥斯汀的公司尤其愿意安置合适的人才,60%以上的工作岗位都是提供给奥斯汀以外的人。相比之下,旧金山湾区公司只有30%提供给非本地候选人。
 
 冷门:寻找顶尖人才
 
在全国范围内,科技公司和其他依赖IT人才的行业表示,他们找不到合格的候选人来快速满足他们的需求。“当有需求的求职者进入招聘市场时,他们通常会以闪电般的速度被抢购,” Robert Half 2017 技术薪酬指南报道。“他们想招聘的IT专业人士可能已经在面试其他几家公司了——或者考虑多份报价。”
 
“这是一场人才争夺战,” WorkplaceTrends 的 Schawbel 说,“这是工资上涨和公司留住员工的问题。”“这些混合在一起,就是工资增长的原因。人才缺口正在扩大。60%的企业无法找到有技能的候选人。
 
 热门:基于AI招聘
 
任何求职者,他们会告诉你申请多个职位比以往任何时候都容易。只要点击下,你的简历和工作样本就会被发送出去。但是招聘经理和招聘人员说他们被应用程序淹没了,招聘人员发现很难区分这些数据。

Ory 表示:“以应急为基础的招聘服务数量有明显增长,而且在线服务的爆炸式增长也是就业机会的重要来源。“我们现在看到更多的简历,而且有责任根据实际的工作要求转移到雇主面前对候选人进行审查。”
 
招聘人员正在利用应用算法和机器学习来帮助找到合适的人选。人工智能可以帮助复制成功的职业介绍,绕过那些不适合某些职位的应聘者。
 
除了对优秀的候选人进行培训之外,一个人工智能的招聘人员,可以使用自然语言的理解来回答候选人的问题,为候选人提供更新,甚至安排面试。
 
 冷门:缓慢过时的招聘经验
 
人力资源公司 Robert Half 报告说,有57%的受访者认为求职中最让人沮丧的是,面试后长时间等待回复他们是否得到了这份工作。如果两周后没有回复,大约70%的受访者表示他们对这个职位失去了兴趣。
 
根据这份报告,招聘经理也很痛苦。一个IT技术人员需要大约4周半的时间来填补,超过40%的技术领导说这时间太长了。
 
“他们在求职时暴露在技能测试和评估中技能,比其他任何招聘技术都要多,但这也是他们未来最不愿意看到的技术,”根据 WorkplaceTrends 的未来招聘研究报告。
 
约70%的雇主计划更多地投资于候选人的经验。
 
 热门:增加对人才的补偿
 
根据人力资源管理协会(美国)的数据,今年全国工人的薪酬预计增长3%左右。
 
尽管工资在上涨,但大多数人还是愿意接受新的机会。根据 StackOverflow 的数据,大约75%的开发者都在关注他们的下一份工作。当招聘经理发现很难填补职位空缺时,工资会上升以满足需求。
 
Schawbel说:“从人才的角度来看,目前公司面临的最大挑战是留住人才。”“让人们留下来变得越来越难,所以你必须有一个更有竞争力的薪资,福利待遇也变得更加重要。”
 
 冷门:性别和种族的多样性
 
就工作机会而言,千禧一代有优势也就不足为奇了。那些年龄在25到30岁之间的人获得了最多的工作机会。 45岁以后,平均工资和工作数量都在下降。50岁之后,大多数IT专业人士认为薪水的大幅下降与他们的经验相符。
 
那么性别和种族的多样性呢?
 
根据国家妇女与信息技术中心的数据,女性在技术人员中所占的比例不到三分之一。截至2016年,只有约20%的 CIO 职位由女性担任。
 
这里有一个种族多样性的快照:最近的美国人口普查报告显示,只有7%的 IT人员是非裔美国人,而这一比例是整个劳动力的11%。
 
拉美裔工人占IT劳动力的7%,整体劳动力占总劳动力的16%。亚洲IT工作者的表现更好,约为18%,亚裔总体劳动力比例为6%。大约70%的IT工作者是白人(76%的工人)。
 
“在硅谷,性别多样性、种族多样性和代际冲突都是一个大话题,” Schawbel 说。“我们仍然认为缺乏多样性,尽管证据显示,更多样化的劳动力创造了更多的生产力和创造力。”公司变化非常缓慢。没有公开的证据表明他们对此做了很多。
 

看好还是看衰?8位业界大咖这么看Serverless的2018

dataman 发表了文章 • 0 个评论 • 107 次浏览 • 2018-02-23 11:37 • 来自相关话题

导读:

Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖研究了Serverless14个月,优缺全体现!,再比如,容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事。今天这篇主要由8位业内意见领袖谈2018Serverless的去向。
在所谓的无服务器IT系统中,数据工作负载是如何处理的? 

亚马逊的AWS Lambda是无服务器计算最大、最著名的例子,它的未来对很多IT人来说是非常诱人的。Lambda是由 Amazon开发的一个事件驱动的计算平台,当特定事件发生时,它会自动触发或执行代码。Lambda只在需要时执行代码,并自动伸缩,为企业处理一些数据流程和应用程序,提供潜在的成本节约和灵活性。

Amazon 在2014年发布了Lambda,作为企业在云中运行代码的“无服务器”平台,不需要物理服务器,也不需要在企业端提供或管理任何服务器。



1、Serverless无服务器是未来的潮流


在应用程序代码方面,AWS支持Node.js、Java、c#和现在的Python,只要开发人员在其中一种语言中编写代码,代码就可以在Lambda运行环境中运行,并利用Lambda资源。


亚马逊并不是唯一的FaaS供应商,其他还包括谷歌云,微软Azure,IBM OpenWhisk和开源项目Iron.io,以及Webtask。


无服务器的工作负载生产仍然处于初级阶段,但如果IT界的各种预言者都是正确的,那么它将很快在我们眼前成长起来。


以下是一些来自行业专家对serverless未来的展望:>>>>Sumo Logic (相扑逻辑):无服务器计算可能是继容器之后的未来AWS的采用率几乎翻了一番,从2016年的12%上升到2017年的23%。serverless的整个想法是,它通过完全跳过容器和DevOps将微服务转移到未来。事实上,有四分之一的开发人员已经在使用serverless,这对于遵循应用程序架构和采用的人来说是一种强烈的信号。IT领导者已经在谈论DevOps,但是serverless将它带到一个全新的世界“NoOps”——在没有基础设施的情况下,应用程序在云中运行。>>>>Avere Systems技术总监Dan Nydick : 我们将看到更多serverless技术和托管服务企业经常花费大量的时间和精力来管理计算基础设施,这不是他们任务和使命的核心任务。公有云的好处之一是,将应用程序迁移到云上之后,企业不再需要管理这些基础设施。云供应商提供了越来越高水平的管理服务,允许客户专注于自身业务,而不必被虚拟机、web服务器或数据库管理分散注意力。


我们将看到更多使用托管的、可伸缩的web服务(如谷歌 App Engine和AWS Beanstalk)和无服务器技术(如AWS Lambda和谷歌CloudFunctions),作为管理和部署复杂企业应用程序的更经济的方式。


“我们预计云供应商将继续向更高级别的托管服务发展,例如完全分布式数据库管理(谷歌Cloud Spanner),以及第三方出售托管在公有云(Azure Managed Apps)中的应用程序的新能力。”>>>>Atlassian平台负责人Steve Deasy:2018将如何改变软件的构建方式“随着来自主要云供应商的支持,无服务器的框架将会受到欢迎。”此外,数据驱动的应用程序将继续受到欢迎,而对工程师需求的支持也将以工具、基础设施和争论(wrangling)的形式出现。在《Mortal Kombat》中提到,Kubernetes将给现有的平台带来致命的灾难。

 

>>>>Evident.io公司CEO Tim Prendergast和客户解决方案副总裁John Martinez:容器和无服务器计算增加,它们会带来安全问题。


“2018年,公司将采用云计算的方式,传统的基于主机的操作系统将变得无关紧要,或者需要重新设计。”从安全的角度来看,没有人真正准备好保护所有这些容器和功能计算,但是人们还是采用了它。>>>>Contino公司主席Jason McDonald:无服务器采用将继续增加其影响。“Serverless将从云产业的小角落转移到聚光灯下,因为它解决了IT三个关键领域的管理:速度、成本和风险。事实上,亚马逊推出AWS Fargate,这是一种创新,它通过删除服务器,消除运行ECS集群所需的基础设施管理,从而极大地改变了容器的演化。


目前,至少有一家美国主要银行正在运行企业级应用程序,这是一个基于Lambda的专职基础架构,可解决成本和规模问题。未来将会有越来越多类似这样的故事,基于云的堆栈越来越多地迁移到无服务器架构中。



>>>>OVH US公司技术布道者和首席系统工程师 Paul Stephenson: 无服务器计算解决哪些用例将会更清晰。


“这项技术目前非常具有探索性,事件驱动的技术仍在继续。”很高兴看到这一领域发生的一切, 因为IT做的任何事情都可以提高企业业绩表现,同时保持相同或较低的风险状况,这将推动企业进行调研和投资。”>>>>Data Expedition CEO Seth Noble: 2018年,Serverless将与其他技术整合云供应商给客户和第三方留下了许多关键的云迁移元素。这为一些关键领域(如数据输入、数据组织和应用部署)带来了隐形成本。2018年,我们将会看到更多客户要求实际的解决方案,如真正的网络加速,缩小对象存储和文件存储之间的差距,以及更好的工具来集成基于无服务器的应用程序和无服务器服务。
>>>>Platform9 CEO Sirish Raghuram: Kubernetes将会在AWS Lambda无服务器部署中变得更有影响力。Kubernetes不仅可以让云更容易交叉使用,还可以降低云提供的其他高价值应用服务的价值。比如Lambda,用于无服务器计算。有很多开源的替代方案,比如Fission,开源并运行在任何Kubernetes集群上,提供了相同的价值主张。这仅仅是一个例子,说明云提供商自身原生服务的价值可能会发生级联变化,还会发生在Kubernetes生态系统中可用的应用服务范围内。“

 

2、7大提供FaaS的开源无服务器框架

随着虚拟化技术的发展,企业开始意识到物理硬件的利用率越来越高。随着云计算的发展,企业开始逐渐将虚拟机用于即付即用的服务中,AWS在2014年推出了Lambda服务,引入了云计算的新范例,如今已经成为通常所说的无服务器计算。在无服务器模式中,企业将功能作为服务付费,而不需要为永远在线的状态虚拟机付费。AWS lambda开创了serverless,现在有多个开源项目构建可用于多重部署的无服务器框架:

1.Apache Openwhisk

IBM启动了apache openwhisk项目,现在它是IBMCloud Functions服务的基础。


2.Fission uses kubernetes for serverless

由云服务供应商Platform9领导的开源Fission项目是一个基于Kubernetes的无服务器框架。”Fission是开放源代码项目,旨在成为lambda事实上的开源替代品,”Madhura Maskasky,PLatform9的联合创始人,在2017年1月采访时对eWEEK说。


3.IronFunctions

IronFunctions是一种以Go语言编写的FaaS平台。功能是任何云计算,包括公有云、私有云和混合云提供开源无服务器计算平台。


4.Fn project backed by Oracle

2017年10月甲骨文公司宣布开源Fn项目,为apache许可的无服务器项目。


5.OpenFaas

OpenFaas 是一种能够使docker或者kubernetes都变成无服务器的开源项目,是一种FaaS框架。


6.Kubeless

开源框架Kubeless是由2017年3月被Bitnami收购的软件供应商Skippbox开发的。

kubeless是一个kubernetes本地无服务器框架,具有符合AWS Lambda CLI的命令行界面(CLI)


7.Riff

在最新的开源无服务器框架中,Riff项目得到了关键支持,并且是即将到来的Pivotal Function Service(PFS)的基础。
 
 
 
>>>>调查显示企业不断从私有云转向公有云

一项对300名IT专业人员的调查显示,公有云系统将继续快速增长,因为企业将把他们的本地数据中心资产转移到云平台。

Serverless这种新兴的云计算服务交付模式为开发人员和管理人员带了很多好处。它提供了合适的灵活性和控制性级别。Serverless架构正在彻底改变软件开发和部署流程。



原文链接:

1、Predictions 2018: Why Serverless Processing May Be Wave of the Future

http://www.eweek.com/innovatio ... uture

2、7 Open-Source Serverless Frameworks Providing Functions as a Service

http://www.eweek.com/cloud/7-open-source-serverless-frameworks-providing-functions-as-a-service
 
 
  查看全部
导读:

Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖研究了Serverless14个月,优缺全体现!,再比如,容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事。今天这篇主要由8位业内意见领袖谈2018Serverless的去向。
在所谓的无服务器IT系统中,数据工作负载是如何处理的? 

亚马逊的AWS Lambda是无服务器计算最大、最著名的例子,它的未来对很多IT人来说是非常诱人的。Lambda是由 Amazon开发的一个事件驱动的计算平台,当特定事件发生时,它会自动触发或执行代码。Lambda只在需要时执行代码,并自动伸缩,为企业处理一些数据流程和应用程序,提供潜在的成本节约和灵活性。

Amazon 在2014年发布了Lambda,作为企业在云中运行代码的“无服务器”平台,不需要物理服务器,也不需要在企业端提供或管理任何服务器。



1、Serverless无服务器是未来的潮流


在应用程序代码方面,AWS支持Node.js、Java、c#和现在的Python,只要开发人员在其中一种语言中编写代码,代码就可以在Lambda运行环境中运行,并利用Lambda资源。


亚马逊并不是唯一的FaaS供应商,其他还包括谷歌云,微软Azure,IBM OpenWhisk和开源项目Iron.io,以及Webtask。


无服务器的工作负载生产仍然处于初级阶段,但如果IT界的各种预言者都是正确的,那么它将很快在我们眼前成长起来。


以下是一些来自行业专家对serverless未来的展望:>>>>Sumo Logic (相扑逻辑):无服务器计算可能是继容器之后的未来AWS的采用率几乎翻了一番,从2016年的12%上升到2017年的23%。serverless的整个想法是,它通过完全跳过容器和DevOps将微服务转移到未来。事实上,有四分之一的开发人员已经在使用serverless,这对于遵循应用程序架构和采用的人来说是一种强烈的信号。IT领导者已经在谈论DevOps,但是serverless将它带到一个全新的世界“NoOps”——在没有基础设施的情况下,应用程序在云中运行。>>>>Avere Systems技术总监Dan Nydick : 我们将看到更多serverless技术和托管服务企业经常花费大量的时间和精力来管理计算基础设施,这不是他们任务和使命的核心任务。公有云的好处之一是,将应用程序迁移到云上之后,企业不再需要管理这些基础设施。云供应商提供了越来越高水平的管理服务,允许客户专注于自身业务,而不必被虚拟机、web服务器或数据库管理分散注意力。


我们将看到更多使用托管的、可伸缩的web服务(如谷歌 App Engine和AWS Beanstalk)和无服务器技术(如AWS Lambda和谷歌CloudFunctions),作为管理和部署复杂企业应用程序的更经济的方式。


“我们预计云供应商将继续向更高级别的托管服务发展,例如完全分布式数据库管理(谷歌Cloud Spanner),以及第三方出售托管在公有云(Azure Managed Apps)中的应用程序的新能力。”>>>>Atlassian平台负责人Steve Deasy:2018将如何改变软件的构建方式“随着来自主要云供应商的支持,无服务器的框架将会受到欢迎。”此外,数据驱动的应用程序将继续受到欢迎,而对工程师需求的支持也将以工具、基础设施和争论(wrangling)的形式出现。在《Mortal Kombat》中提到,Kubernetes将给现有的平台带来致命的灾难。

 

>>>>Evident.io公司CEO Tim Prendergast和客户解决方案副总裁John Martinez:容器和无服务器计算增加,它们会带来安全问题。


“2018年,公司将采用云计算的方式,传统的基于主机的操作系统将变得无关紧要,或者需要重新设计。”从安全的角度来看,没有人真正准备好保护所有这些容器和功能计算,但是人们还是采用了它。>>>>Contino公司主席Jason McDonald:无服务器采用将继续增加其影响。“Serverless将从云产业的小角落转移到聚光灯下,因为它解决了IT三个关键领域的管理:速度、成本和风险。事实上,亚马逊推出AWS Fargate,这是一种创新,它通过删除服务器,消除运行ECS集群所需的基础设施管理,从而极大地改变了容器的演化。


目前,至少有一家美国主要银行正在运行企业级应用程序,这是一个基于Lambda的专职基础架构,可解决成本和规模问题。未来将会有越来越多类似这样的故事,基于云的堆栈越来越多地迁移到无服务器架构中。



>>>>OVH US公司技术布道者和首席系统工程师 Paul Stephenson: 无服务器计算解决哪些用例将会更清晰。


“这项技术目前非常具有探索性,事件驱动的技术仍在继续。”很高兴看到这一领域发生的一切, 因为IT做的任何事情都可以提高企业业绩表现,同时保持相同或较低的风险状况,这将推动企业进行调研和投资。”>>>>Data Expedition CEO Seth Noble: 2018年,Serverless将与其他技术整合云供应商给客户和第三方留下了许多关键的云迁移元素。这为一些关键领域(如数据输入、数据组织和应用部署)带来了隐形成本。2018年,我们将会看到更多客户要求实际的解决方案,如真正的网络加速,缩小对象存储和文件存储之间的差距,以及更好的工具来集成基于无服务器的应用程序和无服务器服务。
>>>>Platform9 CEO Sirish Raghuram: Kubernetes将会在AWS Lambda无服务器部署中变得更有影响力。Kubernetes不仅可以让云更容易交叉使用,还可以降低云提供的其他高价值应用服务的价值。比如Lambda,用于无服务器计算。有很多开源的替代方案,比如Fission,开源并运行在任何Kubernetes集群上,提供了相同的价值主张。这仅仅是一个例子,说明云提供商自身原生服务的价值可能会发生级联变化,还会发生在Kubernetes生态系统中可用的应用服务范围内。“

 

2、7大提供FaaS的开源无服务器框架

随着虚拟化技术的发展,企业开始意识到物理硬件的利用率越来越高。随着云计算的发展,企业开始逐渐将虚拟机用于即付即用的服务中,AWS在2014年推出了Lambda服务,引入了云计算的新范例,如今已经成为通常所说的无服务器计算。在无服务器模式中,企业将功能作为服务付费,而不需要为永远在线的状态虚拟机付费。AWS lambda开创了serverless,现在有多个开源项目构建可用于多重部署的无服务器框架:

1.Apache Openwhisk

IBM启动了apache openwhisk项目,现在它是IBMCloud Functions服务的基础。


2.Fission uses kubernetes for serverless

由云服务供应商Platform9领导的开源Fission项目是一个基于Kubernetes的无服务器框架。”Fission是开放源代码项目,旨在成为lambda事实上的开源替代品,”Madhura Maskasky,PLatform9的联合创始人,在2017年1月采访时对eWEEK说。


3.IronFunctions

IronFunctions是一种以Go语言编写的FaaS平台。功能是任何云计算,包括公有云、私有云和混合云提供开源无服务器计算平台。


4.Fn project backed by Oracle

2017年10月甲骨文公司宣布开源Fn项目,为apache许可的无服务器项目。


5.OpenFaas

OpenFaas 是一种能够使docker或者kubernetes都变成无服务器的开源项目,是一种FaaS框架。


6.Kubeless

开源框架Kubeless是由2017年3月被Bitnami收购的软件供应商Skippbox开发的。

kubeless是一个kubernetes本地无服务器框架,具有符合AWS Lambda CLI的命令行界面(CLI)


7.Riff

在最新的开源无服务器框架中,Riff项目得到了关键支持,并且是即将到来的Pivotal Function Service(PFS)的基础。
 
 
 
>>>>调查显示企业不断从私有云转向公有云

一项对300名IT专业人员的调查显示,公有云系统将继续快速增长,因为企业将把他们的本地数据中心资产转移到云平台。

Serverless这种新兴的云计算服务交付模式为开发人员和管理人员带了很多好处。它提供了合适的灵活性和控制性级别。Serverless架构正在彻底改变软件开发和部署流程。



原文链接:

1、Predictions 2018: Why Serverless Processing May Be Wave of the Future

http://www.eweek.com/innovatio ... uture

2、7 Open-Source Serverless Frameworks Providing Functions as a Service

http://www.eweek.com/cloud/7-open-source-serverless-frameworks-providing-functions-as-a-service
 
 
 

25篇技术干货说尽微服务、Service Mesh、容器、DevOps | Meetup年度实录集

dataman 发表了文章 • 0 个评论 • 244 次浏览 • 2018-02-09 11:03 • 来自相关话题

导读:

小数为大家汇总了数人云2017年举办的十几场技术meetup上的演讲实录。这些实录有关微服务、服务网格Service Mesh、DevOps、云原生、Kubernetes、SRE以及容器等等,分享嘉宾都是前沿技术公司技术专家和大咖,以及传统企业和互联网企业的落地实践。满满的干货,值得温习一遍又一遍!
 
 
 
1

Cloud Native架构下的K8S和微服务实践
 
时间:2018年1月27日,地点:深圳

PPT | 从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?


2

服务网格:ServiceMesh is Coming
 
时间:2017年12月16日,地点:北京

ServiceMesh谁主沉浮?数人云资深架构师最新解读

WeiboMesh服务化实践如何应对明星劈腿的顶级流量?
 
3

论道云原生和微服务,剑指何方?
 
时间:2017年11月4日,地点:北京

5位大咖同台论道,中西方微服务有何异同?
 
 
4

将微服务进行到底
 
时间:2017年9月23日,地点:北京

90%产品服务化,细说豆瓣的5年变革之路
 
 
5

K8S GeekGathering 2017 上海站
 
时间:2017年9月10日 地点:上海

数人云架构师:微服务体系中的K8S&Mesos调度与服务发现
 
 
6

K8S、Mesos还不够? 8月19日更多Container+技术
 
时间:2017年8月19日  地点:北京

微软AzureContainer Service的容器化应用

当K8S遇上微服务-京东金融PaaS平台思考与实践
 
7

DevOps&SRE 超越传统运维之道上海站
 
时间:2017年7月15日 地点:上海

有心了,他写了一份DevOps&SRE参会笔记分享给你 | 附PPT下载

SRE遇上金融老干部,解决发布协调&监控告警两大难题
 
 
8

DevOps&SRE 超越传统运维之道深圳站
 
时间:2017年5月6日  地点:深圳

数人云王璞:《SRE在传统企业中的落地实践》

腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》
 
 
9

大牛的成长轨迹之架构&运维
 
时间:2017年4月15日  地点:北京

当当架构部张亮:从码农到大牛,技术与心境的双重提升
 
 
10

当西方的SRE遇上东方的互联网
 
时间:2017年3月4日  地点:北京

活学活用SRE,美团点评,前Google SRE线下分享视频

活学活用SRE,数人云,某金融线下分享视频
 
 
11

告别人肉运维
 
时间: 2017年2月25日  地点:上海

告别人肉运维,饿了么和数人云的经验都在这里了

拒绝删库到跑路,探究饿了么数据安全保障体系

DesignFor Failure——饿了么技术运营实践
 
 
12

容器之Mesos/K8S/Swarm三国演义深圳站
 
时间:2017年1月7日,地点:深圳

Kubernetes在腾讯游戏的应用实践

实录分享 | Mesos PMC带你回顾Mesos 2016

广发银行运维实践分享:Docker适配传统运维那些事
 
13

容器之Mesos/K8S/Swarm三国演义上海站
 
时间:2017年1月7日,地点:上海

.Net大户的选择:Windows Container在携程的应用

构建与定制:唯品会PaaS基于Kubernetes的实践

Docker在Bilibili的实战:由痛点推动的容器化



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
导读:

小数为大家汇总了数人云2017年举办的十几场技术meetup上的演讲实录。这些实录有关微服务、服务网格Service Mesh、DevOps、云原生、Kubernetes、SRE以及容器等等,分享嘉宾都是前沿技术公司技术专家和大咖,以及传统企业和互联网企业的落地实践。满满的干货,值得温习一遍又一遍!
 
 
 
1

Cloud Native架构下的K8S和微服务实践
 
时间:2018年1月27日,地点:深圳

PPT | 从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?


2

服务网格:ServiceMesh is Coming
 
时间:2017年12月16日,地点:北京

ServiceMesh谁主沉浮?数人云资深架构师最新解读

WeiboMesh服务化实践如何应对明星劈腿的顶级流量?
 
3

论道云原生和微服务,剑指何方?
 
时间:2017年11月4日,地点:北京

5位大咖同台论道,中西方微服务有何异同?
 
 
4

将微服务进行到底
 
时间:2017年9月23日,地点:北京

90%产品服务化,细说豆瓣的5年变革之路
 
 
5

K8S GeekGathering 2017 上海站
 
时间:2017年9月10日 地点:上海

数人云架构师:微服务体系中的K8S&Mesos调度与服务发现
 
 
6

K8S、Mesos还不够? 8月19日更多Container+技术
 
时间:2017年8月19日  地点:北京

微软AzureContainer Service的容器化应用

当K8S遇上微服务-京东金融PaaS平台思考与实践
 
7

DevOps&SRE 超越传统运维之道上海站
 
时间:2017年7月15日 地点:上海

有心了,他写了一份DevOps&SRE参会笔记分享给你 | 附PPT下载

SRE遇上金融老干部,解决发布协调&监控告警两大难题
 
 
8

DevOps&SRE 超越传统运维之道深圳站
 
时间:2017年5月6日  地点:深圳

数人云王璞:《SRE在传统企业中的落地实践》

腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》
 
 
9

大牛的成长轨迹之架构&运维
 
时间:2017年4月15日  地点:北京

当当架构部张亮:从码农到大牛,技术与心境的双重提升
 
 
10

当西方的SRE遇上东方的互联网
 
时间:2017年3月4日  地点:北京

活学活用SRE,美团点评,前Google SRE线下分享视频

活学活用SRE,数人云,某金融线下分享视频
 
 
11

告别人肉运维
 
时间: 2017年2月25日  地点:上海

告别人肉运维,饿了么和数人云的经验都在这里了

拒绝删库到跑路,探究饿了么数据安全保障体系

DesignFor Failure——饿了么技术运营实践
 
 
12

容器之Mesos/K8S/Swarm三国演义深圳站
 
时间:2017年1月7日,地点:深圳

Kubernetes在腾讯游戏的应用实践

实录分享 | Mesos PMC带你回顾Mesos 2016

广发银行运维实践分享:Docker适配传统运维那些事
 
13

容器之Mesos/K8S/Swarm三国演义上海站
 
时间:2017年1月7日,地点:上海

.Net大户的选择:Windows Container在携程的应用

构建与定制:唯品会PaaS基于Kubernetes的实践

Docker在Bilibili的实战:由痛点推动的容器化



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

4大维度3大预测,基于容器生态扩张的DevSecOps为啥引关注?

dataman 发表了文章 • 0 个评论 • 116 次浏览 • 2018-02-08 10:22 • 来自相关话题

 





DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。
 
像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒作和盗用。但是这个术语对拥抱DevOps文化的IT领导者以及实现其承诺的实践和工具而言,具有真正的意义。
 

 DevSecOps什么意思?
 
Datic公司首席技术官兼共同创始人RobertReeves说:“DevSecOps是开发,安全和运维的组合。它提醒我们,对于应用程序来说,安全和创建、部署到生产上同样重要。”
 
向非技术人员解释DevSecOps的一个简单方法:它有意识地更早地将安全性融入到开发过程中。
 
红帽安全战略家Kirsten Newcomer 最近告诉我们: “历史上,安全团队从开发团队中分离出来,每个团队都在不同的IT领域拥有深厚的专业知识  。“其实不需要这样。关心安全的企业也非常关心通过软件快速交付业务价值的能力,这些企业正在寻找方法,将安全性留在应用开发生命周期内。通过在整个CI / CD中集成安全实践,工具和自动化来采用DevSecOps。”
 
她说:“为了做到这一点,他们正在整合团队。安全专业人员将从应用开发团队一直嵌入到生产部署中。” “双方都看到了价值,每个团队都拓展了他们的技能和知识基础,成为更有价值的技术专家。正确的DevOps或DevSecOps ,提高IT安全性。”
 
IT团队的任务是更快,更频繁地交付服务。DevOps成为一个很好的推动因素,部分原因是它可以消除开发和运营团队之间的一些传统冲突,Ops通常在部署之前被排除在外,而Dev将其代码丢在无形的墙上,从来不进行二次管理,更没有任何的基础设施维护责任。说得委婉一些,在数字化时代,这种孤立的做法会产生问题。按照Reeves的说法,如果安全是孤立的,也会存在类似的问题。
 
Reeves说:“我们采用DevOps,它被证明可以通过扫除开发与运维之间的障碍来提高IT的性能。“就像不应该等到部署周期结束才开始运维一样,也不应该等到最后才考虑安全问题。”
 

 DevSecOps为什么会出现?
 
将DevSecOps看作是另一个流行语是一种诱惑,但对于安全意识强的IT领导者来说,这是一个实质性的概念。安全必须是软件开发流程中的“一等公民”,而并非最终步骤部署,或者更糟糕,只有在发生实际的安全事件后才受到重视。
SumoLogic公司安全与合规副总裁George Gerchow表示:“DevSecOps不仅仅是一个流行词,由于诸多原因它是IT的当前和未来状态。“最重要的好处是能够将安全性融入到开发和运营流程中,为实现敏捷性和创新提供保障。”
 
此外,在场景中出现的DevSecOps可能是DevOps自身正在成熟并深入挖掘IT内部的另一个标志。
 
“企业DevOps文化意味着开发人员能够以更快的速度向生产环境提供功能和更新,特别是当自组织团队更加乐于协作和衡量结果。”CYBRIC首席技术官兼联合创始人Mike Kail说。
 
在采用DevOps的同时,保持原有的安全实践的团队和公司会遇到更多的管理安全风险的痛苦,因为DevOps团队会部署地更快、更频繁。
 

 手动测试安全方法逐渐落后

 “目前,手动测试安全方法逐渐落后,利用自动化和协作将安全测试转移到软件开发生命周期,从而推动DevSecOps文化,这是IT领导者提高整体弹性和交付安全保证的唯一路径。”凯尔说。
 
(早期)对安全性测试的改变也让开发人员受益:在开发新服务或部署更新服务之前,他们并没有发现代码中的明显漏洞,而是经常在开发的早期阶段发现并解决潜在的问题,几乎没有安全人员的介入。
 
SAS首席信息安全官Brian Wilson表示:“正确的做法是,DevSecOps可以将安全性纳入开发生命周期,使开发人员能够更快,更方便地保护应用程序,不会造成安全干扰。
 
Wilson将静态(SAST)和源代码分析(SCA)工具集成到团队的持续交付中,帮助开发人员在代码中对潜在问题,以及第三方依赖的漏洞进行反馈。
 
Wilson说:“开发人员可以主动、反复地缓解app的安全问题,并重新进行安全扫描,无需安全人员参与。DevSecOps还可以帮助开发团队简化更新和修补程序。
 
DevSecOps并不意味着企业不再需要安全专家,就像DevOps并不意味着企业不再需要基础架构专家一样。它只是有助于减少瑕疵进入生产的可能性,或减缓部署。
 

 DevSecOps遭遇的危机
 
来自Sumo Logic公司的Gerchow分享了DevSecOps文化的实例:当最近的Meltdown和Spectre消息出现时,团队的DevSecOps方法能够迅速做出响应,以减轻风险,而对内外部客户没有任何明显的干扰。 对云原生和受高度监管的公司来说非常重要。
 
第一步,Gerchow的小型安全团队(具备开发技能)能够通过Slack与其主要云供应商之一合作,确保基础设施在24小时内完全修补好。
 
 “然后,我的团队立即开始了OS级别的修复,不需要给终端用户停机时间,也无需请求工程师,那样意味着要等待长时间的变更管理流程。所有这些变化都是通过Slack打开自动化Jira tickets进行的,并通过日志和分析解决方案进行监控,“Gerchow解释说。
 
这听起来像DevOps文化,正确的人员、流程和工具组合相匹配,但它明确地将安全作为该文化和组合的一部分。
 
Gerchow说:“在传统环境下,停机需要花费数周或数月的时间,因为开发、运营和安全这三项功能都是孤立的。凭借DevSecOps流程和理念,终端用户可以通过简单的沟通和当天的修复获得无缝的体验。”
 
 
02
2018DevSecOps三大预测
 
2018年企业的DevSecOps将迎来一些真正的变革。
 
对于DevSecOps来说,2017年是美好的一年,DevSecOps从一个半朦胧的概念演变成可行的企业功能。
 
容器和容器市场的迅速扩张在很大程度上推动了这一演变,容器市场本质上与DevOps和DevSecOps相互交织在一起。一般来说,快速增长和创新往往比科学更能预测趋势,但我仍然愿意尝试一下。
 
从Docker Hub和成熟的容器生态系统中获取了超过120亿张图片,就企业的DevSecOps而言,我们几乎看不到冰山的一角。不过,相信在2018年,我们将看到:基础变革的开始。我认为它会是这样的:
 

 >>>>1.企业领导者和IT利益相关者意识到DevSecOps正在改进DevOps
 
DevOps将开发团队和运维团队聚在一起,它推动协作文化不足为奇。加入安全举措可能听起来很简单,但多年来,安全问题一直是事后的事情,导致企业文化容易使安全团队与其他IT团队形成对立,包括开发团队。 
但是事情发生了变化。
在雅虎亏损3.5亿美元的商业环境下,暴露了其脆弱的安全状况,企业领导者将网络安全看作是一个运维sinkhole的时代已经结束。加强网络安全现在是企业的当务之急。但这种转变需要时间才能重新回到IT文化中。
DevOps和DevSecOps的崛起无疑为重塑应用程序安全性创造了一个难得且令人兴奋的机会,但是DevOps可能会导致转变速度发生变化。DevOps团队和应用程序架构师每天都能够认识到安全的重要性,并欢迎安全团队的加入,但他们之间仍然存在需要磨合的鸿沟。
为正确实施DevSecOps,安全团队需要与DevOps团队保持一致,企业领导者需要为此打造空间和预算。到2019年,希望企业领导人能够意识到推动一个重要的、合法的安全胜利的机会。
 

>>>>2.成功的组织模式将会出现,最可能的是,安全与DevOps团队之间的紧密协作。

虽然该预测并不特别具有启发性,但是相关的。了解DevSecOps需要来自安全和DevOps团队的平等协作,快速跟踪标准蓝图或实施模型,将DevSecOps集成(并最终自动化)到CI / CD进程中。
虽然不同企业有不同的需求,但大多数公司都使用相同的技术工具,特别是在使用容器的情况下。这就为统一的标准化提供了条件。此外,容器的开源特性可以促进相关信息的共享和标准开发。
到目前为止,由于DevOps团队拥有开发流程,他们一直在安全方面处于领先地位。然而,我认为,DevSecOps需要由安全团队领导, 他们是负责企业安全和风险的人,当安全事故发生时,他们会被解雇或被迫离开。
2018年,安全团队需要加强并展示团队的价值和技能。将安全性融入到IT结构中,而不是在网络安全问题成为事实之后才想起。现在我们有机会来实现这一目标。
 

>>>>3.安全团队仍然要缓慢适应DevOps的现实

过去,企业安全团队通常在不重视或不了解安全需要的文化中运营。难怪今天的电商环境是大多数企业相对容易被破坏的环境。 
强大的安全性不仅仅是外围的防火墙。尽管许多安全专家可能最终会看到这种转变,但可能不像DevOps团队所期望的那样灵活。当谈到容器(通常是appsec)时,即使是最有才华和最优秀的安全专家也会面临学习的瓶颈。更不用说已经被充分证明的网络安全技能短缺的现状。
虽然这些因素可能在短期内降低安全对DevOps和 DevSecOps的支持,但是我认为DevSecOps是解决技能短缺问题的一部分。将安全集成到应用程序交付过程中,并将其自动化比用回溯方法更有效率和更具成本效益,可以解决在部署应用程序之前解决安全漏洞。安全专业人士可以通过开放的态度,以新的方式发挥他们的才能,从而获得很多收益。 
2018年希望这个故事有一个快乐的结局。
 

原文链接:
1、3 predictions for devsecops in 2018https://www.infoworld.com/article/3243155/devops/3-predictions-for-devsecops-in-2018.html2、   Why DevSecOps matters to IT leadershttps://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders
 
 
 
推荐阅读:
企业级落地容器与DevOps,选用K8S都有哪些“姿势”
7大ChatOps&5种团队协作工具助力DevOps实践
如果没按这7种习惯,你可能实践的是假DevOps
这款分布式配置中心,会是微服务的降维打击利器吗?
从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
 
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群
 
点击数人云了解更多信息 查看全部
 
v2-174b0611f0cdb3c1c3ac4bd4db13a3d3_hd.jpg


DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。
 
像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒作和盗用。但是这个术语对拥抱DevOps文化的IT领导者以及实现其承诺的实践和工具而言,具有真正的意义。
 

 DevSecOps什么意思?
 
Datic公司首席技术官兼共同创始人RobertReeves说:“DevSecOps是开发,安全和运维的组合。它提醒我们,对于应用程序来说,安全和创建、部署到生产上同样重要。”
 
向非技术人员解释DevSecOps的一个简单方法:它有意识地更早地将安全性融入到开发过程中。
 
红帽安全战略家Kirsten Newcomer 最近告诉我们: “历史上,安全团队从开发团队中分离出来,每个团队都在不同的IT领域拥有深厚的专业知识  。“其实不需要这样。关心安全的企业也非常关心通过软件快速交付业务价值的能力,这些企业正在寻找方法,将安全性留在应用开发生命周期内。通过在整个CI / CD中集成安全实践,工具和自动化来采用DevSecOps。”
 
她说:“为了做到这一点,他们正在整合团队。安全专业人员将从应用开发团队一直嵌入到生产部署中。” “双方都看到了价值,每个团队都拓展了他们的技能和知识基础,成为更有价值的技术专家。正确的DevOps或DevSecOps ,提高IT安全性。”
 
IT团队的任务是更快,更频繁地交付服务。DevOps成为一个很好的推动因素,部分原因是它可以消除开发和运营团队之间的一些传统冲突,Ops通常在部署之前被排除在外,而Dev将其代码丢在无形的墙上,从来不进行二次管理,更没有任何的基础设施维护责任。说得委婉一些,在数字化时代,这种孤立的做法会产生问题。按照Reeves的说法,如果安全是孤立的,也会存在类似的问题。
 
Reeves说:“我们采用DevOps,它被证明可以通过扫除开发与运维之间的障碍来提高IT的性能。“就像不应该等到部署周期结束才开始运维一样,也不应该等到最后才考虑安全问题。”
 

 DevSecOps为什么会出现?
 
将DevSecOps看作是另一个流行语是一种诱惑,但对于安全意识强的IT领导者来说,这是一个实质性的概念。安全必须是软件开发流程中的“一等公民”,而并非最终步骤部署,或者更糟糕,只有在发生实际的安全事件后才受到重视。
SumoLogic公司安全与合规副总裁George Gerchow表示:“DevSecOps不仅仅是一个流行词,由于诸多原因它是IT的当前和未来状态。“最重要的好处是能够将安全性融入到开发和运营流程中,为实现敏捷性和创新提供保障。”
 
此外,在场景中出现的DevSecOps可能是DevOps自身正在成熟并深入挖掘IT内部的另一个标志。
 
“企业DevOps文化意味着开发人员能够以更快的速度向生产环境提供功能和更新,特别是当自组织团队更加乐于协作和衡量结果。”CYBRIC首席技术官兼联合创始人Mike Kail说。
 
在采用DevOps的同时,保持原有的安全实践的团队和公司会遇到更多的管理安全风险的痛苦,因为DevOps团队会部署地更快、更频繁。
 

 手动测试安全方法逐渐落后

 “目前,手动测试安全方法逐渐落后,利用自动化和协作将安全测试转移到软件开发生命周期,从而推动DevSecOps文化,这是IT领导者提高整体弹性和交付安全保证的唯一路径。”凯尔说。
 
(早期)对安全性测试的改变也让开发人员受益:在开发新服务或部署更新服务之前,他们并没有发现代码中的明显漏洞,而是经常在开发的早期阶段发现并解决潜在的问题,几乎没有安全人员的介入。
 
SAS首席信息安全官Brian Wilson表示:“正确的做法是,DevSecOps可以将安全性纳入开发生命周期,使开发人员能够更快,更方便地保护应用程序,不会造成安全干扰。
 
Wilson将静态(SAST)和源代码分析(SCA)工具集成到团队的持续交付中,帮助开发人员在代码中对潜在问题,以及第三方依赖的漏洞进行反馈。
 
Wilson说:“开发人员可以主动、反复地缓解app的安全问题,并重新进行安全扫描,无需安全人员参与。DevSecOps还可以帮助开发团队简化更新和修补程序。
 
DevSecOps并不意味着企业不再需要安全专家,就像DevOps并不意味着企业不再需要基础架构专家一样。它只是有助于减少瑕疵进入生产的可能性,或减缓部署。
 

 DevSecOps遭遇的危机
 
来自Sumo Logic公司的Gerchow分享了DevSecOps文化的实例:当最近的Meltdown和Spectre消息出现时,团队的DevSecOps方法能够迅速做出响应,以减轻风险,而对内外部客户没有任何明显的干扰。 对云原生和受高度监管的公司来说非常重要。
 
第一步,Gerchow的小型安全团队(具备开发技能)能够通过Slack与其主要云供应商之一合作,确保基础设施在24小时内完全修补好。
 
 “然后,我的团队立即开始了OS级别的修复,不需要给终端用户停机时间,也无需请求工程师,那样意味着要等待长时间的变更管理流程。所有这些变化都是通过Slack打开自动化Jira tickets进行的,并通过日志和分析解决方案进行监控,“Gerchow解释说。
 
这听起来像DevOps文化,正确的人员、流程和工具组合相匹配,但它明确地将安全作为该文化和组合的一部分。
 
Gerchow说:“在传统环境下,停机需要花费数周或数月的时间,因为开发、运营和安全这三项功能都是孤立的。凭借DevSecOps流程和理念,终端用户可以通过简单的沟通和当天的修复获得无缝的体验。”
 
 
02
2018DevSecOps三大预测
 
2018年企业的DevSecOps将迎来一些真正的变革。
 
对于DevSecOps来说,2017年是美好的一年,DevSecOps从一个半朦胧的概念演变成可行的企业功能。
 
容器和容器市场的迅速扩张在很大程度上推动了这一演变,容器市场本质上与DevOps和DevSecOps相互交织在一起。一般来说,快速增长和创新往往比科学更能预测趋势,但我仍然愿意尝试一下。
 
从Docker Hub和成熟的容器生态系统中获取了超过120亿张图片,就企业的DevSecOps而言,我们几乎看不到冰山的一角。不过,相信在2018年,我们将看到:基础变革的开始。我认为它会是这样的:
 

 >>>>1.企业领导者和IT利益相关者意识到DevSecOps正在改进DevOps
 
DevOps将开发团队和运维团队聚在一起,它推动协作文化不足为奇。加入安全举措可能听起来很简单,但多年来,安全问题一直是事后的事情,导致企业文化容易使安全团队与其他IT团队形成对立,包括开发团队。 
但是事情发生了变化。
在雅虎亏损3.5亿美元的商业环境下,暴露了其脆弱的安全状况,企业领导者将网络安全看作是一个运维sinkhole的时代已经结束。加强网络安全现在是企业的当务之急。但这种转变需要时间才能重新回到IT文化中。
DevOps和DevSecOps的崛起无疑为重塑应用程序安全性创造了一个难得且令人兴奋的机会,但是DevOps可能会导致转变速度发生变化。DevOps团队和应用程序架构师每天都能够认识到安全的重要性,并欢迎安全团队的加入,但他们之间仍然存在需要磨合的鸿沟。
为正确实施DevSecOps,安全团队需要与DevOps团队保持一致,企业领导者需要为此打造空间和预算。到2019年,希望企业领导人能够意识到推动一个重要的、合法的安全胜利的机会。
 

>>>>2.成功的组织模式将会出现,最可能的是,安全与DevOps团队之间的紧密协作。

虽然该预测并不特别具有启发性,但是相关的。了解DevSecOps需要来自安全和DevOps团队的平等协作,快速跟踪标准蓝图或实施模型,将DevSecOps集成(并最终自动化)到CI / CD进程中。
虽然不同企业有不同的需求,但大多数公司都使用相同的技术工具,特别是在使用容器的情况下。这就为统一的标准化提供了条件。此外,容器的开源特性可以促进相关信息的共享和标准开发。
到目前为止,由于DevOps团队拥有开发流程,他们一直在安全方面处于领先地位。然而,我认为,DevSecOps需要由安全团队领导, 他们是负责企业安全和风险的人,当安全事故发生时,他们会被解雇或被迫离开。
2018年,安全团队需要加强并展示团队的价值和技能。将安全性融入到IT结构中,而不是在网络安全问题成为事实之后才想起。现在我们有机会来实现这一目标。
 

>>>>3.安全团队仍然要缓慢适应DevOps的现实

过去,企业安全团队通常在不重视或不了解安全需要的文化中运营。难怪今天的电商环境是大多数企业相对容易被破坏的环境。 
强大的安全性不仅仅是外围的防火墙。尽管许多安全专家可能最终会看到这种转变,但可能不像DevOps团队所期望的那样灵活。当谈到容器(通常是appsec)时,即使是最有才华和最优秀的安全专家也会面临学习的瓶颈。更不用说已经被充分证明的网络安全技能短缺的现状。
虽然这些因素可能在短期内降低安全对DevOps和 DevSecOps的支持,但是我认为DevSecOps是解决技能短缺问题的一部分。将安全集成到应用程序交付过程中,并将其自动化比用回溯方法更有效率和更具成本效益,可以解决在部署应用程序之前解决安全漏洞。安全专业人士可以通过开放的态度,以新的方式发挥他们的才能,从而获得很多收益。 
2018年希望这个故事有一个快乐的结局。
 

原文链接:
1、3 predictions for devsecops in 2018https://www.infoworld.com/article/3243155/devops/3-predictions-for-devsecops-in-2018.html2、   Why DevSecOps matters to IT leadershttps://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders
 
 
 
推荐阅读:
企业级落地容器与DevOps,选用K8S都有哪些“姿势”
7大ChatOps&5种团队协作工具助力DevOps实践
如果没按这7种习惯,你可能实践的是假DevOps
这款分布式配置中心,会是微服务的降维打击利器吗?
从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
 
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群
 
点击数人云了解更多信息

最佳实践 | 7大维度看国外企业为啥选择gRPC打造高性能微服务?

dataman 发表了文章 • 0 个评论 • 164 次浏览 • 2018-02-06 10:20 • 来自相关话题

 gRPC作为Google开源的,一个高性能、通用的RPC框架,面向移动和HTTP/2设计,跨语言,跨平台,gRPC支持多种平台和多种语言。gRPC在企业环境中落地已屡见不鲜,小数今天带来一篇有关gRPC国外最佳实践的文章。


Bugsnag(注:一家云端bug监控服务商)每天处理数以亿计的错误信息,为了处理这些数据,考虑优先构建一个可扩展,性能强大的后端系统,并从中学到很多有挑战性的技术。最近,我们推出了新版本的仪表板,这个项目要求扩展系统,来处理服务呼叫的显著增加,这些呼叫是跟踪用户发布和会话所需的。


仪表板的发布在进行中,工程团队将Bugsnag的后端功能分解成称之为管道(pipeline)的微服务体系。将管道扩展到支持发布,意味着增加新的服务,并修改现有服务,也可预见到许多新的服务器和客户端的交互。为了处理上述架构的变化,需要采用一致性的方式来设计,实施和集成企业的服务。Bugsnag是一家多语言的公司,服务是用Java,Ruby,Go和Node.js等多语言编写,因此企业需要一种与平台无关的方法。


本文将介绍为什么我们最终选择了gRPC作为Pipeline的默认通信框架。
 
 
达到REST API设计的极限

现有系统传统上使用具有JSON有效载荷的REST API进行同步通信。这种选择是基于占压倒性比例的成熟度、熟悉度和工具的可用性做出的,但是随着跨洲际工程团队的增长,企业需要设计一致的,基于RESTful API的工具。


不幸的是,这感觉就像试图将简单的方法调用变成一个数据驱动的RESTful界面。这满足了RESTful接口的verb,header,URL标识符,资源的URL和有效载荷的神奇组合,并做了一个清洁,简单,看起来几乎不可能实现的功能界面。RESTful有很多规则和解释,在大多数情况下会导致REST ish接口,这需要花费额外的时间和精力来保持其纯度。


最终,考虑到RESTAPI的复杂性,我们找到了替代方案。希望微服务尽可能相互隔离,减少交互和解耦服务。它可以让企业在很短的时间内创造出一个可行的服务,并防止跳过hoops。


评估REST的替代方案


不要轻易选择通信框架。大型组织(如Netflix)可以拥有超过500+个微服务的后端系统。迁移这些服务以取代不充分的服务间通信会花费大量时间,从后勤和财务角度看这很不切实际。花时间从一开始就考虑正确的框架,可以省去很多未来的浪费。

我们花了大量的时间来制定评估标准和研究、选择。Bugsnag到底长什么样子呢?


技术标准

在研究可用选项时,使用了一些特定的标准来评估。要考虑的事情是基于微服务架构的最有效的方法。主要目标是自由地使用通信,消除通信的复杂性,了解每项服务的责任所在。
 
其中的一些技术问题是:
 
速度 - 对于大量的请求/响应API调用,需要将调用本身的延迟作为性能和用户响应速度的最小因素。延迟的主要组成部分是连接成本,传输成本和消息编码/解码时间。
 
基础架构兼容性 - 框架在基础架构中扮演的角色如何?主要是关于负载平衡和自动扩展?我们使用托管在Google云端平台上的Kubernetes服务,因此需要框架来兼容这种环境。
 
开发工具 - 在实现框架时,提供尽可能小的摩擦将会使开发人员更快捷。哪些工具可以帮助编码,本地测试端点,以及单元和集成测试的stubbing/mocking?当事情出错时,我们需要能够看到包括内容在内的请求信息。消息格式等因素也可以使调试更容易依赖于工具,例如JSON消息是人可读的,但是二进制消息将需要额外的努力来解码。
 
成熟度和采用 - 对于初创公司来说,资源是有限的,需要花费在公司的核心业务上,而不是修复,测试和增强第三方框架。诸如框架的普及,大规模使用的例子,社区的活跃程度以及框架本身的成熟度等因素都是稳定性的良好指标。需要强调的是,选择一个解决具体问题的框架,而并非选择最新最热的。
 
多平台支持 - 在真正的微服务思维中,使用最适合其目的的语言编写企业的服务,目前包括Java,Ruby,Go和Node。框架是否为现有的语言选择提供了一流的支持,同时提供了用其他语言编写新服务的选项?
 
代码量 - 框架应该有助于降低工程成本。企业需要编写和维护多少代码才能使其工作?与业务逻辑相比,这是多少样板代码?
 
 
安全 - 所有的内部通信都应该被认证和加密。我们需要能够使用所有通信的SSL / TLS(或等价物)。设计上的考虑,并非都与技术有关


服务API是最重要的接口之一,因为在开发过程中对设置服务期望至关重要。解决服务API的设计是一项艰巨的任务,当不同的团队负责所涉及的不同服务时,该任务会被放大。最大限度地减少由于预期不匹配而浪费的时间和精力,与缩短编码时间一样有价值。由于Bugsnag拥有跨地区的工程团队,因此沟通时间有限。必须通过简化沟通,确保事情不用那么多解释,否则错误很容易产生,事情很容易被拖延。


以下是在选择框架时的一些设计考虑因素:
 
强类型 - 消息是否是强类型的?如果通过服务边界发送的消息清晰可见,那么可以消除由于类型而造成的设计和运行时错误。
 
打开解释 - 能够直接从服务API规范生成客户端库,减少了误解的问题。
 
错误条件 - 有一套明确定义的错误代码可以更容易一致地交流问题。
 
文档 - 服务API应该是易读易懂的。定义服务API的格式应该尽可能清楚,准确地描述端点。
 
版本控制 - 更改是不可避免的,这是一个很好的选择,在某些时候,服务API将需要修改。所使用的消息传递格式和服务定义可以影响修改API并将其部署到生产的容易程度。是否有明确的路径来增加版本及其相应的库,并推出更改?
 
 
微服务最佳实践,为什么可扩展性是重要的


除了上面列出的标准外,还需要选择一个易于扩展的框架。随着微服务的发展,企业需要越来越多的“开箱即用”功能,发展的同时,为系统增加了更多的复杂性。
 
因此企业希望的功能包括:
 
异常处理 - 在请求级别提供一个处理异常的机制。它允许捕获有关请求的重要上下文元数据,例如发出请求的用户,可以用例外报告。我们使用Bugsnag轻松地监视这些异常。
 
智能重试 - 在特定条件下重试请求,例如仅在5xx状态码上。这包括支持各种退避策略,如指数退避。
 
服务发现配置 - 将通信框架连接到流行的服务发现应用程序(如Zookeeper,Eureka或Consul)的选项可以提供一种快速简便的解决方案,以绕过企业的架构来请求路由。
 
度量、跟踪和日志记录 - 可观察性对于复杂的分布式系统是必不可少的,但是应该小心监视的内容。在服务边界自动收集指标和跟踪信息可以快速回答常见问题,例如“我的服务对请求响应缓慢吗?”以及“请求失败的频率如何?”。
 
熔断 - 这种模式可以通过自动检测问题和快速失败来防止级联服务故障。也可以由长时间缓慢的请求来触发,以提供响应降级的服务而不是不断地超时。
 
 
缓存和批处理 - 通过使用缓存或批处理请求来加速请求。


大多数框架不会提供所有功能,但至少它们应该是可扩展的,以便在需要时添加。
 
什么是gRPC和协议缓冲区?

没有一个框架是万能的。我们探索的一些选项包括Facebook的Thrift,Apache Hadoop的Avro,Twitter的Finagle,甚至使用JSON模式。

我们的需求更接近于远程程序调用(RPC),给予所需要的细粒度控制。使用RPC的另一个吸引力是使用接口描述语言或IDL。IDL允许以独立于语言的格式描述服务API,将接口与任何特定的编程语言分离。他们可以提供一系列的好处,包括服务API的一个单一的事实来源,并可能被用来生成客户端和服务器代码来与这些服务进行交互。IDL的例子包括Thrift,Avro,CORBA,当然还有ProtocolBuffers。

最后,明确的获胜者是基于协议缓冲区的gRPC。
 
 
什么是gRPC?
 
我们选择了gRPC,因为它满足了我们的功能需求(包括未来的可扩展性),背后的活跃社区以及HTTP / 2框架的使用。

gRPC是由Google开发,设计用于传统的RPC调用。该框架使用最新的网络传输协议HTTP / 2,主要用于通过使用流的单个TCP连接来实现低延迟和多路复用请求。与REST over HTTP / 1.1相比,gRPC非常快速和灵活。

gRPC的性能对于设置管道来处理仪表板发布的大量增加至关重要。此外,HTTP / 2是下一个标准化的网络协议,可以利用为HTTP / 2开发的工具和技术(如Envoy代理),并为gRPC提供一流的支持。由于多路复用流支持,gRPC支持双向通信,不限于简单的请求/响应呼叫。

什么是Protobufs(协议缓冲区)?Protocol Buffers或protobufs是定义和序列化结构化数据为高效的二进制格式的一种方式,也是由Google开发的。二者的有效结合,也是我们选择gRPC的主要原因之一。

以前有许多与想修复的版本相关的问题。微服务意味着必须不断更新,需要适应并保持向前和向后兼容的接口,protobufs对此非常有用。由于是二进制格式,所以它们也是通过wire快速发送的小型有效载荷。

Protobuf消息使用关联的IDL进行描述,它提供了一个紧凑的,强类型的,向后兼容的格式来定义消息和RPC服务。我们使用最新的proto3规范,并在此处显示protobuf消息的实际示例。

所有字段proto3都是可选的。如果未设置字段,将始终使用默认值。这与字段编号相结合提供了一个API,可以非常抵抗打破变化。通过遵循一些简单的规则,向前和向后兼容性可以成为大多数API更改的默认值。

protobuf格式还允许定义RPC服务本身。服务端点与消息结构共存,在单个protobuf文件中提供RPC服务的自包含定义。对于我们的跨洲际的工程团队来说,这非常有用,他们可以从一个文件中了解服务如何工作,生成客户端并开始使用它。以下是我们的服务之一:

该框架能够生成代码来使用protobuf文件与这些服务进行交互,这是另一个优势,它可以自动生成需要的所有类。这个生成的代码负责消息建模,并提供一个存根类,其中包含与您的服务端点相关的重复方法调用。

支持多种语言,包括C ++,Java,Python,Go,Ruby,C#,Node,Android,Objective-C和PHP。但是,使用protobuf文件维护和同步生成的代码是个问题。我们已经能够通过使用Protobuf文件自动生成客户端库来解决这个问题,会在即将发布的下一篇博客文章中分享更多的内容。


gRPC最好的特性之一是支持中间件模式,被称为拦截器。它允许扩展所有的gRPC实现(这对企业来说很重要),能够轻松访问所有请求,从而实现自己的微服务最佳实践。gRPC还内置了对一系列认证机制的支持,包括SSL / TLS。gRPC社区我们正处于gRPC采用的开始阶段,期待社区提供更多的工具和技术。很高兴能够加入这个充满活力的社区,并对未来的项目有一些想法,我们希望看到这些项目是开放源代码或我们自己写的。gRPC工具的当前状态


gRPC比较新,缺乏可用的开发工具,特别是与经验丰富的REST over HTTP / 1.1协议相比。搜索教程和示例时,这一点尤其明显,因为只有少数有用的信息。二进制格式也使消息不透明,需要努力解码。虽然有一些选择,例如JSON代码转换器可以帮助,但预计需要做一些基础工作,以便为gRPC提供顺畅的开发体验。我们喜欢用Apiary 来记录外部API。使用服务协议缓冲区(protobuf)文件自动生成交互式文档的等价物,将是理想的有效的内部通信gRPCAPI。

protobuf文件的静态分析在运行时能捕获更多的bug。使用Checkstyle作为Java代码,并且把它用作类似于protobuf的文件。

自定义拦截器可以提供跟踪,日志记录和错误监视功能。我们希望开源我们的Bugsnag gRPC拦截器,以自动捕获并向Bugsnag报告错误。gRPC的增长和采用在过去几年中,gRPC的普及度大幅增长,Square,Lyft,Netflix,Docker,Cisco和CoreOS等公司大规模采用。Netflix Ribbon是基于RPC调用使用REST的微服务通信框架的事实标准。今年,他们宣布,由于其多语言支持和更好的可扩展性/可组合性,他们正在向gRPC过渡。该框架最近也于2017年3月加入了CNCF基金会,支持重量级的Kubernetes和Prometheus。gRPC社区非常活跃,与开源gRPC生态系统 列出了许多gRPC激动人心的项目。
 
 
另外,gRPC有我们认同的原则
 
Lyft在转向gRPC方面做了大量的讨论,这与我们的经验非常相似:使用Protocol Buffers和gRPC生成统一的API。值得一试。

gRPC现在还处于初期阶段,存在一些明显的磨合问题,但未来前景光明。总的来说,我们对gRPC如何整合到后端系统非常乐观,并且很高兴见证这个框架的发展。



原文链接:

https://blog.bugsnag.com/grpc- ... erral





  查看全部

v2-132a2ab6614fbc037bbb063a944e72ec_hd.jpg

 gRPC作为Google开源的,一个高性能、通用的RPC框架,面向移动和HTTP/2设计,跨语言,跨平台,gRPC支持多种平台和多种语言。gRPC在企业环境中落地已屡见不鲜,小数今天带来一篇有关gRPC国外最佳实践的文章。


Bugsnag(注:一家云端bug监控服务商)每天处理数以亿计的错误信息,为了处理这些数据,考虑优先构建一个可扩展,性能强大的后端系统,并从中学到很多有挑战性的技术。最近,我们推出了新版本的仪表板,这个项目要求扩展系统,来处理服务呼叫的显著增加,这些呼叫是跟踪用户发布和会话所需的。


仪表板的发布在进行中,工程团队将Bugsnag的后端功能分解成称之为管道(pipeline)的微服务体系。将管道扩展到支持发布,意味着增加新的服务,并修改现有服务,也可预见到许多新的服务器和客户端的交互。为了处理上述架构的变化,需要采用一致性的方式来设计,实施和集成企业的服务。Bugsnag是一家多语言的公司,服务是用Java,Ruby,Go和Node.js等多语言编写,因此企业需要一种与平台无关的方法。


本文将介绍为什么我们最终选择了gRPC作为Pipeline的默认通信框架。
 
 
达到REST API设计的极限

现有系统传统上使用具有JSON有效载荷的REST API进行同步通信。这种选择是基于占压倒性比例的成熟度、熟悉度和工具的可用性做出的,但是随着跨洲际工程团队的增长,企业需要设计一致的,基于RESTful API的工具。


不幸的是,这感觉就像试图将简单的方法调用变成一个数据驱动的RESTful界面。这满足了RESTful接口的verb,header,URL标识符,资源的URL和有效载荷的神奇组合,并做了一个清洁,简单,看起来几乎不可能实现的功能界面。RESTful有很多规则和解释,在大多数情况下会导致REST ish接口,这需要花费额外的时间和精力来保持其纯度。


最终,考虑到RESTAPI的复杂性,我们找到了替代方案。希望微服务尽可能相互隔离,减少交互和解耦服务。它可以让企业在很短的时间内创造出一个可行的服务,并防止跳过hoops。


评估REST的替代方案


不要轻易选择通信框架。大型组织(如Netflix)可以拥有超过500+个微服务的后端系统。迁移这些服务以取代不充分的服务间通信会花费大量时间,从后勤和财务角度看这很不切实际。花时间从一开始就考虑正确的框架,可以省去很多未来的浪费。

我们花了大量的时间来制定评估标准和研究、选择。Bugsnag到底长什么样子呢?


技术标准

在研究可用选项时,使用了一些特定的标准来评估。要考虑的事情是基于微服务架构的最有效的方法。主要目标是自由地使用通信,消除通信的复杂性,了解每项服务的责任所在。
 
其中的一些技术问题是:
 
  • 速度 - 对于大量的请求/响应API调用,需要将调用本身的延迟作为性能和用户响应速度的最小因素。延迟的主要组成部分是连接成本,传输成本和消息编码/解码时间。

 
  • 基础架构兼容性 - 框架在基础架构中扮演的角色如何?主要是关于负载平衡和自动扩展?我们使用托管在Google云端平台上的Kubernetes服务,因此需要框架来兼容这种环境。

 
  • 开发工具 - 在实现框架时,提供尽可能小的摩擦将会使开发人员更快捷。哪些工具可以帮助编码,本地测试端点,以及单元和集成测试的stubbing/mocking?当事情出错时,我们需要能够看到包括内容在内的请求信息。消息格式等因素也可以使调试更容易依赖于工具,例如JSON消息是人可读的,但是二进制消息将需要额外的努力来解码。

 
  • 成熟度和采用 - 对于初创公司来说,资源是有限的,需要花费在公司的核心业务上,而不是修复,测试和增强第三方框架。诸如框架的普及,大规模使用的例子,社区的活跃程度以及框架本身的成熟度等因素都是稳定性的良好指标。需要强调的是,选择一个解决具体问题的框架,而并非选择最新最热的。

 
  • 多平台支持 - 在真正的微服务思维中,使用最适合其目的的语言编写企业的服务,目前包括Java,Ruby,Go和Node。框架是否为现有的语言选择提供了一流的支持,同时提供了用其他语言编写新服务的选项?

 
  • 代码量 - 框架应该有助于降低工程成本。企业需要编写和维护多少代码才能使其工作?与业务逻辑相比,这是多少样板代码?

 
 
  • 安全 - 所有的内部通信都应该被认证和加密。我们需要能够使用所有通信的SSL / TLS(或等价物)。设计上的考虑,并非都与技术有关



服务API是最重要的接口之一,因为在开发过程中对设置服务期望至关重要。解决服务API的设计是一项艰巨的任务,当不同的团队负责所涉及的不同服务时,该任务会被放大。最大限度地减少由于预期不匹配而浪费的时间和精力,与缩短编码时间一样有价值。由于Bugsnag拥有跨地区的工程团队,因此沟通时间有限。必须通过简化沟通,确保事情不用那么多解释,否则错误很容易产生,事情很容易被拖延。


以下是在选择框架时的一些设计考虑因素:
 
  • 强类型 - 消息是否是强类型的?如果通过服务边界发送的消息清晰可见,那么可以消除由于类型而造成的设计和运行时错误。

 
  • 打开解释 - 能够直接从服务API规范生成客户端库,减少了误解的问题。

 
  • 错误条件 - 有一套明确定义的错误代码可以更容易一致地交流问题。

 
  • 文档 - 服务API应该是易读易懂的。定义服务API的格式应该尽可能清楚,准确地描述端点。

 
  • 版本控制 - 更改是不可避免的,这是一个很好的选择,在某些时候,服务API将需要修改。所使用的消息传递格式和服务定义可以影响修改API并将其部署到生产的容易程度。是否有明确的路径来增加版本及其相应的库,并推出更改?

 
 
微服务最佳实践,为什么可扩展性是重要的


除了上面列出的标准外,还需要选择一个易于扩展的框架。随着微服务的发展,企业需要越来越多的“开箱即用”功能,发展的同时,为系统增加了更多的复杂性。
 
因此企业希望的功能包括:
 
  • 异常处理 - 在请求级别提供一个处理异常的机制。它允许捕获有关请求的重要上下文元数据,例如发出请求的用户,可以用例外报告。我们使用Bugsnag轻松地监视这些异常。

 
  • 智能重试 - 在特定条件下重试请求,例如仅在5xx状态码上。这包括支持各种退避策略,如指数退避。

 
  • 服务发现配置 - 将通信框架连接到流行的服务发现应用程序(如Zookeeper,Eureka或Consul)的选项可以提供一种快速简便的解决方案,以绕过企业的架构来请求路由。

 
  • 度量、跟踪和日志记录 - 可观察性对于复杂的分布式系统是必不可少的,但是应该小心监视的内容。在服务边界自动收集指标和跟踪信息可以快速回答常见问题,例如“我的服务对请求响应缓慢吗?”以及“请求失败的频率如何?”。

 
  • 熔断 - 这种模式可以通过自动检测问题和快速失败来防止级联服务故障。也可以由长时间缓慢的请求来触发,以提供响应降级的服务而不是不断地超时。

 
 
  • 缓存和批处理 - 通过使用缓存或批处理请求来加速请求。



大多数框架不会提供所有功能,但至少它们应该是可扩展的,以便在需要时添加。
 
什么是gRPC和协议缓冲区?

没有一个框架是万能的。我们探索的一些选项包括Facebook的Thrift,Apache Hadoop的Avro,Twitter的Finagle,甚至使用JSON模式。

我们的需求更接近于远程程序调用(RPC),给予所需要的细粒度控制。使用RPC的另一个吸引力是使用接口描述语言或IDL。IDL允许以独立于语言的格式描述服务API,将接口与任何特定的编程语言分离。他们可以提供一系列的好处,包括服务API的一个单一的事实来源,并可能被用来生成客户端和服务器代码来与这些服务进行交互。IDL的例子包括Thrift,Avro,CORBA,当然还有ProtocolBuffers。

最后,明确的获胜者是基于协议缓冲区的gRPC。
 
 
什么是gRPC?
 
我们选择了gRPC,因为它满足了我们的功能需求(包括未来的可扩展性),背后的活跃社区以及HTTP / 2框架的使用。

gRPC是由Google开发,设计用于传统的RPC调用。该框架使用最新的网络传输协议HTTP / 2,主要用于通过使用流的单个TCP连接来实现低延迟和多路复用请求。与REST over HTTP / 1.1相比,gRPC非常快速和灵活。

gRPC的性能对于设置管道来处理仪表板发布的大量增加至关重要。此外,HTTP / 2是下一个标准化的网络协议,可以利用为HTTP / 2开发的工具和技术(如Envoy代理),并为gRPC提供一流的支持。由于多路复用流支持,gRPC支持双向通信,不限于简单的请求/响应呼叫。

什么是Protobufs(协议缓冲区)?Protocol Buffers或protobufs是定义和序列化结构化数据为高效的二进制格式的一种方式,也是由Google开发的。二者的有效结合,也是我们选择gRPC的主要原因之一。

以前有许多与想修复的版本相关的问题。微服务意味着必须不断更新,需要适应并保持向前和向后兼容的接口,protobufs对此非常有用。由于是二进制格式,所以它们也是通过wire快速发送的小型有效载荷。

Protobuf消息使用关联的IDL进行描述,它提供了一个紧凑的,强类型的,向后兼容的格式来定义消息和RPC服务。我们使用最新的proto3规范,并在此处显示protobuf消息的实际示例。

所有字段proto3都是可选的。如果未设置字段,将始终使用默认值。这与字段编号相结合提供了一个API,可以非常抵抗打破变化。通过遵循一些简单的规则,向前和向后兼容性可以成为大多数API更改的默认值。

protobuf格式还允许定义RPC服务本身。服务端点与消息结构共存,在单个protobuf文件中提供RPC服务的自包含定义。对于我们的跨洲际的工程团队来说,这非常有用,他们可以从一个文件中了解服务如何工作,生成客户端并开始使用它。以下是我们的服务之一:

该框架能够生成代码来使用protobuf文件与这些服务进行交互,这是另一个优势,它可以自动生成需要的所有类。这个生成的代码负责消息建模,并提供一个存根类,其中包含与您的服务端点相关的重复方法调用。

支持多种语言,包括C ++,Java,Python,Go,Ruby,C#,Node,Android,Objective-C和PHP。但是,使用protobuf文件维护和同步生成的代码是个问题。我们已经能够通过使用Protobuf文件自动生成客户端库来解决这个问题,会在即将发布的下一篇博客文章中分享更多的内容。


gRPC最好的特性之一是支持中间件模式,被称为拦截器。它允许扩展所有的gRPC实现(这对企业来说很重要),能够轻松访问所有请求,从而实现自己的微服务最佳实践。gRPC还内置了对一系列认证机制的支持,包括SSL / TLS。gRPC社区我们正处于gRPC采用的开始阶段,期待社区提供更多的工具和技术。很高兴能够加入这个充满活力的社区,并对未来的项目有一些想法,我们希望看到这些项目是开放源代码或我们自己写的。gRPC工具的当前状态


gRPC比较新,缺乏可用的开发工具,特别是与经验丰富的REST over HTTP / 1.1协议相比。搜索教程和示例时,这一点尤其明显,因为只有少数有用的信息。二进制格式也使消息不透明,需要努力解码。虽然有一些选择,例如JSON代码转换器可以帮助,但预计需要做一些基础工作,以便为gRPC提供顺畅的开发体验。我们喜欢用Apiary 来记录外部API。使用服务协议缓冲区(protobuf)文件自动生成交互式文档的等价物,将是理想的有效的内部通信gRPCAPI。

protobuf文件的静态分析在运行时能捕获更多的bug。使用Checkstyle作为Java代码,并且把它用作类似于protobuf的文件。

自定义拦截器可以提供跟踪,日志记录和错误监视功能。我们希望开源我们的Bugsnag gRPC拦截器,以自动捕获并向Bugsnag报告错误。gRPC的增长和采用在过去几年中,gRPC的普及度大幅增长,Square,Lyft,Netflix,Docker,Cisco和CoreOS等公司大规模采用。Netflix Ribbon是基于RPC调用使用REST的微服务通信框架的事实标准。今年,他们宣布,由于其多语言支持和更好的可扩展性/可组合性,他们正在向gRPC过渡。该框架最近也于2017年3月加入了CNCF基金会,支持重量级的Kubernetes和Prometheus。gRPC社区非常活跃,与开源gRPC生态系统 列出了许多gRPC激动人心的项目。
 
 
另外,gRPC有我们认同的原则
 
Lyft在转向gRPC方面做了大量的讨论,这与我们的经验非常相似:使用Protocol Buffers和gRPC生成统一的API。值得一试。

gRPC现在还处于初期阶段,存在一些明显的磨合问题,但未来前景光明。总的来说,我们对gRPC如何整合到后端系统非常乐观,并且很高兴见证这个框架的发展。



原文链接:

https://blog.bugsnag.com/grpc- ... erral





 

PPT下载 | 亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?

dataman 发表了文章 • 0 个评论 • 148 次浏览 • 2018-02-02 14:50 • 来自相关话题

2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。

数人云Meetup每月一期,欢迎大家来面基、学习。本文为vivo云计算架构师袁乐林分享的“vivo云服务容器化实践”现场演讲实录。

今天讲的内容主要是介绍技术背景,产品的技术架构,我们关键技术的实践,前车之鉴,以及对下一代云服务架构的设想。

技术背景

vivo这些年的业务增长非常快,用户数已经上亿,服务器到了万级,业务域好几百,后端系统的复杂度在迅速攀升,不光是运维方面、架构体系复杂度也非常高,vivo技术架构也是到了破茧化蝶的时候。

我们做过容器、虚拟机与物理机性能对比测试。上面这张图是当时做的性能测试架构图。得出了一些测试结论:
1.容器化app(4c8g)在性能上略优于非容器化app测试指标
2.容器化app(32c64g)性能相较于裸跑同物理机有近4%左右性能损耗,其中TPS有3.85%损耗,平均响应时间3.95%(1毫秒)的增加,对业务请求无影响。
3.容器化app在12h的稳定性测试中表现正常
4.容器化app在cpu相对配额,cpu绑定以及绝对配额场景下,业务性能CPU相对配额 > CPU绑定 > 绝对配额。
5.容器化app在组部件异常,单计算节点,控制异常场景下,容器运行正常。
综上所述,容器化app性能上接近物理机,在多测试场景下,表现相对稳定可靠。同时,对计算密集型app,相对权重配额能实现CPU资源利用率最大化。

vivo容器化云服务框架

正是因为这个性能测试数据的支撑,就有了vivo容器化云服务框架,我们给它取名 Kiver,提供轻量级、高可靠的容器化生产方案。

在这个框架之上vivo一共有八个云服务,按照后来统计数据来看,MySQL加上其他两个服务占到80%的比例,这也非常符合“二八”原则。

vivo整个云服务容器化产品的架构,左边是运维自动化的工具集,比如日志、监控等,日志在业界应用非常广泛,我们用采集容器的数据、容器的监控指标。

这里有两个日志,上面是中间件的业务日志平台,所有业务基于中间件日志规范,输出日志后都会送到这里面收集起来,但是这个业务日志平台功能目前比较薄弱,对新增加的一些组件,比如ECTD等不支持。vivo又引入了现在容器领域比较常见的日志方案EFK,今后会规划把两个日志整合到一起。

vivo在运维方面做了一些工具,如 vivo MachineCtl和 KiverCtl,两个工具主要实现宿主机的自动化,简单来说可以把宿主机操作系统自动化地装起来,装完之后变成Kiver的计算节点或者控制节点。还有KiverPerfermance,是我们内嵌的一个小的性能测试插件。

再来看右边,是vivo的基础设施,物理机和交换机,网络设备和防火墙等,上面是Docker,Docker容器虚拟化技术把物理机上面的相关资源虚拟化用起来。

右边有 Ceph 块存储,实现数据备份,上面是vivo自研的DevOps平台,做了调度框架,右边是用harbor做的镜像仓库,再往上就是云服务Portal,前面所说的那些云服务,同时也可以跑长生命周期应用。
宿主机自动化实践

下面我们讲一下vivo的实践。现在物理机一旦上了规模之后,装操作系统就成为一件大事,我们提供了 vivoMachineCtl,这个工具是一个命令行给运维人员使用,可以实现宿主机集中化的参数配置和自动化。

利用 vivoMachineCtl,首先和物理机管理卡做一个交互,交互之后拿到物理机的MAC地址,这里有个BMC,也有厂商叫iDrac卡,它可以取得这台服务器网卡的MAC地址,创建以MAC地址命名的Bootfile,指明现在需要装什么操作系统,和其他一些参数。再进一步给它一个ipmi消息对服务器复位,然后服务器开始重启。

重启之后,服务器第一次会发dhcp请求,拿到IP地址,之后会走一个pxe的协议,拿到bootfile,下载Bootfile所指明的小系统和内存文件系统文件下来,加载到物理机中,然后开始进行操作系统安装。这就是操作系统安装的过程。操作系统安装完成之后,把安装类和文件系统切换成正在启动的文件系统,在post阶段到集中化的配置中心,把相关的配置拉下来,包括IP地址,主机名和网关等信息,这是宿主机的自动化部署。

KiverCtl实际上就是把操作系统的宿主机变成计算节点或者控制节点。计算节点有如下几个功能:第一,基本的包安装,第二,Docker、Netplugin初始化,启动kiver-guard/flume/cadvisor容器,完成日志和监控指标的采集。

控制节点上面有Etcd和Netmaster,也会可选地把Prometheus/alertmanager/grafana/启动起来。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的转变。

业务日志集成到日志平台实践

这是vivo日志采集的实践,在宿主机上做日志分区,容器运行起来之后挂这个目录,每个容器起来之后会创建一个自己的文件目录。外面有kiver-guard,用来侦听内核文件系统的新日志文件创建的通知。

根据通知会创建软件链接,链接到上一级Flume监控的日志目录,由Flume推到kafka。大数据平台会来消费这里的数据,业务日志平台也会消费这个数据,然后持久化到ES里,最后由中间件日志平台来实现对日志的检索和展示。

为什么要这么做?当时用的flume版本不支持自动收集递归子目录下日志新增内容的收集,完整的文件可以收集进去,但是日志文件在递归子目录下有不停地追加是输不进去的。

kiver-guard本身也是一个容器,它起来之后把宿主机日志目录挂上去,在容器里面侦听日志目录下的create事件。

不管这些日志路径有多深或者在哪里,都可以链接出来。做链接的时候有一点需要注意,要确保链接过来之后文件名称是唯一的。有些容器被删除了,或者日志被轮转删除了,同样也会针对Delete事件,侦测到delete是件之后删除上层flume监控日志路径的对应链接。

基础组件日志收集实践

基础组件日志采用Etcd、Ceph、CentOS、Netmaster等一些网上比较热门的EFK组件,开箱即用。
监控与告警实践

这是监控和告警实践,在容器领域比较常见,vivo采用的是Promethus和Alertmanager。Promethus采用双节点,双拉(拉两遍),两个Promethus之间没有做主从,为了解决高可用问题,挂了一个另外一个还在。

之后接短信邮件中心,后面接Grafana作为监控面板,前面用了telegraf。我们做的东西不仅仅有容器,还有其他的组件像Ceph。我们用Cadvisor收集容器监控指标。

我们对集群健康做监控,也对集群资源使用情况进行监控,集群的健康性采用telegraf可以调用外部shell脚本的特性。我们在控制节点写了脚本,用来检查Etcd的健康情况,也和各个节点进行通讯,检查各个节点是不是健康。之后会返回数值,给出集群健康状态码。

这个就是前面讲的自定义的一些监控指标,这是集群的健康检查,这是集群的资源利用率,大致两条数据链进来。一个脚本由telegraf去拉,推到Prometheus里面,最后展现在Grafana上面。另一个,由DevOps框架把数据写到Mysql里面,再由Grafana定义Mysql的软件源。

这边拉出来的自定义的健康指标支持返回码,这个返回码需要翻译成文字,实际上Grafana已经具备这个特性,我们可以去做一个映射,比如1代表监控,2代表网络问题等等,它可以自动翻译来。
数据持久化实践

说到云服务大家都会关注这个问题,数据怎么做到持久化,做到不丢。容器启动的时候会挂在宿主机上面的一个数据目录,和日志类似,有容器的启动进程,直接写脚本也可以,创造二级目录。

用主机名,是在容器默认的主机名,就是它的默认ID号。如果这个ID已经存在就不用创建,说明容器是起用一个旧的容器,最后建立软链接到数据目录。这样确保每个容器日志数据都持久化到宿主机,还可以确保容器重启后数据不丢。

第二,数据本身有一个单独的备份系统,它会每天晚上凌晨2点跑一遍,把Mysql数据推到Ceph块存储当中,实现数据的可靠性。
集群可靠性实践

这是容器集群可靠性实践,最典型的是三个副本,副本能够实现数据和服务的可靠性。

失效重试,在集群各节点提供一个crontab定时任务,每隔一段时间探测一次docker服务进程健康状况,若不健康,则拉起Docker服务进程。同时我们开启了docker的Restartalways选项,确保容器服务异常退出后,能被重新拉起来。

关于隔离,首先是分区隔离,宿主机业务日志目录/app/log独立分区,避免日志量过大时侵占宿主机系统分区或者业务分区磁盘。

第二,资源隔离,flume当时是跑进程的,我们做的第一件事情是进行容器化,之后做配额,限制能使用的资源使用量,避免大日志传输时侵占宿主机过多资源。

第三,故障隔离,开启dockerlive-restore选项,保障docker服务进程不影响容器服务。
前车之辙

我们犯过一些错误,不负责物理机运营的童鞋可能感受不明显。如果磁盘引导分区被破坏,就可能导致操作系统被重装,这个问题是很严重的。原因也很简单,服务器一般有多引导的选项,比如磁盘、网络、CD,一般在顺序上磁盘第一,网络第二。

但如果磁盘引导分区坏了,服务器会认为没有操作系统,然后就从第二个上引导。这时候不幸的事情是,在你的网络环境里如果之前刚好装过操作系统,采用了第三方开源的部署服务器,而没有把之前的文件删掉,那么它就会把那些操作重新装上。

解决办法很简单,我们提供了定时任务,对两个小时前创建的引导文件,能看见它的创建时间、访问时间,并进行强制性删除。

第二个前车之辙,在收集Ceph日志时碰到困难,当时是用fluent-plugin-ceph插件来做。具体的情况是,第一,官方配置文档不正确,因为提交者没按官方文档格式编码,导致看到的配置是一行,拿回来根本不知道怎么办。第二,它和td-agent1.0 版本不兼容。摸索出的解决方法就是图片上显示的办法。

下一代云服务架构

这是我们下一代云服务架构,与上一代的主要区别在于,把编排框架换成了Kubernetes。目前AI这块已经用起来了,AI部分在线上大概有一百台物理机,跑Job任务,短任务每天可以跑到三万个,一次性可以调动3000个容器,未来会把这个些换成Kubnernetes,包括我们的AI、云服务都会跑在Kubernetes上。
XaaS on Kubernetes

如果把云服务跑到Kubernetes上,第一个要做的事情,可能会采用ceph块存储做后面的数据和数据持久化。目前vivo已经有了数据ceph块存储,但功能还不强大。第二,要解决pod漂移调度问题,如果不用ceph块存储,pod失效调度到其他节点上有问题,调过去没用的,没有数据。
第三,也是最常见的一个,固定POD IP,看到网上有人讨论这个事情,觉得容器坏了,没必要把容器固定起来,因为有违微服务的原则。这种观点不太对,有一些场景,比如在vivo的企业IT架构里面,很多东西都跟IP挂钩,比如安全策略,它不是跟域名挂钩,而是PODIP挂钩,交换机、防火墙等很多的配置都跟这个相关。所以vivo要干的很重要的事情,就是把POD IP固定。
目前业界对这块也有一些实践,比如京东最近有这方面的分享,把PODIP放在一个APP的IP 小池子里面,小池子里面还有IP的话,就从小池子里拿,没有的话就从大池子里去申请。

在微信公众号后台回复“127”,即可获取本次演讲PPT《vivo云服务容器化实践》。
点击数人云阅读更多技术干货 查看全部
2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。

数人云Meetup每月一期,欢迎大家来面基、学习。本文为vivo云计算架构师袁乐林分享的“vivo云服务容器化实践”现场演讲实录。

今天讲的内容主要是介绍技术背景,产品的技术架构,我们关键技术的实践,前车之鉴,以及对下一代云服务架构的设想。

技术背景

vivo这些年的业务增长非常快,用户数已经上亿,服务器到了万级,业务域好几百,后端系统的复杂度在迅速攀升,不光是运维方面、架构体系复杂度也非常高,vivo技术架构也是到了破茧化蝶的时候。

我们做过容器、虚拟机与物理机性能对比测试。上面这张图是当时做的性能测试架构图。得出了一些测试结论:
1.容器化app(4c8g)在性能上略优于非容器化app测试指标
2.容器化app(32c64g)性能相较于裸跑同物理机有近4%左右性能损耗,其中TPS有3.85%损耗,平均响应时间3.95%(1毫秒)的增加,对业务请求无影响。
3.容器化app在12h的稳定性测试中表现正常
4.容器化app在cpu相对配额,cpu绑定以及绝对配额场景下,业务性能CPU相对配额 > CPU绑定 > 绝对配额。
5.容器化app在组部件异常,单计算节点,控制异常场景下,容器运行正常。
综上所述,容器化app性能上接近物理机,在多测试场景下,表现相对稳定可靠。同时,对计算密集型app,相对权重配额能实现CPU资源利用率最大化。

vivo容器化云服务框架

正是因为这个性能测试数据的支撑,就有了vivo容器化云服务框架,我们给它取名 Kiver,提供轻量级、高可靠的容器化生产方案。

在这个框架之上vivo一共有八个云服务,按照后来统计数据来看,MySQL加上其他两个服务占到80%的比例,这也非常符合“二八”原则。

vivo整个云服务容器化产品的架构,左边是运维自动化的工具集,比如日志、监控等,日志在业界应用非常广泛,我们用采集容器的数据、容器的监控指标。

这里有两个日志,上面是中间件的业务日志平台,所有业务基于中间件日志规范,输出日志后都会送到这里面收集起来,但是这个业务日志平台功能目前比较薄弱,对新增加的一些组件,比如ECTD等不支持。vivo又引入了现在容器领域比较常见的日志方案EFK,今后会规划把两个日志整合到一起。

vivo在运维方面做了一些工具,如 vivo MachineCtl和 KiverCtl,两个工具主要实现宿主机的自动化,简单来说可以把宿主机操作系统自动化地装起来,装完之后变成Kiver的计算节点或者控制节点。还有KiverPerfermance,是我们内嵌的一个小的性能测试插件。

再来看右边,是vivo的基础设施,物理机和交换机,网络设备和防火墙等,上面是Docker,Docker容器虚拟化技术把物理机上面的相关资源虚拟化用起来。

右边有 Ceph 块存储,实现数据备份,上面是vivo自研的DevOps平台,做了调度框架,右边是用harbor做的镜像仓库,再往上就是云服务Portal,前面所说的那些云服务,同时也可以跑长生命周期应用。
宿主机自动化实践

下面我们讲一下vivo的实践。现在物理机一旦上了规模之后,装操作系统就成为一件大事,我们提供了 vivoMachineCtl,这个工具是一个命令行给运维人员使用,可以实现宿主机集中化的参数配置和自动化。

利用 vivoMachineCtl,首先和物理机管理卡做一个交互,交互之后拿到物理机的MAC地址,这里有个BMC,也有厂商叫iDrac卡,它可以取得这台服务器网卡的MAC地址,创建以MAC地址命名的Bootfile,指明现在需要装什么操作系统,和其他一些参数。再进一步给它一个ipmi消息对服务器复位,然后服务器开始重启。

重启之后,服务器第一次会发dhcp请求,拿到IP地址,之后会走一个pxe的协议,拿到bootfile,下载Bootfile所指明的小系统和内存文件系统文件下来,加载到物理机中,然后开始进行操作系统安装。这就是操作系统安装的过程。操作系统安装完成之后,把安装类和文件系统切换成正在启动的文件系统,在post阶段到集中化的配置中心,把相关的配置拉下来,包括IP地址,主机名和网关等信息,这是宿主机的自动化部署。

KiverCtl实际上就是把操作系统的宿主机变成计算节点或者控制节点。计算节点有如下几个功能:第一,基本的包安装,第二,Docker、Netplugin初始化,启动kiver-guard/flume/cadvisor容器,完成日志和监控指标的采集。

控制节点上面有Etcd和Netmaster,也会可选地把Prometheus/alertmanager/grafana/启动起来。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的转变。

业务日志集成到日志平台实践

这是vivo日志采集的实践,在宿主机上做日志分区,容器运行起来之后挂这个目录,每个容器起来之后会创建一个自己的文件目录。外面有kiver-guard,用来侦听内核文件系统的新日志文件创建的通知。

根据通知会创建软件链接,链接到上一级Flume监控的日志目录,由Flume推到kafka。大数据平台会来消费这里的数据,业务日志平台也会消费这个数据,然后持久化到ES里,最后由中间件日志平台来实现对日志的检索和展示。

为什么要这么做?当时用的flume版本不支持自动收集递归子目录下日志新增内容的收集,完整的文件可以收集进去,但是日志文件在递归子目录下有不停地追加是输不进去的。

kiver-guard本身也是一个容器,它起来之后把宿主机日志目录挂上去,在容器里面侦听日志目录下的create事件。

不管这些日志路径有多深或者在哪里,都可以链接出来。做链接的时候有一点需要注意,要确保链接过来之后文件名称是唯一的。有些容器被删除了,或者日志被轮转删除了,同样也会针对Delete事件,侦测到delete是件之后删除上层flume监控日志路径的对应链接。

基础组件日志收集实践

基础组件日志采用Etcd、Ceph、CentOS、Netmaster等一些网上比较热门的EFK组件,开箱即用。
监控与告警实践

这是监控和告警实践,在容器领域比较常见,vivo采用的是Promethus和Alertmanager。Promethus采用双节点,双拉(拉两遍),两个Promethus之间没有做主从,为了解决高可用问题,挂了一个另外一个还在。

之后接短信邮件中心,后面接Grafana作为监控面板,前面用了telegraf。我们做的东西不仅仅有容器,还有其他的组件像Ceph。我们用Cadvisor收集容器监控指标。

我们对集群健康做监控,也对集群资源使用情况进行监控,集群的健康性采用telegraf可以调用外部shell脚本的特性。我们在控制节点写了脚本,用来检查Etcd的健康情况,也和各个节点进行通讯,检查各个节点是不是健康。之后会返回数值,给出集群健康状态码。

这个就是前面讲的自定义的一些监控指标,这是集群的健康检查,这是集群的资源利用率,大致两条数据链进来。一个脚本由telegraf去拉,推到Prometheus里面,最后展现在Grafana上面。另一个,由DevOps框架把数据写到Mysql里面,再由Grafana定义Mysql的软件源。

这边拉出来的自定义的健康指标支持返回码,这个返回码需要翻译成文字,实际上Grafana已经具备这个特性,我们可以去做一个映射,比如1代表监控,2代表网络问题等等,它可以自动翻译来。
数据持久化实践

说到云服务大家都会关注这个问题,数据怎么做到持久化,做到不丢。容器启动的时候会挂在宿主机上面的一个数据目录,和日志类似,有容器的启动进程,直接写脚本也可以,创造二级目录。

用主机名,是在容器默认的主机名,就是它的默认ID号。如果这个ID已经存在就不用创建,说明容器是起用一个旧的容器,最后建立软链接到数据目录。这样确保每个容器日志数据都持久化到宿主机,还可以确保容器重启后数据不丢。

第二,数据本身有一个单独的备份系统,它会每天晚上凌晨2点跑一遍,把Mysql数据推到Ceph块存储当中,实现数据的可靠性。
集群可靠性实践

这是容器集群可靠性实践,最典型的是三个副本,副本能够实现数据和服务的可靠性。

失效重试,在集群各节点提供一个crontab定时任务,每隔一段时间探测一次docker服务进程健康状况,若不健康,则拉起Docker服务进程。同时我们开启了docker的Restartalways选项,确保容器服务异常退出后,能被重新拉起来。

关于隔离,首先是分区隔离,宿主机业务日志目录/app/log独立分区,避免日志量过大时侵占宿主机系统分区或者业务分区磁盘。

第二,资源隔离,flume当时是跑进程的,我们做的第一件事情是进行容器化,之后做配额,限制能使用的资源使用量,避免大日志传输时侵占宿主机过多资源。

第三,故障隔离,开启dockerlive-restore选项,保障docker服务进程不影响容器服务。
前车之辙

我们犯过一些错误,不负责物理机运营的童鞋可能感受不明显。如果磁盘引导分区被破坏,就可能导致操作系统被重装,这个问题是很严重的。原因也很简单,服务器一般有多引导的选项,比如磁盘、网络、CD,一般在顺序上磁盘第一,网络第二。

但如果磁盘引导分区坏了,服务器会认为没有操作系统,然后就从第二个上引导。这时候不幸的事情是,在你的网络环境里如果之前刚好装过操作系统,采用了第三方开源的部署服务器,而没有把之前的文件删掉,那么它就会把那些操作重新装上。

解决办法很简单,我们提供了定时任务,对两个小时前创建的引导文件,能看见它的创建时间、访问时间,并进行强制性删除。

第二个前车之辙,在收集Ceph日志时碰到困难,当时是用fluent-plugin-ceph插件来做。具体的情况是,第一,官方配置文档不正确,因为提交者没按官方文档格式编码,导致看到的配置是一行,拿回来根本不知道怎么办。第二,它和td-agent1.0 版本不兼容。摸索出的解决方法就是图片上显示的办法。

下一代云服务架构

这是我们下一代云服务架构,与上一代的主要区别在于,把编排框架换成了Kubernetes。目前AI这块已经用起来了,AI部分在线上大概有一百台物理机,跑Job任务,短任务每天可以跑到三万个,一次性可以调动3000个容器,未来会把这个些换成Kubnernetes,包括我们的AI、云服务都会跑在Kubernetes上。
XaaS on Kubernetes

如果把云服务跑到Kubernetes上,第一个要做的事情,可能会采用ceph块存储做后面的数据和数据持久化。目前vivo已经有了数据ceph块存储,但功能还不强大。第二,要解决pod漂移调度问题,如果不用ceph块存储,pod失效调度到其他节点上有问题,调过去没用的,没有数据。
第三,也是最常见的一个,固定POD IP,看到网上有人讨论这个事情,觉得容器坏了,没必要把容器固定起来,因为有违微服务的原则。这种观点不太对,有一些场景,比如在vivo的企业IT架构里面,很多东西都跟IP挂钩,比如安全策略,它不是跟域名挂钩,而是PODIP挂钩,交换机、防火墙等很多的配置都跟这个相关。所以vivo要干的很重要的事情,就是把POD IP固定。
目前业界对这块也有一些实践,比如京东最近有这方面的分享,把PODIP放在一个APP的IP 小池子里面,小池子里面还有IP的话,就从小池子里拿,没有的话就从大池子里去申请。

在微信公众号后台回复“127”,即可获取本次演讲PPT《vivo云服务容器化实践》。
点击数人云阅读更多技术干货

大家好 新人报道

回复

aai99704 发起了问题 • 1 人关注 • 0 个回复 • 193 次浏览 • 2018-01-31 16:43 • 来自相关话题