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

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