值得欣慰的是,如果您和大部分公司一样,曾经已多次经历过这一流程。大约每三到五年,您就会针核心架构进行一次彻底改造。您会调整应用交付方式、努力提高性能、增强安全性并降低成本。
但糟糕的是,云会让这些工作变得更复杂。您可能无法再完全掌握服务,可能无法以硬编码连接或以原有的方式运行。您会面临阵痛。但正如古话云:“没有痛苦,何来收获”,对吧?因此您需要规划好用户行为、连接性和适当的带宽。
为了让您更平稳顺利地过渡,我们提炼了七个重要的步骤帮助您做好准备。
您的应用状态如何?您拥有多少应用?这些应用对业务的重要程度如何?这些应用存有哪些类型的数据,以及最重要的是,这些应用之间的依赖关系如何?
首先请思考一下您的应用属于哪些类别。您有以下四种选项:
首先从简单的部分做起。确定您产品组合中属于虚拟商品的应用。您可能会发现有很多。但您真的还需要为自建的 Exchange 服务器、过时的 HR 系统或自研的销售自动化工具提供支持吗?这些应用是否值得您的团队投入精力,或者是否还能够值回您的 OpEx?如果不值,欢迎您订购销售、HR、生产力工具或其他适合的解决方案,这样可以省去许多麻烦。让第三方承担这些繁重的工作。通过 SaaS 您可以迅速获得显著的改进。
下一步,您需要评估其余的应用,并确定将哪些应用迁移到云端、哪些应用需要为云端重构、哪些应用保持原样。
您需要自问以下几个问题:
- 如果我们要迁移应用 X,会中断多少系统?
- 数据存储在哪里?
- 依赖关系如何?
- 用到了哪些网络服务?
- 哪些应用需要有正常程序和协议的解决方法才能运行?
对于大部分应用而言,您可能已经拥有这些问题的答案了。但对于其余应用,可能只有当您真正开始试着迁移时才会找到答案。受损风险越大、关系越复杂、对依赖关系了解越少,您就越有可能将应用保持原样。
当您在描绘依赖关系时,请务必做好记录。这会给您带来巨大的益处,即使最后您只有少数应用迁移到了云端。
检查应用交付策略,寻找标准化和自动化的契机。您应当制定有限的标准负载均衡策略(比如 10 个),而不是为每个应用手动调整配置。您需要确定标准化的存储层、制定标准化的网络服务。请与开发人员讨论标准化的好处,并获得他们的认可。制作模板帮助他们更加快捷轻松地进行部署。
自问一下哪些人员可以访问各个应用,以及从何处访问。您必须规划好用户行为、连接性和适当的带宽。您试图迁移到云端(无论是私有云还是公有云)的应用中,大部分都需要能够随时随地更轻松地访问。将应用迁移到云端能够减少基础架构的压力。
此外,还有身份验证和安全问题:大部分企业一直以来习惯于使用网络控制措施,而不是应用控制措施来确定访问权限。在公有云中,您需要采用前所未有的全新身份识别和访问权限管理技术。
在迁移到云端时,由于云端结构不是静止不变的,因此架构也需要有所调整。对于数据库之类庞大而单一的应用,以往绑定特定 IP 地址或其他固定结构的机制在云端无法起到作用。您可能需要额外的负载均衡程序或代理,从而帮助您在不断变化的环境中提供一致性。您还需要设置额外的控制点,确保所有人都可以持续访问应用,而不会受到中断。
迁移的过程充满艰辛。正如我们在开头所说的,IT 架构非常复杂。
尽管并不轻松,但光从节省成本(OpEx 和 CapEx)和可扩展性的角度来说就已经物超所值了。部分企业仅仅在云端部署的准备阶段就已经节省了大量成本。通过评估现有的应用库存、分析依赖关系、记录所有信息、尽可能标准化和简化,您就可以从最有利的角度审视哪些应用需要迁移以及该如何迁移。