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

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

相关文章

来自专栏EAWorld

万达网络科技的DevOps平台架构解析

目录: 一、万达DevOps平台建设历程 二、平台架构解析 三、建设过程中的难点分享 四、总结 一、万达DevOps平台建设历程 我们从2017年2月份开始帮助...

2645
来自专栏EAWorld

谈谈企业的持续交付流水线设计

有一天,业务人员急冲冲的跑过来,对你说生产上出现了一个严重BUG,必须要尽快修复。你听完问题描述后,胸有成竹坐定并迅速定位问题,随后改动了一行代码并提交,系统开...

2688
来自专栏黑白安全

我的渗透测试之道

我做渗透测试也有一段时间了,服务了很多企事业单位,由于我所在的单位性质的关系,也接触到了很多其他公司接触不到的项目,从中也积累了很多的经验。

592
来自专栏SDNLAB

SDN与OpenStack集成需要解决的三大问题

最近这大半年,博主花了不少精力在SDN与OpenStack neutron的集成上。快到年底了,有必要稍微总结一下这大半年来究竟都解决了些什么问题。抛砖引玉,希...

28510
来自专栏DevOps时代的专栏

云时代软件研发的终局猜想

2015 年到 2016 年,是业界普遍认为的容器技术爆发的一年,短短几年时间,我们看到容器技术星火燎原。但是容器毕竟是个底层产品,距离业务还很远。对云上客户来...

843
来自专栏云计算D1net

如何确保容器的安全性?

对于许多企业来说,容器化使得释放速度更快,比虚拟机更加有效率。与此同时,容器引入了新的部署模式,因此,企业架构师和安全专家需要重新考虑:采取哪些方式来保证应用程...

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

海量存储第二弹 - 立体化监控

架平主要服务了公司内部的胖子业务,主要提供了其中的海量存储、海量CDN相关的服务,这些服务最终都体现在业务多、机器数量多、区域及运营商分布广泛(国内海外都有)、...

2673
来自专栏北京马哥教育

【重磅】大众点评运维架构图文详解 @高效运维

本文根据高效运维系列群「运维讲坛」的嘉宾分享整理而成。运维讲坛,邀请国内运维领域优秀技术专家作为分享嘉宾,其中线上分享每周一次,线下沙龙活动每月一次。欢迎点击上...

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

如何利用各种“桥梁”,建立跨国沟通的信任

游戏业务运维能够接触现网环境作为玩家与业务项目组、代理开发商之间的”桥梁“,同时也作为业务项目组与代理开发商之间的技术”桥梁“,处于一个核心枢纽岗位的游戏运维人...

1765
来自专栏养码场

限时领取!全套Linux运维教程,200集实战教学,让你从入门到精通!

根据场主了解,Linux高级运维工程师的起薪在8-10K,1-3年工作经验能拿12-16K,3-5年工作经验能拿年薪30-50W。

912

扫码关注云+社区