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

原文作者：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.