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

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

相关文章

来自专栏无原型不设计

普通程序员该如何进阶为全栈工程师?

如何成为一名全栈工程师(full stack developer)?互联网最热的话题之一。LinkedIn, Facebook上标榜自己是全栈工程师的人也越来...

4795
来自专栏owent

2016年总结

又好久没写blog啦。诶最近好懒啊。正好过年在家里有点空,写完我那些lib的patch之后还有一点时间写一下2016年的总结吧。

1293
来自专栏SAP最佳业务实践

SAP最佳业务实践:MM–无QM采购(130)-1业务概览

用途 无需质检的采购 优点 可使用采购信息记录、货源清单、合同等已有数据创建采购订单,从而提高采购处理效率。 可将报价请求(RFQ)自动分配到采购订单 ...

3124
来自专栏BeJavaGod

Shiro系列视频 - 3. 权限管理的解决方案与方式

这是关于Shiro的原创系列视频,目前已经在官网以及一些自媒体平台发布,公众号也开始同步更新,在线播放采用腾讯视频,削微模糊 Shiro系列视频 - 3. 权限...

2729
来自专栏北京马哥教育

不能在Linux下玩游戏?看完这篇文章从此Linux下玩游戏不是梦

自述:从第一次看到Linux系统,从大神那里了解到了Linux灵活、干净、开源等诸多的好处后,我打算入坑。但是,作为一个游戏迷,用笔记本打游戏绝对是不能省的。...

4577
来自专栏ThoughtWorks

微服务 | Martin Fowler

“微服务架构”这一术语在前几年横空出世,用于描述这样一种特定的软件设计方法,即以若干组可独立部署的服务的方式进行软件应用系统的设计。尽管这种架构风格尚无明确的定...

4006
来自专栏王清培的专栏

SOA架构设计经验分享—架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3....

2309

不要信任云:这不只是安全的问题

亚马逊的Web服务在过去一年中收益达到50亿美元(据亚马逊的的财务报表显示),Bessimer创业企业的云指数反应了2014年在云端的另外140亿美元收入,显然...

19510
来自专栏java一日一条

为什么我要写自己的框架?

其实说白了框架就是使用别人造好的轮子。在软件开发里面就是command+C/command+V。

861
来自专栏ThoughtWorks

数字化企业的API架构治理

在前文中我们说到,传统企业在逐步建设自己的数字平台过程中,需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱...

3144

扫码关注云+社区