准备云架构

简化架构迁移到云端流程的 7 个步骤

相关内容

指点多云的迷津:成功的 5 大原则 ›

正如虚拟化技术彻底变革了 IT 基础架构一样,云的崛起再次改变了竞争格局。

阅读电子书 ›

直面现实:大部分 IT 架构都非常复杂。如果您正在考虑迁移到云端,那么您就应当重点关注到迁移中架构和企业本身需要做出的巨大调整。

值得欣慰的是,如果您和大部分公司一样,曾经已多次经历过这一流程。大约每三到五年,您就会针核心架构进行一次彻底改造。您会调整应用交付方式、努力提高性能、增强安全性并降低成本。

但糟糕的是,云会让这些工作变得更复杂。您可能无法再完全掌握服务,可能无法以硬编码连接或以原有的方式运行。您会面临阵痛。但正如古话云:“没有痛苦,何来收获”,对吧?因此您需要规划好用户行为、连接性和适当的带宽。

为了让您更平稳顺利地过渡,我们提炼了七个重要的步骤帮助您做好准备。

1. 评估您已拥有的应用

您的应用状态如何?您拥有多少应用?这些应用对业务的重要程度如何?这些应用存有哪些类型的数据,以及最重要的是,这些应用之间的依赖关系如何?

首先请思考一下您的应用属于哪些类别。您有以下四种选项:

  1. 采用 SaaS
  2. 迁移到云端
  3. 采用混合环境
  4. 保持原样

2. 确定哪些应用适合外包给 SAAS

首先从简单的部分做起。确定您产品组合中属于虚拟商品的应用。您可能会发现有很多。但您真的还需要为自建的 Exchange 服务器、过时的 HR 系统或自研的销售自动化工具提供支持吗?这些应用是否值得您的团队投入精力,或者是否还能够值回您的 OpEx?如果不值,欢迎您订购销售、HR、生产力工具或其他适合的解决方案,这样可以省去许多麻烦。让第三方承担这些繁重的工作。通过 SaaS 您可以迅速获得显著的改进。

3. 分析并确定其余的应用

下一步,您需要评估其余的应用,并确定将哪些应用迁移到云端、哪些应用需要为云端重构、哪些应用保持原样。

您需要自问以下几个问题:

-     如果我们要迁移应用 X,会中断多少系统?
-     数据存储在哪里?
-     依赖关系如何?
-     用到了哪些网络服务?
-     哪些应用需要有正常程序和协议的解决方法才能运行?

对于大部分应用而言,您可能已经拥有这些问题的答案了。但对于其余应用,可能只有当您真正开始试着迁移时才会找到答案。受损风险越大、关系越复杂、对依赖关系了解越少,您就越有可能将应用保持原样。

当您在描绘依赖关系时,请务必做好记录。这会给您带来巨大的益处,即使最后您只有少数应用迁移到了云端。

4. 标准化

检查应用交付策略,寻找标准化和自动化的契机。您应当制定有限的标准负载均衡策略(比如 10 个),而不是为每个应用手动调整配置。您需要确定标准化的存储层、制定标准化的网络服务。请与开发人员讨论标准化的好处,并获得他们的认可。制作模板帮助他们更加快捷轻松地进行部署。

5. 简化并保护访问权限

自问一下哪些人员可以访问各个应用,以及从何处访问。您必须规划好用户行为、连接性和适当的带宽。您试图迁移到云端(无论是私有云还是公有云)的应用中,大部分都需要能够随时随地更轻松地访问。将应用迁移到云端能够减少基础架构的压力。

此外,还有身份验证和安全问题:大部分企业一直以来习惯于使用网络控制措施,而不是应用控制措施来确定访问权限。在公有云中,您需要采用前所未有的全新身份识别和访问权限管理技术。

6. 规划架构

在迁移到云端时,由于云端结构不是静止不变的,因此架构也需要有所调整。对于数据库之类庞大而单一的应用,以往绑定特定 IP 地址或其他固定结构的机制在云端无法起到作用。您可能需要额外的负载均衡程序或代理,从而帮助您在不断变化的环境中提供一致性。您还需要设置额外的控制点,确保所有人都可以持续访问应用,而不会受到中断。

7. 切记这绝非易事

迁移的过程充满艰辛。正如我们在开头所说的,IT 架构非常复杂。

尽管并不轻松,但光从节省成本(OpEx 和 CapEx)和可扩展性的角度来说就已经物超所值了。部分企业仅仅在云端部署的准备阶段就已经节省了大量成本。通过评估现有的应用库存、分析依赖关系、记录所有信息、尽可能标准化和简化,您就可以从最有利的角度审视哪些应用需要迁移以及该如何迁移。 

探索更多

文章

您能否承受住过多的应用?

应用是现代企业的支柱。但俗话说过犹不及,应用过多是否反而会给我们带来负面影响?

解决方案

DevOps 解决方案自动化

避免 DevOps、NetOps 和 SecOps 团队互相拖累。请选择进行自动化。

客户案例

MAXIMUS 与 F5 共同简化运营

Mimulu 向 F5 寻求协作,从而无缝迁移到 AWS,并实现流程自动化和资源释放。