Fabrics are a grid-based software infrastructure enabling virtualization of application services with reliable execution and simplified operation across any number of computational resources.InfoQ sat down with Appistry VP Sam Charrington to discuss the community edition and Appistry's overall place in the grid/fabric computing landscape:
1) Why (business and technical strategy please) are you releasing your product free for up to 5 servers/10 cores?
We call this new model "Open Distribution" and feel it offers the best of the open source and commercial worlds-that is, the security and support options that a successful commercial software provider can offer, coupled with the ease of adoption of open source.Open Distribution allows us to give everyone in the community an opportunity to experience Appistry EAF with no strings attached. In doing so, we allow users to better align their costs with the economic value they receive from their applications.
From a business perspective we believe this will create opportunities for us over time in three ways: Some users will become paying customers because they want a more proactive support relationship with us. Some because the success of their projects gives them the opportunity to scale beyond 5 servers. And some because they want to collapse multiple applications onto a single larger fabric, to attain the resulting operational efficiencies.
Technically speaking, the free Community Edition product available for download today is the same great product that paying Appistry EAF customers receive. Over time Community Edition will continue to receive the core feature enhancements and bug fixes that Appistry EAF gets, but customers purchasing the paid product will get additional features geared toward managing large deployments.
2) What types of applications most lend themselves to benefit from your product?
The majority of our customers are using Appistry EAF to simplify the development and deployment of data and CPU intensive applications, typically to process lots of data in a highly reliable way.Great examples of these types of applications include FedEx's next-generation logistics system which runs on Appistry EAF, and GeoEye's applications which process terabytes of satellite imagery each day. These applications are large scale by almost any definition, running across hundreds of CPUs forming what we'd call an "application fabric."
In parallel with these "scale as a noun" applications are the "scale as a verb" applications.
These tend to be ISVs or Software-as-a-Service providers; sometimes the former trying to become the latter. They want to achieve a level of agility that allows them to incrementally scale applications on-demand. More importantly, they want to simplify things for their developers, raising the level of abstraction so that they can get more done more quickly.
The applications tend to look more like traditional business applications, just natively scaled-out.
3) What is your Spring integration story?
4) How do you respond to criticisms about API-lockin / code portability?
Platform lock-in is an important issue for customers and we've worked very hard to eliminate barriers to portability. As a result, today's fabric customers are able to easily migrate code both on to and off of a fabric.We've got a great approach to Spring integration that allows developers to deploy existing Spring beans to an application fabric without changing either the beans themselves or the client applications that use them. It's all done simply by changing the way the app is wired. As an example, we deployed the jPetStore application to a fabric changing only about 10 lines of XML.
Whether your application is written in Spring, Java or .NET, your business objects are written in fabric-independent POJOs or PONOs and you can run them wherever you want. (This also makes for easier unit testing by the way.)
For customers developing C/C++ applications, which we also support, that language doesn't have the introspection facilities that Java and .NET do, so it's a bit harder to utilize the full richness of our platform without getting tied to it, but it's certainly possible. Many customers take existing binary executables and deploy them totally untouched to a fabric.
5) Do you position your product as XTP, Grid, or Cloud, and why?
6) What is the difference between Grid and cloud computing?
We position our product as a "grid-based application platform," which while not quite a perfect descriptor, does a good job of suggesting to technical people what the product is used for and what differentiates it from traditional options. Massimo Pezzini at Gartner coined that term, along with XTP, or Extreme Transaction Processing. We like XTP as well, because it represents a business challenge that customers can relate to.The terms Grid and Cloud on the other hand represent "solutions," but the problems they solve are not always explicit. Is it scalability? Is it resource sharing? Is it external hosting?
In our experience, end-users take a "common denominator" approach when trying to figure out what a term means. For Grid, that means that most people we talk to just think of it as a way to scale out applications across many computers.
We believe that Cloud computing layers onto Grid the notions of utility delivery models, Internet scale, and extreme agility. We don't however believe that utility, or on-demand delivery is necessarily synonymous with 3rd party delivery: Many of our customers think of our product as enabling Cloud computing within their enterprises-no EC2, no AppEngine, thank-you-very-much.
7) In Appistry's view what are some of the most interesting trends you're seeing these days related to application scale?
What's most interesting is the fact that scalability itself is being redefined before our eyes, driven by technology trends like Cloud computing, Software-as-a-service and Web 2.0.Appistry also recently completed a series C round of funding to expand sales and marketing operations.The scalability bar was a lot lower 10 years ago when J2EE came on the scene. Most problems in the enterprise could be solved on a single server or small cluster. That's simply not the case anymore-today's applications are drowning in data and transactions that need to be processed with increasingly sophisticated algorithms.
The technologies of the past are collapsing under their own complexity in this new world, creating opportunities for developers and architects working with newer, lighter-weight, more scalable and agile approaches and pushing scalability squarely onto the executive-level agenda if not into the popular dialogue.
These are very exciting and important times for those of us interested in application scalability.
