在最近的一篇文章中 Joe McKendrick 质疑当前的一些平台即服务（PaaS）方法是否会像其他依赖于厂商的 SOA 衍生品一样，成为厂商依赖的潜在机会。正如他所说，虽说 PaaS……
[……] 本质上提供了一个随需应变的数据中心，其服务器、存储介质和中间件都由提供商管理。但是你不会想要把自己的需求强加于某一单个厂商。
Joe 引用了 Lori MacVittie 的一篇文章，文中区分了云中的两个概念，可迁移性和可移植性。
前者意味着从一个环境迁移到另一个环境而无需作任何修改，而后者允许了跨平台（或者在这里，跨云）的部署。迁移性无需重新编译，无需对应用本身重定向，而事实上，移植性对两者可能都有需要。
Lori 指出，各厂商近来的宣传实质都是关于移植性而非迁移性，这些宣传可能从一开始就是概念不清晰的。诚然，目前总有一些方面可能是会限制云中的迁移性，比如，当你选择某一特定的语言，如 Java，有些 PaaS 方案可能就不提供支持。尽管如此，正如 Lori 指出的那样，目前 PaaS 方法的另一些方面可能并未明显受限于迁移性。
[……] 对一些私有平台服务的使用，比如提供数据，队列和邮件。[近期的一些宣传] 提及到的“利用”或者“影响”平台服务的能力，当其建立于一种旨在帮助客户避免云“依赖” 的环境中时，这种说法就极具讽刺意味，因为当一个组织决定和 PaaS(平台即服务) 方案提供的私有服务集成时，厂商依赖几乎是无法避免的。[……] 这样的平台服务是特定厂商私有的、封闭的、无移植性可言的。它们是那种一旦应用依赖上，就“无法摆脱” 的服务。
所以无论客户怎么想，他们都会对这些平台产生依赖。当然，类似的警告早在 2008 就由 Rich Stallman’s 提出，殊途同归，几乎同时 Tim Bray 也提出了类似的警告。正如 Stallman 回应的那样：
使用自由软件的拷贝在自己的计算机上实现计算。如果你在使用一个私有程序，或者他人的 Web 服务，你是毫无抵抗力的，你将受制于开发这个软件的人。
Joe 指出，尽管如此，这些问题同样困扰着其他软件方法论，比如 SOA（事实上，像大部分读者将会意识到一样，厂商依赖一直是个常态，在 SOA 出现前就一直存在）：
Lori 提出的问题与面向服务世界一直力图解决的问题是同一个问题——换言之，公司过分或专门依赖某一特定厂商的环境，从而限制了整个公司内部或公司间不同应用筒仓之间的互操作性。
近几年我们目睹了为尽可能使 SOA 技术标准化所做的越来越多的努力，包括各种各样的 WS-* ， SCA ， JAX-WS 以及 JBI 。鉴于 Lori 的定义，这些标准可以帮助解决可迁移性和（或）可移植性，以及某些情况下的互操作性。所以解决厂商依赖问题的第一步应该是标准化，尽管这样，标准化的建立也不可急于求成，因其未必一定会成功。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论