Appistry Java/C++ Fabric对于5服务器以下应用免费

来源：InfoQ中文站作者：Scott Delap 出处：巧巧读书 2008-06-24 进入讨论组

Appistry发布了他们EAF产品的一个免费的、5个服务器规模的社区版。Appistry可以把一个日常资源集合看成一个单一的、虚拟的资源。Appistry企业应用Fabric架构（Enterprise Application Fabric —— EAF）提供了透明的可伸缩性、基于软件的可靠性、以及自动化管理。

Appistry的首席架构师Michael Groner最近发表了一篇博文，试图澄清grid和fabric之间的区别：

Fabrics是一个基于grid的软件基础架构，能够提供跨越任意数量计算资源的可靠执行和简化操作来虚拟化应用服务。

InfoQ有幸采访到了Appistry副总裁Sam Charrington，讨论其社区版及Appistry在网格/云（grid/fabric）计算领域的总体地位：

1）你们为什么（其中的业务和技术策略是什么）将你们的产品免费发布给至多5个服务器/10个CPU内核？

我们把这一新模式称之为“开放发行（Open Distribution）”，我们感觉它为开源和商业界提供了最好的东西——即，一个成功的商业软件提供商才能提供安全性和支持选项，加上易于被开源项目所采用。

开放发行使我们能让社区中每个人得以体验Appistry EAF的机会，且不带任何附加条件。在这一过程中，我们让用户可以更好地调整其应用程序的经济收益及开销。

从业务视角看，我们相信随着时间的推移，这一做法将会从三个方面给我们创造机会：一些用户将变成付费用户，因为他们想得到更多前期支持。一些人因为其项目的成功而使其有机会扩展到超过5个服务器。还有一些人因为他们想把多个应用压缩到一个大的fabric上，以获得较好的运行效率。

从技术视角看，今天可供下载的免费社区版产品与日后用户获得的付费Appistry EAF产品是相同的。随着时间推移，社区版将持续得到Appistry EAF所作的核心特性增强及Bug修复，但是客户购买的付费产品将提供适合管理大型部署的附加特性。

2）什么类型的应用最能从你们的产品中受益？

我们的主要客户使用Appistry EAF来简化数据和CPU密集型应用的开发和部署，典型的如以一种高可靠的方式来处理大量数据。

这些类型应用的很好的例子包括：FedEx运行在Appistry EAF上的下一代后勤系统（logistics system），每天处理成T（1000G）卫星图片的GeoEye应用。这些应用具有很大规模（scale），跨越成百的CPU运行，形成了我们所称的“应用fabric”。

与这些“scale作为名词”的应用相并列的是那些“scale作为动词”的应用。

这些应用更倾向于ISV或SAAS提供者；有时候前者试图要变为后者。他们想要获得一定程度的敏捷性，以使他们可以随时增加应用的规模。更重要的是，他们想简化其开发人员的工作，提升抽象层级，这样就可以更快地做更多的事情。

这些应用程序看起来更倾向于传统业务应用，只是天生具有伸缩性。

3）与Spring集成方面有哪些内容？
4）你们怎样回应对API封闭性（API-lockin）/ 代码移植性方面的批评？

平台封闭性对客户来说是一个很重要的问题，我们经过努力工作已经消除了移植性的障碍。今天的fabric用户可以很容易将代码移植到fabric上，或从fabric上移植下来。

我们有非常棒的方法来与Spring进行集成，它使得开发者可以把已有Spring beans部署到一个应用fabric上，而无需改变beans本身或使用这些bean的客户端应用程序。通过改变应用的装配方式，所有这些实现起来都很简单。举个例子，我们仅仅修改了10行XML，就把jPetStore应用部署到了一个fabric上。

不论你的应用程序是用Spring写的，还是用Java或.NET写的，你的业务对象都是用与fabric无关的POJO或PONO，而且你可以在任何时候运行它们。（顺便说一下，这也使得单元测试更加容易。）

对于那些开发C/C++应用的客户，我们也提供支持，该语言没有像Java和.NET那样的内省工具（introspection facilities），因此不依赖于它而利用我们平台的全部特性是挺困难的，但是这也是可能的。许多客户已经把现有二进制可执行程序部署到fabric上了，完全未作修改。

5）你们把你们的产品定位于XTP、Grid还是Cloud，为什么？
6）Grid和Cloud计算之间的区别是什么？

我们把我们的产品定位为“基于grid的应用平台”，虽然这不是一个很精确的描述，但是对于技术人员了解该产品用于哪里及与传统选项有何区别来说，这个描述已经到位了。Gartner的Massimo Pezzini创造了这个术语，同时也创造了术语XTP（Extreme Transaction Processing）。我们也很喜欢XTP这个词，因为它表现了客户可能涉及到的业务挑战。

另一方面，术语Grid和Cloud表示了“解决方案”，但是他们所解决的问题不总是很明显：到底是伸缩性？还是资源共享？或是外部托管？

以我们的体验，当最终用户试图断定一个术语的意思时，通常采取的是一种“公分母”方法。对于Grid，大多数人认为它是通过跨越许多计算机执行来扩大应用规模的一种方式。

我们认为Cloud计算之所以位于Grid的上层，是因为其实用交付模型（utility delivery models）、Internet范围、以及极限敏捷的概念。我们并不认为只有第三方交付才意味着实用、即时交付：我们的许多客户认为我们的产品可以在其企业范围内搭建起云计算平台——既不需要EC2，也不需要AppEgine，非常感谢。

7）从Appistry的视角看，这些天与应用伸缩性相关的最有趣的趋势是什么？

最有趣的事情是，由Cloud计算、SAAS及Web 2.0这样的技术趋势推动，可伸缩性本身在我们眼前被重新定义了。
可伸缩性的门槛比10年前J2EE出现的时代低多了。企业里的大多数问题可以在一个单一的服务器或小的集群上被解决。今天的应用沉浸在大量的数据和事务里，它们需要被日益复杂的算法来处理，简化之后，再不会出现这种情况了。

过去的技术在现今的新世界中由于其自身的复杂性而毁灭了，这给开发者和架构师创造了去实现一个新的、轻量级的、更加可伸缩及敏捷方法的机会，并且把可伸缩性放到了执行层议程中，或者放到通常的对话中。

对于我们这些对应用程序可伸缩性充满兴趣的人来说，这是非常令人兴奋且重要的时期。

Appistry最近还完成了C系（series C）的一轮投资，用于扩张销售及市场运作。

查看英文原文：Appistry Java/C++ Grid Fabric Goes Free for up to 5 Servers