写点什么

关于“使用云的混合架构”的三大误区

  • 2019-11-11
  • 本文字数:2033 字

    阅读完需:约 7 分钟

关于“使用云的混合架构”的三大误区

“人生最难的就是要学会哪座桥可以过,哪座桥可以烧。”–David Russell


在以首席信息官的身份负责多个基于云服务的业务解决方案的交付工作时,我开始对混合架构有了一些自己的看法。在过去的 5 个月里,我有幸与大公司的首席信息官和首席技术官进行了数十次对话,这进一步加深了我对这个主题的想法。与此同时,我阅读了许多讨论混合架构的文章和博客,我看不出行业对采用云技术的混合架构是否达成了共识。


公司出于各种不同的原因采用云技术。云采用者已获得敏捷性提高、成本降低和全球影响力扩大等优势。对于我接触过的许多首席信息官来说,实际上可归结于它能够将宝贵资源充分转化为能够促进业务发展的资源。换句话说,将与管理基础设施相关的千篇一律的繁重工作转化为与构建其品牌知名产品和服务相关的活动。


也就是说,大多数企业的 IT 组织已经建立了他们今天所运营的基础设施和管理模式。我接触过的许多首席信息官希望尽快将这一基础设施迁移到云,但必须认识到,有意义的云采用是一个需要时间的过程。在迁移到云的过程中,公司需要一种能够保持系统正常运行同时充分利用其现有投资的方法。在我撰写的有关企业云之旅的文章中,我讨论过公司应该如何使用 AWS Virtual Private Cloud (VPC) 和 Direct Connect 将其本地基础设施拓展到 AWS 上,以创建混合架构。对我来说,这是最有意义的混合架构,也是许多公司在最大限度地利用云的优势时所采取的步骤。


除此之外,关于混合架构的对话就变得有些复杂了。我在市场评论中发现了三个趋势,初看起来挺有道理,但稍一深入分析,就会发现这些观点站不住脚。这三个误区是:


误区一:混合架构是永久目的地。用“永久”来形容这一观点有些太过绝对了。拥有大量陈旧系统的大型公司将运行混合云架构一段时间 (可能是以年计数)。每个组织的云之旅会有所不同,每个人都将按照自己喜欢的步伐前进。但是,我认为未来不会有太多公司运营自己的数据中心。其淘汰过程可能需要 3 年以上的时间,但我确信这一定会在 15 年内实现。能够加速这一转型的因素至少有四个:


  1. 云提供商实现的规模经济效应将随着采用范围的扩大而不断增长。这些优势终会通过这样或那样的方式令云消费者受益。

  2. 云技术的创新步伐是前所未有的。2014 年,AWS 发布了超过 515 项增强功能,近 3 年来创新速度几乎翻了一番。

  3. 公司运行业务所依赖的技术 (如电子邮件、生产力、人力资源、CRM 等) 越来越多地构建在云中。

  4. 有助于企业迁移到云的技术和业务的数量正在迅速增长。您看看 AWS MarketplaceAWS 合作伙伴网络就知道了。


误区二:混合架构允许您在本地基础设施与云之间无缝迁移应用程序。表面上看起来好像很有吸引力,但这个前提有一个根本性的缺陷。它假定云和本地基础设施具有同样的能力。我知道很多公司都具备管理其基础设施的能力。与此同时,有很多公司是想要获得其数据中心不具备的功能和特性才迁移到云的,这些功能和特性有:真正的弹性、安全性、随用随付、持续不断的创新流等。您在设计应用程序的架构时,如果想要在自己的数据中心和云间无缝切换,则您的应用程序的功能就只能限定为数据中心和云都具备的功能集合。


误区三:混合架构允许您跨多个云提供商无缝地代理您的应用程序。我认为,这个论点有一个细节值得探讨。公司正在使用各种不同的云解决方案来满足其业务需求。这通常包括基础设施服务的混合,以及运行在公司数据中心之外的其他地方 (通常是在 AWS 上) 的打包解决方案。这完全讲得通。IT 高管应该关注他们试图解决的问题,并根据其面临的限制条件挑选最佳的工具来解决它。


但令我感到惊讶的是,很多公司掉入了陷阱之中:他们尝试构架单一应用程序来在多个不同的云提供商的服务上运行。我明白工程师为什么喜欢这样做 —  – 对工程师来说,造出能够使不同的云协同工作所需的“胶水”是一项莫大的成就。但遗憾的是,这种工作会抵消组织迁移到云所获得的生产力提升。我一直认为这是一种倒退的举动。除了管理自己的基础设施以外,您现在还需要解决多种服务的差异性问题。跟误区二一样,这也会将其应用限制到所有架构共有的功能集合。


我也明白,公司选择这条路线是想让供应商保持诚实,同时避免束缚于单个云提供商。我认为,首先,大型云提供商倒闭的可能性不大,而且云计算行业不太可能会朝着惩罚性商业策略的方向发展。其次,我觉得一定有更好的办法来减轻这种顾虑。使用已知的自动化技术构架应用程序的公司将能够可靠地重现其环境。这种最佳实践使他们能够充分发挥云的弹性优势,并将应用与基础设施分离。如果这一点做得足够好,迁移到其他云提供商 (如果有充分理由需要这样做的话) 就变得不那么重要了。


做出技术选择有时并不容易,而且很难做到完美无憾。但创建混合架构并不一定如此。我很乐意倾听您的想法。请留言加入讨论。


不断前进


-Stephen


orbans@amazon.com


@stephenorban


http://aws.amazon.com/enterprise/


本文转载自 AWS 技术博客。


原文链接:


https://amazonaws-china.com/cn/blogs/china/three-myths-about-hybrid-architectures-using-the-cloud/


2019-11-11 08:00421

评论

发布
暂无评论
发现更多内容

架构训练营 - 第 13 周课后作业 - 学习总结

Pudding

测开之函数进阶· 第7篇《装饰器装饰类,通用装饰器,有啥区别呢?》

清菡软件测试

测试

抽象照进现实

型火🔥

抽象 视觉化

架构师训练营 - 大作业一

Pudding

Vue 3 组件开发:搭建基于SpreadJS的表格编辑系统(环境搭建)

葡萄城技术团队

Vue SpreadJS vite

电商平台如何激发内容生态

马踏飞机747

内容 内容分发网络 电商

案例展示自定义C函数的实现过程

华为云开发者联盟

数据库 数据 C语言 字符串

深圳区块链交易所开发、数字货币交易平台开发

W13902449729

深圳区块链交易所开发 数字货币交易平台开发

2020 — iOS 面试败北感悟

iOSer

ios 面试 iOS Document 底层知识

软件测试--中间件介绍

测试人生路

软件测试 中间件

OpenKruise 2021 规划曝光:More than workloads

阿里巴巴云原生

阿里云 开源 容器 云原生 调度器

架构训练营 - 第12周课后作业 - 学习总结

Pudding

Linux的进程pid编号极限

程序员架构进阶

Linux 进程

架构师训练营 - 第 13周课后作业(1 期)

Pudding

Appium的安装及简单的使用介绍

行者AI

人工智能

深度解析!滴滴内部开源Spring IoC和AOP源码小册

Java架构追梦

Java spring 架构 aop ioc

云原生2.0时代,华为云DevOps立体运维实践

华为云开发者联盟

DevOps 运维 云原生 华为云

如果腾讯、阿里是弱生态,那么谁是强生态?

ToB行业头条

从根上理解高性能、高并发(三):深入操作系统,彻底理解I/O多路复用

JackJiang

网络编程 高并发 高性能 即时通讯

Linux进程知识干货|收藏

赖猫

c++ Linux 后台开发 运维

分布式身份:重新定义你的“身份”管理

华为云开发者联盟

区块链 数据 隐私保护 分布式身份标识

anyRTC 2020年12月SDK更新

anyRTC开发者

uni-app android 音视频 WebRTC sdk

这些常用ETL任务调度框架组件,你都知道几个?

TASKCTL

大数据 kettle 海豚调度 调度引擎 调度式分布

敏捷团队的质量保障赋能

BY林子

质量保障 质量赋能 敏捷测试

四年三次获奖,PostgreSQL再度荣获“年度数据库”桂冠!

PostgreSQLChina

数据库 postgresql 开源

如何防止短信验证码接口被恶意调用攻击?

香芋味的猫丶

短信 短信防刷 接口安全 验证码

Java并发编程:AQS的公平性

码农架构

Java Java 分布式 java 并发

万字长文聊缓存(下)- 应用级缓存

Silently9527

缓存 缓存击穿 Caffeine 缓存架构

获奖名单|七日更挑战成功!

InfoQ写作社区官方

奖品 七日更 热门活动

架构师训练营 - 大作业二

Pudding

IT2.0:中台构建还应从企业业务实际出发

华为云开发者联盟

区块链 分布式 安全 数据 身份安全

关于“使用云的混合架构”的三大误区_语言 & 开发_亚马逊云科技 (Amazon Web Services)_InfoQ精选文章