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

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

相关文章

来自专栏Java架构

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

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

41910
来自专栏云计算

迁移到微服务架构

在这篇文章中,我将介绍我对于一些微服务相关问题的看法。第一个问题是为什么金融科技公司应当把遗留的传统架构应用迁移到现代的架构风格上;其次,如何在这一范式迁移过程...

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

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

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

3954
来自专栏Java编程技术

阿里之路(一)

我是2015年6月研究生毕业,然后通过校招进入到阿里巴巴,当时复习时候目标很明确就是要进入BAT,然后就一堆堆资料的复习,本科+研究生7年用的都是c++,所以面...

1182
来自专栏云计算D1net

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

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

35212
来自专栏EAWorld

数字化企业云平台的Cloud Native12原则(上)

本文作者介绍了未来云原生应用建设的方法论,开发Cloud Native App的理想实践标准——12要素原则的前6个原则,并围绕数字化企业云平台讲述了具体实践方...

2976
来自专栏我的安全视界观

【企业安全】企业安全项目-测试环境内网化

1855
来自专栏极乐技术社区

『Demo』音乐类Demo大全

好东西要乐于分享 好的Demo资源可遇而不可求,在这个小程序Demo资源越来越少的时局下,极乐蜀黍给大家雪中送炭,拿出自己的收藏多年的Demo资源,可不要太感动...

2055
来自专栏美团技术团队

云端的SRE发展与实践

背景 SRE(Site Reliability Engineering)是Google于2003年提出的概念,将软件研发引入运维工作。现在渐渐已经成为各大互联网...

3299
来自专栏媒矿工厂

优化延迟的最佳视频传输方案(二)

上一篇文章《优化延迟的最佳视频传输方案(一)》介绍了在整个视频传输系统中的分发链前端和媒体内容准备方面的延迟优化方案,本文将继续介绍传输系统的接下来的优化方案,...

932

扫码关注云+社区