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

原文作者: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 条评论
登录 后参与评论

相关文章

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

17年,中国互联网技术走出国门【腾讯篇】

要说哪些公司代表了中国互联网技术的前沿,估计大多数人都会脱口而出:BAT(百度、阿里、腾讯)。中国互联网发展20多年,经历了QQ、游戏、微信红包、双11等等亿万...

1826
来自专栏企鹅号快讯

2018年中间件技术展望

2017年即将过去,Java新技术新版本纷纷出现和发布,让人眼花缭乱。除了springboot2不知是否会作为新年贺礼能否及时发布之外,其余重要的技术都已经登...

2148
来自专栏BestSDK

Mashape 和 RapidAPI 合并,搭建全球最大的API开发市场

应用编程接口发行商RapidAPI和Mashape Inc.近日宣布合并,将组建它们号称的全球最大的应用编程接口市场。 ? RapidAPI的总部位于旧金山,已...

3199
来自专栏TEG云端专业号的专栏

DCOS :私有云的物理基础架构管理引擎

云计算经过多年的发展,逐渐从概念到渐为人认知、到接受、到现在全行业拥抱上云,云的客户也从最初的中小初创互联网企业为主,逐步渗透到大型互联网企业、金融企业、传统企...

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

日新进用户200W+,解密《龙之谷》手游背后的压测故事

本文记录了《龙之谷》手游压测过程中的点点滴滴,希望给其他手游的压测提供思路、方法和工具的借鉴。

5820
来自专栏顶级程序员

新华社点名批评!有些 App 太贪婪了。开发者如何应对?

源 / 新华网 文 / 颜之宏/汪奥娜/周蕊/李黔渝 一款普通的手机浏览器,不开启定位权限就无法正常使用;一个普通的手机输入法,拒绝它收集你的信用卡号...

3345
来自专栏ThoughtWorks

敏捷实践之Desk Check | TW洞见

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

2895
来自专栏EAWorld

Docker 与 K8s 在企业基础设施服务的应用

大家好,本次内容我在我司上个月的PWorld大会上分享过,线下会议参与人数有限,这次应邀在微信上向更广泛的人群分享,同时也加入了我近期的一些新想法,不仅仅是上次...

3585
来自专栏ytkah

微信小程序的好处及可能的不足

微信小程序是什么?小程序基于微信体系,在微信内部不用安装就能使用,体积不超过1 M。如果简单粗暴一点,小程序可以简单理解为——“微信应用”。 引用微信之父张小龙...

3845
来自专栏张善友的专栏

深港澳大湾区第三次.NET技术交流会圆满成功

1506

扫码关注云+社区