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

随着亚马逊的网络服务收入在去年达到了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 条评论
登录 后参与评论

相关文章

来自专栏数据和云

MySQL vs Postgre SQL: 5个你最关注的非技术维度的区别

开源数据库中有一堆冤家,我想大家都知道,那就是MySQL与Postgre SQL。两个派系的恩怨情仇从何而来,今天我们将从非技术的角度来进行分析。 本文仅代表个...

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

SAP最佳业务实践:生产订单拆分-工具生产(236)-1业务概览

image.png 用途 此业务情景将允许您使用按库存生产 (MTS, Make-to-stock) 的生产订单处理来生产工具。工具产品是匿名制造的,并作为...

3306
来自专栏有趣的django

微信小程序入门(一)

1182
来自专栏云计算D1net

如何为混合云工作负载找到适合的场合:5个安全问题

一旦开始部署实际工作负载,使用真实数据和实际流程,就会发生一些变化:某些数据以及其中一些过程会很敏感。那么企业应该如何决定将工作负载放在哪里,一旦他们部署在那里...

670
来自专栏云市场·精选汇

如何注册小程序?(附完整注册流程)

方式一:登录微信公众平台(http://mp.weixin.qq.com/),单击右上角的“立即注册”。

1988
来自专栏服务端思维

微服务架构概述

传统的单体架构,使用三层架构,包括视图表现层、业务逻辑层与数据访问层,其划分的目的是为了更好地规划软件系统的逻辑结构,便于开发与维护。单体架构将整个应用系统视为...

801
来自专栏云计算D1net

闲话虚拟化和云计算的异同点

经常有人讨论这两者的区别,在这个行业时间长,听到的也自然很多,这里做一个总结。下面的观点,我想没有对和错,只是理解不同。 所谓虚拟化,虚拟机,vps,其实是差不...

3314
来自专栏nice_每一天

《互联网架构 》来自一位大牛的分享

对于大部分程序员来说架构师这条路还很远。但是掌握现阶段Java的主流技术无疑提升了自身的竞争力。

701
来自专栏令仔很忙

软件文档总结

   首先说一下软件工程,软件工程标准的制定有一个生命周期,从发起建议到发布和维护大致如如下:

651
来自专栏云计算D1net

微软云计算服务Azure全球大范围宕机

北京时间8月19日消息,据彭博社报道,微软云计算服务Azure的主要组件周一发生全球大范围宕机。 微软表示,Azure服务目前处于中断状态,原因是位于全球多个数...

35010

扫码关注云+社区