本文主要是介绍CIO的困境：云端网络设计与服务，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本文翻译自：http://www.druva.com/blog/cios-dilemma-designing-networks-services-cloud/
云，已经改变了之前的游戏规则，为供应商和使用者都带来了利益，但也被现有体系束缚。想象一个情景，公司的CIO（首席信息官）思索如何将现有的东西迁移到云端。云带来的在成本上和敏捷性上的好处对于任何一个组织来说无疑是具有吸引力的一个选择。它让研发人员可以将有限的资源应用到公司的核心业务上，去开发更具公司影响力的新项目。
加强网络间的关联
网络提供的容量和分析使得网络供应商可以缓解CIO的困境。到目前为止，本章研究的内容目的在于促进云端的使用，让企业或组织将越来越多的核心业务迁移到云端，而网络在这一过程中又会起到关键性的作用，而且它的作用会越来越重要。
许多云的世界
现在又各种不同的云存在着：公有的、私有的和混合类型的云，它们随着团体和某些特殊的云端产生，来满足不同的商业需要，如医疗服务，多媒体，金融和政府。如图4-2所示，我们正在进入一个有许多云交互的世界，这些云满足那些想要在任何时间，任何地点，任何设备使用云服务及想要将IT作为服务传输的商业需求。
图4-2 许多云的世界（来源：Cisco）
在这些云里，网络的作用很关键，因为云之间是需要安全连接的。除此之外，随着网络中APP和传送的内容增多，需要大量的基础设施为用户提供一个安全和持续性的，并且忽略用户的位置和其中的云端平台数量的体验。网络会将这些设施结合在一起，虚拟化云之间，云和用户之间的连接。
一个更大的云
经历了几年的发展，在消费者和移动设备，传感器，驱动器的数量和类型上都有了爆炸式的增长，这些中有许多现在都已经接入互联网中。我们会有这样的一个想法：这些云并不仅仅局限于存在于数据中心的服务器，实际上，如图4-3所示，云已经扩展到所有这些接入互联网的电子设备上，如智能仪表和其他的传感器。当你把他们都放在一起时，很容易发现横向来看，这是个拥有数十亿级的网络连接组件的云。
图4-3 移动消费类电子和传感器组成的云
（来源：J.Rabaey，“A Brand New Wireless Day”）
想象一下现在运行着几十个传感器的汽车。3G/4G的数据连接促成了机器与机器（M2M）的交流，汽车厂商可以通过传感器来检测和共享车辆性能的数据。而这些数据可以作为为汽车提供保养和维修的有力参考。或者客户也愿意让汽车之间进行交流，通过本地网络的点对点方式，就可以知道前方的路况和交通状况。当然，安全也是极为重要的。毕竟，我们可不希望不被信任的地方被控制，例如刹车或者其他与安全相关的部分。未来的可能性是无限的，像你看到的那样，动态的，可升级的和安全的网络在未来的云中会至关重要。这些未来的云会在13章讲到，“未来小觑”。
云端数据量的增长
客户和商业云服务，包括富媒体服务，一直保持着主流式的增长。导致了数据中心流量的爆炸式增长。据思科的GCI数据来看，从2010年到2015年，云端IP会达到66%的复合年均增长率，这是同一时期总体数据33%的两倍。如图4-4所示，总体数据期望在2015年达到4.8ZB。而云端流量会占到1/3。
图4-4 从2010到2015年的数据流量（来源：Cisco Cloud Index）
注：思科的云数据索引包括了所有供应商或企业的数据中心，并包括以下几个方面
1 数据中心遗留下来的数据流量
2 数据中心之间的流量
3 因特网上数据中心和终端用户间的数据流量
让我们来看以下1.6ZB的流量有多大，这相当于5兆亿个小时的商业网络会议，或者是1.6万亿的高清视频流量。另一个有趣的比较是总体上的全球网络流量，根据思科VNI预测的，在2015年仅仅是1ZB。
除了在流量上令人吃惊的增长，云APP，服务和基础设施用来负责数据中心流量的传输。那些在数据中心内部，数据中心之间和用户到数据中心之间的cloud-ready网络会有着极其重要的作用。这又体现在有效调整处理云端数据增长的效率上，和在不损害终端用户体验的基础上保持云供应商的利益上。
如何获利
在之前的章节里，我们讨论在云端的使用及一些问题的解决方法中网络的重要作用。云端供应商可以调节自身的网络来使客户放心的将自己关键的业务转移到云上。关键是，云供应商又如何从自身的网络资产中获利呢？如果网络和服务可以被供应商以一种网络的形式提供又会怎样，NaaS呢？
根据计算和存储的需求，网络和服务可以作为一种产品来消费，计量并收费。这种经济模式也将促使网络和服务供应商改善自己的服务，使得消费者获得更有效的利益。
下面的方法可以作为网络和服务的消费项目来提供。
服务目录
关于云端服务的讨论在第3章“云分类和服务管理”中，解释了云端服务是如何提供到客户的。除了不同种类的服务定义外，服务目录页适当的增加和配置了这些服务的可选项。相同的服务目录会提供一个方法，定义和提供网络消费项目。
为了在服务目录中包含这些网络服务，它们需要被抽象出来并以较简单的形式提供给用户，因为用户可能并不是一个网络方面的专家。难懂的和复杂的操作对于用户来说应该是不可见的。简单是制胜的关键，这就要求NaaS应该简单的就只是点击几下鼠标或者是几个API的调用就可以使用的。
下面是几个服务项目的例子，都是简单并且可靠的。供应商可以将其放在自己的服务目录中。
VM和三级APP间的权限
级和三级APP间的负载均衡
独立VPN终端
数据中心的内部QoS
这些服务目录并不需要限制在网络服务里。毕竟，终端用户通过WAN或者因特网来使用网络服务。如果网络供应商拥有或可以控制下一代网络资产，那就有机会将可用的网络服务做成服务目录。
网络服务项目单（点菜单）
盈利的一个选择就是提供一个网络项目单。在这里面，网络的连接和服务可以被用户选择性的定制。这也符合开发需要。例如一个开发者需要简单的连接到数据库虚拟机，这个虚拟机独立于网络，所以不能通过路由获得，但可以从web服务器上到达。这些属性都可以作为API的一部分，如下所示：
1. 创建数据库连接
create_network(name="db-net", cidr="10.0.1.0/24")
2. 从DB VM到到网络的连接步骤1：
attach_vm(vm=vm_uuid, network="db-net")
3. 到web服务器的连接
create_route("web-net","db-net", "local")
一个设计良好的API可以让用户很容易的实现他们想要的功能：例如，一个支持很大带宽的网络，或者一个服务监测网络。这个API将底层网络抽象成统一的接口给用户调用。
这篇关于CIO的困境：云端网络设计与服务的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
