4个技能构造多云利用程序（4个技能构造多云利用程序是什么）

通常有两类气力推动围绕多云的讨论：自由选择组织所需的云计算工具和平台，和这些选择带来的复杂性。

　　这其实不总是那末容易，但组织有多种方法可以构造IT架构，提供跨环境的一致性并避免供应商锁定。企业需要遵守获得有关如何构造多云利用程序并了解什么时候不值得这样做的建议。

　　不管是产生中断、价格变化、与供应商的关系破裂，还是其他缘由，很多企业都希望构造自己的利用程序，以便在认为适合的时间和地点移动代码。

　　但是，编写与云计算无关的代码不单单触及避免使用特定于平台的工具。以下是构造可在多个云平台上使用的利用程序时需要记住的4个因素：

　　1.不要在源代码中包括密码和API（Application Programming Interface）密钥等敏感信息。

　　2.为利用程序提供单一入口点。要最大限度地下降故障点风险，使用循环域名系统记录在云计算提供商之间分配负载。

　　3.尽量自动化以最小化复杂性。

　　4.不要完全排除本机工具。云计算供应商可能具有真正独特、有价值的服务，或避免使用特定工具的本钱可能高于供应商锁定的风险。

　　斟酌什么时候和如何计划可迁移性

　　组织优化其特定云平台的工作负载越多，以后移动这些利用程序就越困难。如果IT团队想要取得可迁移性，他们需要了解使用的服务的含义和如何将利用程序锚定到给定平台。

　　举例来看，云计算提供商推动与其竞争对手进行功能奇偶校验，但这其实不一定能够更轻松地在云平台之间迁移工作负载。即便两个提供商具有可比较的服务，它们也经过不同的API提供。开发人员需要重写组件才能在其他云平台上工作。

　　虽然如此，迁移性其实不是万能的。事实上，从长远来看，即便本钱较高，找到合适工作负载的适合平台也会更具本钱效益。如果企业具有深度互联的利用程序，最好将它们托管在自己的数据中心内，以限制流量费用、集成和安全问题。

　　克服平台差异

　　部署多云战略的组织需要弥补利用程序部署在不同云中的履行方式不同的事实。企业可以经过限制扩大到一个云平台，在不同的云平台中运行并行部署或抽象某些组件来实现这一目标。

　　如果组织使用诸如Apache Meos或Kubernetes之类的软件将部署同质化，以抽象利用程序平面或使用诸如Ansible、Chef或Puppet之类的DevOps工具，则会采取范围和重新部署方法。

　　运行并行部署与扩大和重新部署方法类似，但事务和其他任务是同享的。这将需要在重复的利用程序组件之间使用负载均衡器，但不需要特殊的部署技术，由于只有工作在云平台之间移动。

　　当利用程序组件需要跨云平台进行扩大或故障转移时，IT团队可使用基于适配器设计模式的某种私有中间件。这会将不同的云平台提供程序API拉入单个API，然后开发人员可使用它。如果提供商的服务不同，则创建更高级别的抽象，以将组织的API映照到每一个云中的特定功能。

　　简化延续集成和延续交付(CI/CD)管道

　　与云计算提供商无关的延续集成和延续交付(CI/CD)管道可以简化多云利用程序的部署进程，如果IT团队选择采取这类方式，则可以选择多种方案。

　　大多数云计算供应商都支持安全文件传输协议。虽然它容易出错，但开发人员可使用它来交换、更新或删除端点，同时保持部署的性质。

　　IT团队还可使用容器来集中利用程序构造，并避免在多个环境中部署全部利用程序代码。利用程序映像可以保存到任何云都可以访问的容器存储库中，开发人员可使用给定提供程序的编排工具来启动利用程序映像。

　　如果企业依然想要使用一些云原生服务，还有其他一些技能可以解决依赖性分发，虽然它们可能会下降可迁移性并增加复杂性。举例来看，如果只有一个提供商具有上传内容交付网络资产的工具，请确保每次使用该云平台将内容上传到该CDN，即便目标是另外一个云平台。

　　不管采取哪一种方法，企业还必须肯定将在每一个环境中运行的部署后任务，以便平衡云中的负载。一样，更多的云平台会增加复杂性，因此请注意利用程序依赖的托管功能和需要额外管道自制的方式。

免责声明：
本网址（www.yingxiongyun.com）发布的材料主要源于独立创作和网友匿名投稿。此处提供的所有信息仅供参考之用。我们致力于提供准确且可信的信息，但不对材料的完整性或真实性作出任何保证。用户应自行验证相关信息的正确性，并对其决策承担全部责任。对于由于信息的错误、不准确或遗漏所造成的任何损失，本网址不承担任何法律责任。

本网站所展示的所有内容，如文字、图像、标志、音频、视频、软件和程序等的版权均属于原创作者。

如果任何组织或个人认为网站内容可能侵犯其知识产权，或包含不准确之处，请即刻联系我们进行相应处理。