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

随着亚马逊的网络服务收入在去年达到了50亿美元(正如亚马逊的财务报表所报告的)和Bessimer公司在 2014年170亿美元的云计算收入,可以看出很多公司都把钱投给了云计算和软件服务(SaaS)。虽然我们认为,这数十亿美元的增长速度超过了科技领域的其他任何东西,但这些数字带来的其他10倍增长的东西又会是什么呢?许多调查都认为信任和安全对于加速云的采用至关重要。

那么,信任云意味着什么呢?它是否意味着我们有更多的访问控制权利、加密和防火墙的设置?当然,但同样重要的是,它意味着加速云的成功需要责任性和可见性。

在信息技术世界中,“信任”这个词与螺栓的安全技术的营销密切相关,目的是诱导恐惧和产生金钱。然而,我们相信现实是,在一个由分布式组件、团队、服务提供者和服务组成的应用程序的世界中,没有验证的信任是业余的。类似地,信任与验证和问责并不仅仅是为了职业的偏旁,它同样适用于专业的软件团队,而且他们正在使用不断扩展的分布式组件和团队。

以下三个例子解释了信任不够的地方—验证和问责制的需要:

1.云中的信任分界点

每个服务提供者都有一个划分点,即服务的交付和客户的责任开始。例如,在你家里的路由器中,demarc点是连接到路由器和你用来连接设备的以太网端口(或无线局域网接入点)之间的连接点。如果你的联网温控器有问题,你的连通性提供方可能会提供一些帮助,但是恒温器是你的责任,而不是他们的。这些需求线经常从提供者转移到提供者和服务到服务,但它们始终存在。

在云服务中,demarc点的变化取决于提供者在服务和代码之间的位置。例如,在像Amazon EC2这样的基础设施服务中,物理基础设施是服务提供者的职责,而操作系统、虚拟机、容器和运行在它上面的代码则是我们的职责。或者在平台服务(PaaS)中,如Amazon Beanstalk、Pivotal、Heroku或Azure,demarc点位于运行时服务和代码之间。通过设计(根据安全性、治理和责任性而定)基础设施服务(IaaS)和PaaS提供商通常不希望访问您的代码来帮助修复问题。相信服务和您的代码之间的界限是正确的,但是任何值得他们运行软件业务的人都可以运行工具来验证和监视该需求点处的服务状态。为什么验证应用程序和服务提供者之间的需求点是很重要的?一句话说,问责制。当出现问题时,是提供者还是你的责任?确定是服务提供者导致问题还是您的团队在基础结构配置或最近的发布中更改了什么导致问题产生是至关重要的。注意:即使您架构您的应用程序以适应服务失败,您也应该认识到在构建未来的架构和服务提供者决策时,这些失败的广度和深度。搜索“混沌猴子”在这方面的更多。

2.相信微服务之间的联系

软件团队如何处理随着创新和迭代产生需要的依赖于单片代码库的挑战?我们把它们分成几块服务项目。网络语言称呼他们“微服务”。

基于服务的应用程序体系结构其实已经存在了相当长一段时间,但是随着基础设施版本控制、容器和API标准的出现,构建和维护可组合应用程序变得更加容易。与此同时,要扩大成功的软件业务,就必须提高开发人员的生产力,并打破单一应用程序的人月限制。这导致越来越多的应用程序成为开发、测试、伸缩和以提供应用程序弹性和更少的构建依赖的能力的方式进行的服务组合。

相比于简单地信任一个服务来完成工作,其实最好的做法是建立在身份验证机制、服务目录、API监视、失败和回退场景以及将服务从内部服务转换为外部服务的能力。否则,如果这些服务之间的唯一通信方式是通过一个标准化的接口,那么隔壁的团队可能会在不经意间启动对服务的拒绝服务攻击。组织需要验证每个服务是否有效。Steve Yegge提到著名的咆哮在亚马逊为什么以及如何很好平台和扩展开发人员的生产力,这意味着被意识到,“当你的服务说,“哦,是的,我很好,”很可能的情况仍然运行在服务器的唯一的事就是小组件,知道如何说“我很好,罗杰·罗杰,”在一个愉快的droid的声音。”

3.在客户体验的竞争中,代码的变化是恒定的

在客户的体验中消除摩擦,提供快乐和发现的时刻,需要无止境的艺术和实验。支持这种艺术的科学需要不断的代码变更。

在一个不断变化的软件世界里,一段代码的改变可以让一个网站或应用程序在昨天运行良好或者在今天把整个业务都搞垮。对这些场景的恐惧可能会使开发人员无法将代码推向生产环节。与其简单地将代码委托到生产中,最佳实践还需要通过CI工具、自动化测试、自动化安全测试和负载测试来验证代码,并监控生产应用程序的可用性、性能、特性采用、成本控制等。

(关于这个主题的更多信息,请参见这篇关于两个重要组件的“BlazeMeter”客座文章 。)

不要相信云…

上面的三个示例演示了基于云的关系,它们需要在现代分布式应用程序组合中负责、验证和监控等职能。然而,信任和验证是需要的,在任何多个团队一起工作的地方都是需要的,特别是当你处理承包商,成本控制,和其他灵活的部分。云服务可以让软件团队获得前所未有的关注和速度,但是聪明的途径总是你总是对所有事物都具有可见性。

这个博客可能包含链接到第三方网站的内容。通过提供这些链接,New Relic不采用、保证、批准或认可在此类网站上提供的信息、视图或产品。

本文的版权归 庹阳 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

从理解管理级别入手,为IT系统选择恰当的云监管

监控管理是云计算中的重要一环。但是当企业不理解各种管理级别的差别时往往会碰壁。 云管理和安全通常是相辅相成的,所以你如果不事先搞懂你的监管策略的话,是无法选择出...

374120
来自专栏张善友的专栏

怎样维护成功的开源项目

开源可不仅仅是将代码扔到网上就万事大吉了,将开源项目变成能让自己引以为豪的东西才算成功。那么,你需要注意哪些方面呢? 写好指导性文字 每一个开源项目有三样东西是...

21480
来自专栏软件测试经验与教训

张老师聊面试(二)

小梅,毕业一年,从实习到现在都在一家外包单位工作,做的是手机测试和定制软件的测试,由于工作单调,且没有成长空间,因此考虑换一份工作。但几次面试都不太顺利。

11110
来自专栏java一日一条

微服务与Java EE

时至今日,基于微服务的架构已经随处可见了。我们见识到了Netflix与Amazon等创新者是如何通过微服务来取得业务上的成功。不过,对于那些使用Java EE服...

11710
来自专栏微服务生态

关于分布式调度框架的一些优秀资源总结

http://www.cnblogs.com/zuoxiaolong/p/niubi-job-3.html niubi-job 社区资料少,群(包含作者)活跃...

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

【大系统小做】——理论篇

大系统小做是什么? 我们先看一个简单的例子: 舞厅要装设多色灯,有2种实现方案: ? 思考:它们各有什么优缺点? 方案1: 优点:整体性强; 缺点: 系统可靠性...

32490
来自专栏互联网数据官iCDO

Google Analytics增强版电子商务功能的分步指南

译者:陈荣芳、审校:朱玉雪 本文长度为3728字,预估阅读时间7分钟。 我们今天要向大家简单介绍下,如何使用Google Analytics增强版电子商务插件...

65840
来自专栏Java架构

架构的演进,阿里资深Java工程师表述架构的腐化之谜

新技术层出不穷。过去十年时间里,我们经历了许多激动人心的新技术,包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境,缩短了产品...

455100
来自专栏Java架构

架构的演进, 阿里资深Java工程师表述架构的腐化之谜

21450
来自专栏ThoughtWorks

2015.1 技术雷达 | 技术篇

许多项目都存在外部代码依赖,这些依赖中很大一部分是由开源项目提供的。为了确保构建过程可被重现,我们总是与固定版本的外部依赖进行集成。但这就意味着我们与这些类库的...

36270

扫码关注云+社区

领取腾讯云代金券