准备云架构
简化架构云迁移的7个步骤
必须承认，大多数IT架构都很复杂。如果正在考虑迁移到云端，您有理由担心迁移过程中架构乃至整个组织需要进行的大规模变革。
好消息是，如果贵公司和大多数企业一样，那么这样的转型已经经历过很多次。大约每3至5年，企业都会全面调整核心架构，改变应用交付方式，力求提升性能、增强安全性并降低成本。
坏消息是，采用云后，情况会更加复杂。您可能无法控制相关服务，也可能无法对连接进行硬编码或继续沿用旧方法。这个过程难免会遇到一些困难。不过，常言道，“一分耕耘，一分收获”，不是吗？您需要针对用户行为、连接能力和适当的带宽做好规划。
为了让过渡过程更顺畅一些，我们整理了7个重要步骤，帮助您顺利起步。
1. 评估现有资源
您的应用目前状况如何？共有多少个应用？这些应用对业务有多重要？其中存储了哪些类型的数据？最重要的是，它们之间存在哪些依赖关系？
开始考虑您的应用应归入哪些类别。共有四种选择：
- 采用SaaS
- 迁移到云端
- 采用混合环境
- 将其保留在原处
2. 确定哪些应用适合外包给SaaS服务商
先从简单的部分着手。找出应用组合中那些已高度标准化的应用，这类应用可能有很多。真的有必要自行支持Exchange服务器、过时的人力资源系统或自研的销售自动化工具吗？它们值得团队投入精力并承担相应的运营支出吗？如果不值得，可以订阅销售、人力资源、生产力或其他合适的解决方案，省去许多麻烦。将繁重的工作交给第三方处理，借助SaaS快速取得显著成效。
3. 分析并决定其余应用的处理方式
接下来，需要评估其余应用，并决定哪些应用要迁移到云端，哪些要针对云环境进行重构，以及哪些保持不变。
请思考以下问题：
- 如果迁移应用X，会有多少项功能出现故障？
- 数据存储在哪里？
- 存在哪些依赖关系？
- 这些应用正在使用哪些网络服务？
- 哪些应用需要绕过常规流程和协议才能正常运行？
对于许多应用，您已经掌握了这些问题的答案。对于其他应用，可能只有实际尝试迁移后才能找到答案。应用出现故障的风险越高，依赖关系越复杂、越不明确，就越有可能将其保留在原有环境中。
在梳理这些依赖关系时，请将其记录下来。即使最终只有少数应用迁移到云端，这些记录也会很有用。
4. 标准化
审查应用交付策略，寻找实现标准化和自动化的机会。应将标准负载均衡策略控制在有限数量内，例如10项，而不是为每个应用手动调整配置。确定标准化的存储层级。定义标准化的网络服务。向开发人员说明标准化的优势，并争取他们的支持。创建模板，帮助他们快速、轻松地完成部署。
5. 简化并保护访问
需要考虑谁会从何处访问每个应用。必须针对用户行为、连接性和适当的带宽进行规划。许多计划迁移到云端的应用，无论是私有云还是公有云，都可能需要支持从任何位置更便捷地访问。将这些应用迁移到云端可减轻基础设施的压力。
此外，还需要考虑身份验证和安全问题。传统上，大多数企业使用网络控制而非应用控制来确定访问权限。在公有云中，您可能需要采用以前未使用过的新型身份和访问管理技术。
6. 规划架构
迁移到云端时，由于各项构造并非静态不变，架构也会有所不同。对于数据库等单体应用，原先绑定到特定IP地址或其他固定构造的机制在云端将无法正常工作。您可能需要增加负载均衡器或代理，以帮助在不断变化的环境中保持一致性。请增设控制点，确保所有人都能持续、顺畅地访问您的应用。
7. 切记，这并非易事
这并非易事。正如开篇所述，IT架构十分复杂。
虽然这并不容易，但仅凭运营支出（OpEx）和资本支出（CapEx）的节省以及可扩展性，就值得付出努力。有些企业仅通过为上云做好准备，就实现了大幅成本节省。通过评估现有应用清单、分析依赖关系、完整记录相关信息，并尽可能实现标准化和简化，您将能更好地决定迁移哪些内容以及如何迁移。
