简化将架构迁移到云的 7 个步骤。
好消息是，如果您像大多数公司一样，您以前就已经这样做过了。 很多次。 大约每三到五年你就会对核心架构进行彻底检查。 您可以调整交付应用的方式。 您努力提高性能、增强安全性并降低成本。
坏消息是，有了云，事情就会变得更加复杂。 您可能无法控制服务。 您可能无法对连接进行硬编码或按照老方法做事。 会有些疼痛。 但是，就像人们说的，“没有付出就没有收获”，对吧？ 您必须规划用户行为、连接性和适当的带宽。
为了使过渡更加顺利，我们整理了七个重要步骤来帮助您入门。
你的应用状态如何？ 你有多少个？ 它们对您的业务有多重要？ 它们保存什么类型的数据？最重要的是，它们之间有什么依赖关系？
开始思考您的应用程序将属于哪些类别。 您有四个选择：
先做简单的部分。 确定您的投资组合中属于虚拟商品的应用程序。 你很可能拥有很多这样的人。 您是否真的需要支持您自己的 Exchange 服务器、过时的 HR 系统或自主开发的销售自动化工具？ 它们是否值得您的团队付出努力或承担运营成本？ 如果没有，请通过订阅销售、人力资源、生产力或其他适当的解决方案来省去很多麻烦。 让第三方承担您的繁重工作。 您将通过 SaaS 获得明显的、快速的收益。
接下来，您需要评估剩余的应用程序并决定将哪些应用程序移动到云中，哪些应用程序将为云进行重构，哪些应用程序保持原样。
问自己以下问题：
- 如果我们迁移应用程序X，会有多少东西被破坏？
- 数据存储在哪里？
- 依赖关系有哪些？
- 他们使用什么网络服务？
- 哪些应用程序需要通过正常程序和协议的变通方法才能正常运行？
您将会找到针对许多应用程序的这些问题的答案。 对于其他人来说，您可能直到真正尝试移动它们时才知道答案。 发生故障的风险越大，依赖关系越复杂且不为人所知，您就越有可能将应用程序保持在原位。
当你映射出这些依赖关系时，请将其记录下来。 即使只有少数应用程序最终进入云端，这也很有用。
检查您的应用交付政策并寻找标准化和自动化的机会。 您应该有有限数量的标准负载均衡策略（例如 10 个），而不是为每个应用程序手动调整配置。确定标准化的存储层。 定义标准化的网络服务。 与您的开发人员讨论标准化的好处并获得他们的承诺。 制作模板来帮助他们快速、轻松地部署事物。
问问自己谁将会访问每个应用程序以及从哪里访问。 您必须规划用户行为、连接性和适当的带宽。 您想要迁移到云的许多应用（无论是私有云还是公共云）可能都需要从任何地方更容易访问。 将它们迁移到云端将减轻基础设施的压力。
另外还存在身份验证和安全问题；大多数企业传统上都使用网络而不是应用程序控制来确定访问权限。 在公共云中，您可能需要采用以前没有的新身份和访问权限管理技术。
当迁移到云时，架构将会有所不同，因为结构不是静态的。 对于数据库等单体应用，以前与特定 IP 地址或其他常量结构绑定的机制在云中无法发挥作用。 您可能需要额外的负载均衡器或代理来帮助在不断变化的环境中提供一致性。 设置额外的控制点，以便确保每个人都能一致、无中断地访问您的应用程序。
这是件很难的事。 正如我们一开始所说，IT 架构很复杂。
虽然这可能并不容易，但仅从节省成本（运营支出和资本支出）和可扩展性来看，它还是值得的。 一些企业仅仅通过为云计算做好准备就实现了巨额的节省。 通过评估您现有的应用程序库存、分析依赖关系、记录所有内容以及尽可能地标准化和简化，您将能够完美地决定移动什么以及如何移动。