不要太信任云:不仅仅只是关乎安全的原因

原文作者:Abner Germanow

原文地址:https://dzone.com/articles/dont-trust-the-cloud-why-its-about-more-than-just

在过去的一年,亚马逊公司网络服务的收入达到50亿美元(根据亚马逊的财务报表报告),另外,Bessimer Venture’s Cloud Index也反映了2014年全球云计算业务收入达到170亿美元,显然很多机构都把资金投到他们信任的云计算和软件即服务(Software-as-a-Service ,SaaS)等领域上。虽然我们相信这些数十亿资金量级的产业增长速度要比任何其他技术更快,但是,如果这些数字再翻十倍呢?很多调查认为信任和安全对于加速云计算大规模应用至关重要。

那么信任云意味着什么?它意味着更多的访问控制、加密和防火墙吗?当然,但同样重要的是,这意味着加速云的成功,需要问责制和可见性。

在信息技术世界中,“信任”一词与追加补丁式的安全技术营销高度相关,这些技术旨在诱发社会恐慌,从而赚钱。然而,我们相信的现实是,在一个由分布式组件、团队、服务提供者以及服务等组成的应用程序的世界中,没有任何验证的信任是为业余爱好者服务的。类似地,建立在问责和验证上的信任,不仅仅只是为了专业技术偏执狂,也是为了专业软件开发团队,他们利用不断扩展的分布式组件和团队进行工作。

这三个例子阐明了信任还欠缺的地方——验证和问责仍然被需要。

1.云计算的信任分界点

每个服务提供者都有一个分界点,服务交付的结束和客户责任的开始。例如,在你家的路由器中,这个分界点是路由器连接运营商的以太网端口(或无线局域网接入点),用于连接您的设备。如果你的互联网连接温控器有问题,你的网络运营商也许能提供一些帮助,但是恒温器故障是你的责任,而不是他们的。这些分界线通常在设备供应商和网络运营商之间转移,但它们永远存在。

在云服务中,分界点的不同取决于服务提供商将服务和代码之间的线划在了哪里。例如,在一个基础设施的服务中,如Amazon’s EC2,物理基础设施是服务提供商的责任,而操作系统、虚拟机、容器,以及运行在上面的代码,这是你的责任。或者在一个平台即服务(Platform-as-a-service ,PaaS)像Amazon Beanstalk, Pivotal, Heroku, or Azure中,这个分界点,在运行的服务和代码之间。按照设计(由于安全、治理和责任),基础设施即服务(Infrastructure-as-a-Service ,IaaS)和平台即服务(PaaS)提供商通常不想通过访问你的代码来帮助解决问题。通常信任服务之间的分界线是很好的,你的代码也能够得到妥善的安置,但是那些称职的软件运营人员,还是会通过工具来验证和监控分界点上的服务状态。

为什么验证你的应用程序和服务提供者之间的分界点很重要?一句话,问责。当出问题时,责任归服务提供者还是你?关键是要确定是服务提供者造成了问题,还是你的团队在基础设施配置或最近的版本中改变了什么。注意:即使你把应用程序设计成对服务故障具有弹性恢复能力,您也应该在制定将来的架构和服务提供商的决策时认识到这些故障的广度和深度。搜索“Chaos Monkey”获取更多。

2.信任微服务间关系

软件团队如何应对基于需要创新和迭代的充满依赖性的庞大僵化代码的挑战?我们把它们拆分成若干服务。酷的人称之为“微服务”。

基于服务器的应用程序架构已经普及有一段时间了,但是由于基础设施的版本控制、容器和API标准,建立和保持组合的应用程序变得更加容易。与此同时,需要扩大开发人员的生产力并打破单块应用程序的月约束,这对扩大成功的软件业务至关重要。这导致了越来越多的应用程序变成了被开发、测试、缩放、切换的复合服务,以提供应用程序弹性和能够以较少的构建依赖性演进。

最好的做法是建立身份验证机制、服务目录、API监控、故障和回退场景,以及将服务从内部唯一服务转向外部服务的能力,而不是简单地信任服务来完成工作。

否则,如果这些服务彼此交流的唯一方式是通过标准化的接口,那么旁边的团队可能会搞砸,不小心发起拒绝服务,攻击你的服务。组织需要验证每一台服务器都在正常工作。正如Steve Yegge’s famous rant中关于为什么亚马逊如此擅长经营平台和亚马逊如何衡量开发者的生产力,这意味着,要意识到“当你的服务器说,‘哦,是的,我很好’,很可能,服务器中唯一能运行的就是一个小部件,它知道如何用一个欢快的机器人声音说‘我很好,收到,收到,通话完毕。’"

3.在客户体验竞赛中,代码的更改是持续不断的

消除摩擦,在客户体验中提供欢乐和发现的时刻,需要无穷无尽的艺术和实验。支持这种艺术的科学需要不断修改代码。

在一个不断变化的软件世界中,一行代码的改变,可能会使一个网站或应用程序,昨天运行良好,而今天整个业务坍塌。对这些场景的恐惧,可以阻止开发人员将代码工业化生产。

最佳的实践要求用 CI tools、自动化测试、自动化安全测试和负载测试来检验代码,同时也要监控产品应用程序的可用性、性能、功能采用、成本控制等,而不是简单地将代码一路信任直至进入最终产品。

(更多关于这个话题,可以查看Blazemeter的这篇博客文章:Two Vital Components Your Continuous Delivery Process Can’t Ignore.)

不要完全信任云……

上面的三个示例演示了基于云的关系,这些关系需要在现代分布式应用程序组合中进行问责、验证和监视。然而,信任和验证几乎需要多个团队协同工作,特别是在处理承包商、成本控制和其他移动部件时。云服务可以给软件团队前所未有的专注和速度,但聪明的方法总是确保你对一切都有可见性。

这个博客可能包含第三方站点上的内容链接。通过提供这样的链接,New Relic不接受、保证、批准或认可这些站点上的信息、观点或产品。

Cloud image courtesy of Shuttstock.com.

本文的版权归 周汪洋 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Rainbond开源「容器云平台」

Docker实战:一部奋斗史

1193
来自专栏DevOps时代的专栏

高效持续交付的 7 大原则

如果你身处IT领域,并且你不是昨天才出生的,那么你一定理解速度的必要性。自从企业实施了持续集成(CI)和持续交付(CD),开发与交付周期要比过去快了很多。举个例...

932
来自专栏安智客

8张图带你玩耍Mbed OS!

对于MbedOS的认知一直停留文档上,安智客上周末闲逛淘宝手贱买了一个支持MbedOS的开发板,到货了忍不住玩一玩,也就是helloworld!各位见笑了!整理...

852
来自专栏程序员的SOD蜜

2010技术应用计划

导读: “2010技术应用计划”是去年3月中心部门头脑风暴“成果”的一部分,现在重新回顾一下,当时的许多计划或许对现在及以后还有一定的意义,故放在我的博客“朝花...

1766
来自专栏云计算

信“云”你就输了,它不仅仅是安全问题

随着亚马逊的网络服务收入在去年达到了50亿美元(正如亚马逊的财务报表所报告的)和Bessimer公司在 2014年170亿美元的云计算收入,可以看出很多公司都...

2030
来自专栏Java架构师学习

一文读懂:完整的支付系统整体架构!

在不同的公司由于接入渠道和应用的差异,对支付产品分类略有不同。综合支付场景和流程,支付产品可以分为如下几类:

943
来自专栏Rainbond开源「容器云平台」

视频 | Rainbond与Service mesh微服务架构

一体化架构为何遭遇强拆?开发语言为何自由选择?资源利用率为何大幅提高?微服务架构插件体系,应该怎样结合?独立部署、升级、替换、伸缩的微服务,运维应该是喜是忧?管...

3128
来自专栏BestSDK

听云SDK发布《中国移动应用性能管理白皮书》:高德路径规划API接口响应耗时最短

移动互联网时代,各种应用都在抢占移动APP市场。据统计,2017年全球手机用户人数将突破50亿人,发展速度远远超过传统互联网,中国亦如是。相应的,中国的移动应用...

3405
来自专栏腾讯大讲堂的专栏

数据中心假负载验证测试之道

1什么是数据中心假负载验证测试 众所周知,购车前我们都会有试驾环节,通过试驾我们可以验证和评估车辆的品质。同样的,在新建数据中心基础设施交付前,也需要通过假负载...

2016
来自专栏SDNLAB

如何确保SDN基础设施的安全

编者按:SDN受到越来越多人的青睐,但是SDN部署迟迟未能落地,主要原因就是企业担心部署冒的风险太大,对基础设施产生很大的影响,因此很多企业抱着观望的态度,那么...

2074

扫码关注云+社区