IT外包服务 强大的SOA治理是控制云的关键从某种意义上说起
云计算主要是指一种按需提供服务的模式，可以覆盖外包和企业内部的各种平台，成为一种新的流行的服务模式。
然而，云计算也让一些IT人士苦恼，他们担心云服务可能会绕过企业苦心打造的SOA治理工具的管辖。
在为企业的 Web 服务环境煞费苦心地实施生命周期管理之后，这些 IT 专业人员发现他们可能必须重新开始，才能跟上外包云服务的繁荣。
SOA治理（）也称为服务治理，是指用于对一些关键功能的生命周期实施一致的研发、安全管理、性能管理等策略的规则和工具，无论是托管在内部还是外部。事情。
有效的 SOA 治理极其重要。它使组织能够持续规划、设计、验证、发布、配置、监控、纠正、保护和优化他们的分布式环境，确保服务部署在企业应用环境（无论是构建在云端），还是构建在大型机上或任何其他平台）完全符合各项管理规范、管理政策、运营规范等基本原则。
强大的 SOA 治理是控制云的关键
从某种意义上说，云计算可能会成为SOA治理领域的重中之重，因为云计算的存在使得SOA治理变得越来越重要。
从理论上讲，“云”几乎可以将任何形式的IT功能——从应用到中间件、应用平台，甚至存储、进程等硬件资源转化为按需订阅的服务模式。
但是 IT 经理如何在云计算世界中实施健全的治理？
AG 副总裁兼代理 CTO Miko 表示：“云计算重新点燃了管理人员对治理的兴趣，因为您必须跨场所甚至可能跨公司边界管理服务。” “这不仅从治理的角度来看是有益的，而且跨场所集成云计算应用程序和基础设施的复杂性需要一个治理框架来保持一切就绪。”
换句话说，云计算使 SOA 治理的前景复杂化。如果没有合适的治理框架，任何人都可以根据自己的意愿随时部署新的云服务。任何人都可以随意编排云服务。服务，导致环境模型太复杂而无法添加。
此外，云服务通常与企业的核心 SOA 环境存在根本冲突，结果是 IT 部门无法确保最佳治理实践（如果有的话）适用于这个新环境。
许多企业为支持 Web 服务而部署的组件，如服务登录门户、服务级别管理代理和控制台，在许多公共或私有云环境中要么部分缺失，要么完全缺失。
从 SOA 专家的角度来看，云环境是未记录、未支持和未标准化的应用程序服务的温床。试想，如果企业内部的用户未经批准就开始访问外部提供的云服务，会造成怎样的混乱？
此外，外包云服务可能不遵守企业 IT 部门在企业内部构建 SOA 时遵守的任何 Web 服务标准，例如 XML、SOAP（简单对象访问协议）、WSDL（Web 服务描述语言）和UDDI（通用描述发现和集成）等标准。
杂乱无章的公有云服务就像藤蔓在不知不觉中爬墙而过，正在牢牢渗透到企业IT环境中，并且还在抵制企业的一切扫除努力。如果这些不速之客真的在企业的运行环境中生根发芽，那么企业的IT部门就会发现，这种情况会严重阻碍对这些服务的监控或控制，使其符合企业的设计、维护和监控。服务。、安全和升级等方面的标准规范工作。
治理需要新工具
除了对云服务合规性的担忧，对云计算缺乏了解也是一个令人担忧的因素。当然，如果云计算逐渐成为主流，这种担心终究会消失，但现在看来，这还需要一个过程。
企业在一定程度上采用云服务后，会选择性地外包一些特定的应用和基础设施。“云”/SOA 治理决策的首要原则之一是决定哪些服务应该外包给公共云，以避免不必要的内部应用程序环境重复。
“重大业务决策必须围绕哪些服务应该或不应该外包做出。此外，它必须是适度的，风险必须是可控的。” 该公司首席分析师达纳说。“一个风险是，当人们第一次进入‘云’时，他们通常会零碎地使用外部服务，因此没有治理或集中管理，更不用说全面的治理计划了。”
他补充说，“另一个风险是，企业被严格禁止使用云服务，并严格执行集中管理制度，因此他们根本无法利用云计算带来的任何好处。那么企业也将承担由此产生的机会成本，并且新技术的快速采用不会损害适应和创新的能力。”
在接下来的几年里，IT 经理应该能够看到大量 SOA 治理工具涌入云市场。“拥有最好的 SOA 规则，准备好更新的治理工具和更高的效率，并在服务和资源之间实施强有力的治理措施将为 IT 带来巨大的好处，”说。
云服务使 SOA 治理复杂化
由于围绕云服务进行了如此多的炒作，因此很难找到在这种新环境中进行有效 SOA 治理的合适案例研究。然而，大多数公共云服务提供商提供各种治理工具来管理应用程序、虚拟机、集成逻辑和服务级别的部署。随着此类供应商数量的增加，用于在公共和私有云环境中配置和管理服务的工具也在增加。当然，由于云计算还处于不成熟阶段，目前还没有成熟的SOA治理工具供应商能够支持基于云的应用程序、事务处理、消息或服务级别管理。
而且，即使云服务成为主流，即使云服务厂商按照SOA治理规范构建云服务，对于管理来说仍然是一个巨大的挑战。这一挑战主要来自于这样一种新的、复杂的模式组合：外包服务提供商、专有公有云、虚拟化资源池和混搭服务构建。
全面的 SOA 治理依赖于所有应用程序、平台和网络域都处于共同的基于策略的管理之下，或基于自治域的“联邦化”( )。
在企业或 B2B 供应链中，可管理的 SOA 联合可能非常复杂。但是管理一个 SOA 联邦，即连接一个内部应用域和一个或多个由外包商（包括像微软、微软、微软这样的公司）提供的外部应用域的联邦，将取决于合同谈判技巧。
联邦云有助于治理
“公共云提供商正在谨慎地接近联邦制的概念，”加州大学计算机科学教授 Rich 说。他还是开源云计算项目的负责人。“公共云之间的联盟还很少，但我们开始看到一些关于‘资源跨云联盟’的讨论。”
强调在云计算市场遇到联邦制的无数问题的同时，服务提供商和他们的企业客户需要建立一个跨越多个层次的协议来统一身份管理、服务级别管理、存储管理和其他关键性管理级别。
迄今为止，企业的 SOA 环境和公共云服务之间很少或根本没有战略联合。据系统架构及业务系统架构副总介绍，选择公有云服务的企业其实存在相当大的风险。
“当这样的企业把自己的基础设施和应用放在别人的云端时，服务商的表现就会成为企业的致命伤。” 说。“在这种环境下，公有云服务提供商几乎没有责任协调他们自己计划的停机时间与客户的应用程序运行需求。因此，构建依赖于公有云提供的服务的企业应用程序，没有就稳定性或可用性达成协议他们的 API 首先，那将是危险的。” 即使公有云的API没有问题，“这些接口有变化也不会及时通知你”。说。
建议企业的 IT 部门，很多治理特性应该写入与公有云服务提供商的合同中。至少，这些合同还应包含条款，例如，公共云服务提供商必须将停机、服务变更、新服务演示、版本回归和 API 修改等信息告知客户。
SOA 治理的一个关键原则是分布式应用程序环境应该独立于平台，它的治理基础设施也应该如此。在纯 SOA 环境中，外部 API 应该独立于它们的底层平台。
然而，当企业进入云计算市场时IT外包服务，通常总是违背这一原则，只依赖单一的公有云服务商。后者的大多数服务都具有专有 API、开发工具、虚拟化层和治理功能。虽然有很多云服务也可以在一定程度上与开放的SOA和Web 2.0标准保持一致。许多专有公共云之间的互操作性在很大程度上是不存在的，而用于管理这些不同的公共云和私有云之间的服务的工具才刚刚开始出现。
虚拟化工具供应商 rPath 的创始人兼首席战略官 Billy 表示：“为了将这些跨云服务设计成可移植的，公共云服务提供商应该为其虚拟化服务实施开放的行业标准。” “如果可以定义服务以符合开放的虚拟化格式，那么我们就可以使服务管理平台独立。”
解决此问题的一个规范是开放虚拟化格式 (OVF)，这是分布式管理任务组 (DMTF) 提出的一种标准草案，用于打包和分发在虚拟机 (VM) 中运行的软件。定义了可扩展格式。rPath 的工程副总裁 Brett Adam 表示，这是 VM 跨多个云的可移植性的关键规范，但它仍处于 1.0 版本，尚未提供对 VM“镜像”的支持。其复杂的生命周期治理所需的一切。
VM的激增进一步增加了管理难度
大多数 SOA 治理实际上只触及了企业 IT 环境的表面：仅管理应用层中某些服务的子集，以及那些构建在 XML、SOAP、WSDL 和其他核心 SOA 规范之上的 Web 服务。相比之下，很多公有云服务商可以提供深度按需服务栈、扩展应用、软件平台、集成中间件，甚至可以到达硬件层。事实上，虚拟化的、基于网格的“硬件即服务（HOA）”资源池也成为流行的云服务，提供足够的处理能力和存储能力。
因为很多云服务已经深入到企业的应用栈中，也已经超出了当今SOA治理工具的治理能力。因此，依靠传统的SOA治理工具无法实现云计算环境的统一规划、设计、配置和监控。
云治理与传统 SOA 治理之间的一个关键区别在于，前者侧重于 VM 生命周期治理。为了促进深度应用的自动配置和虚拟机堆栈的集成，云管理环境应该能够提供预先打包的“服务模板”。
这些模板嵌入了预打包的策略定义IT外包服务，控制关键生命周期服务的 VM 治理功能，包括一个或多个公共云和私有云上 VM 的部署、配置、启动、监控、控制、优化和扩展。云治理甚至可以适应“停用和丢弃”旧 VM 实例并用新 VM 实例替换它们的周期性需求。
事实上，这样的云将成为云治理的杀手级应用：防止 VM 实例在公共和私有虚拟化基础设施之间未经身份验证的扩散。增殖问题有时被称为“VM 蔓延”，代表着沉重的维护负担和对云 CPU、存储和网络资源的过度消耗。
越来越多的商业云管理工具提供了控制 VM 在各种不同环境中蔓延的能力。此外，微软、微软、公有云服务商等平台厂商都在各自的管理工具中加入了这一重要的管理功能。这种管理功能，有时称为“实例管理”，正是传统 SOA 治理工具所缺少的。
SOA 最佳实践触及云端
但是，云服务还是有很多好处值得企业SOA治理从业者学习的。惠普软件与解决方案事业部 SOA 产品经理 Tim Hall 表示，“最重要的是，你需要一个服务目录来维护与服务相关的元数据，能够控制服务卡和构建过程，并将其暴露给用户. 服务的可见性和可用性。”
此外，联邦协议还可以在公有云与企业SOA、REST等应用环境之间设置自配置的服务定义。霍尔认为，从宏观上看，服务可以直接转化为价值，可以帮助企业赚钱、省钱或降低风险。
显然，SOA 治理正在走向成熟，而云计算才刚刚起步。不幸的是，未来几年云计算领域将继续快速变化，因此很难就一致的服务治理实践达成一致。
在这个新的、狂野的状态下，如此强大的服务治理还在云端，但几颗明亮的星星已经透过云层向我们闪烁。美国《世界报》特为本报撰稿。
相关链接：混搭的泥潭
传统 SOA 治理工具的开发是自上而下的。它需要大量的前期架构设计，将各种基础功能分解为平台无关的功能，还需要按照Web服务标准与研发人员签订松耦合的服务契约。通常，它还包括核心服务目录（如 UDDI）以及支持关键接口标准（如 WSDL 和 SOAP）的各种工具和平台。
相比之下，云服务鼓励草根开发风格——通常称为 Web 2.0、面向 Web 的架构或表述性状态传输 (REST)——用于服务配置、开发和管理。任何人只要有一张信用卡就可以注册和访问云服务，这就带来了各种应用和企业内部应用的重复和冗余。
使用相同的标志，任何人都可以使用浏览器混合搭配各种应用程序中可用的各种云服务组件，这将越来越偏离符合企业标准的应用程序设计规范。从企业级服务的角度来看，这可能会导致缺乏严格管理的安全措施。REST 范例中也明显缺少 UDDI、WSDL、SOAP 和其他 WS* 标准。因此，“混搭治理”让一些 SOA 专家担心也就不足为奇了。