Let's face it: this isn't your father's Grid computing. Gone are the days when Grid was relegated to the back rooms of universities, supercomputing centers and national labs, being used only by “dreamers” with a fantastical vision of sharing the rapidly growing computing resources at their fingertips. They say a technology has reached the big time when it makes the leap from academia to the business world. If this is true, then Grid has not only reached the big time, but done so in ways probably unforeseen to many.

While big business has been using Grid for years now to speed up compute-intensive applications and handle the huge volumes of data they produce, it is more recently, since Grid began its evolution into Grid 2.0, that enterprises have been finding more everyday uses for Grid technology, focusing more on Grid's inherent flexibility and distributed nature than on its brute processing power. One way in which they have been using Grid is to handle transactional applications, a technology trend Gartner has labeled “Grid-based application platforms,” which, as of July, sat on the “Technology Trigger” area of the analyst firm's renowned Hype Cycle.

According to Massimo Pezzini, vice president and distinguished analyst at Gartner, while there are similarities between traditional Grid deployments and Grid-based application platforms, and while the underlying technologies even can be the same, the target, from an application perspective, is different. “In traditional Grid, the problem is allocating processing power and you don't really care about availability of the overall system, if one box is available you don't care. You need to have that server,” he said. “In transactional apps, it is not that simple. With transactional applications, you have to deal with databases, you have to deal with maintaining the transactional integrity of the thing that you are doing. It's a bit more complicated.”

Typically, Pezzini added, these Grid-based application platforms address two main problems that are not always for traditional grids to solve: scalability and availability. When it comes to scalability, it's all about adding more and more hardware resources, he said, and availability is crucial because users need to be able to maintain transactional integrity, which generally requires as close to 100 percent availability as possible — even while adding or removing resources from the grid.

And it is here, Pezzini said, where vendors is this space believe they have the advantage over traditional Grid vendors. Whereas Grid-based application platforms can be applied (to some degree, at least) to straight computational applications, the same cannot be said for traditional grids and transactional applications. Among the vendors trying to exploit this different approach — according the Hype Cycle profile — are GigaSpaces, Appistry, Paremus, Aumega Networks and Majitek, of which Pezzini cites GigaSpaces as being the largest in terms of revenue and customer installations.

If you ask Geva Perry, GigaSpaces' executive vice president of business development, what separates his company from those traditionally associated with Grid computing, he'll tell you it's all about managing the various middleware tiers – – messaging, business logic (computation), data and presentation — necessary to run any business application. While traditional grids can manage applications across distributed resources, have several instances of business logic running to handle the computation, and improve throughput by having tasks split up and ran in parallel — a setup that works nicely for non-data intensive applications with few latency requirements — GigaSpaces caters to customers running transactional applications by focusing on data management with its software.

By providing a distributed data grid, which Perry defines as having data stored locally on grid boxes, as well as having data in memory (often referred to as distributed shared memory), GigaSpaces' solution is able to offer “everything you'd expect from a database in terms of maintaining state during transaction,” he said. The traditional n-tier architecture, he added, requires separate products and separate boxes for each tier, thus creating a fair amount of latency from tiers interacting with one another, data traveling across the network, etc., “Which, for many transactional applications, just won't cut it.” With the GigaSpaces approach, Perry contrasted, the transaction can be completed within a physical box, with the resulting data, business logic, etc., being distributed across the grid of processing units.

“When you think about that architecture, a whole set of questions come to mind,” said Perry. “Number one is: how do I maintain reliability and high availability, especially since I'm holding the data in memory?” Another is: what happens if a job head for a particular box fails? Well, Perry answered, both of these issues are addressed with GigaSpaces' synchronous backup functionality and transactional semantics, which allow other boxes to pick up where the primary one left off.

If it sounds to good to be true, that's because it's designed to be. Perry said GigaSpaces has put a lot of effort into separating the programming language from the underlying distributed architecture, and has been a big hit with developers as a result. The company, he said, has been telling developers to continue writing applications as they have been, in whatever language they please, and the GigaSpaces software will take care of the scalability and distribution, transparent to the application. The same holds true for multi-core machines and applications, Perry added. It is especially important in transactions that order and sequence are maintained when things are happening in parallel, he said, what GigaSpaces is saying is, “Don't worry. We'll take care of it.”

Of course, it isn't developers who make the ultimate purchasing decisions, but GigaSpaces ease-of-use and subsequent ROI and TCO pitch works just as well on IT executives, who very much enjoy hearing about being able to run business-critical, Linux-based applications on commodity hardware, which just happens to be utilized at a higher rate. When you throw in the added benefits of higher throughput, reduced complexity and not having to pay for new development skills for the IT staff, the pot is only sweetened. One executive who has experienced what GigaSpaces brings to the table is Bec Wilson, CTO of Sempra Energy.

Sempra Energy has been using GigaSpaces for around two years, primarily to load historical and future price curves into memory for the company's commodity trading applications. According to Wilson, legacy platform for handling these applications was “all JDBC/ODBC SQL fetch stuff,” and was orders of magnitude slower with much longer night-cycle processes and batch processes. “If we pre-load stuff, we see 100X increases in data access. If we're not preloading stuff, on the first hit it takes just as long to load it as before, but on the second hit we see those 100X performance increases again,” said Wilson. “If the optics are already there waiting on us, there's just no comparison — we can do things in minutes now that used to take us hours because of how much data loading we had to do.”

Interestingly, though, Sempra Energy does not solely use GigaSpaces for its Grid computing needs. Actually, said Wilson, in Sempra's data center, GigaSpaces serves in many ways as an “extremely valuable” and “extremely important” complement to the company's Sun Rio/Jini computing grid. This grid, Wilson explained, is used for executing portfolio evaluation jobs, which lend themselves pretty well to a parallel-processing environment. Each node on the Sun grid is in communication with the GigaSpaces shared memory and thus has access to whatever pricing curves have been loaded. This is so important, he said, because several evaluations might need the same curve simultaneously or back-to-back, and GigaSpaces makes the curve available without having to re-fetch 10 years of electricity pricing data every time they run.

Overall, Wilson said, the GigaSpaces software has really empowered his computing grid, and his staff has been “very impressed” with how well it lays down and how well-behaved it is. “In terms of performance and reliability, it's been a pretty exemplary product, and a lot of technical guys are pretty hard on vendors — it really appeals to the super-technical types,” he noted. “And it's beginning to appeal to the executives whenever we can talk about 10 to 100X performance increases. It's been impressive all the way around. The techs, the guys who really use it a lot, swear by it.”

GigaSpaces, however, is not alone in the Grid-based application platform market. As noted earlier, Appistry also plays in this space, although it takes a different approach with its Enterprise Application Fabric (EAF). From the outside, EAF (which has been the focus of two GRIDtoday articles: http://www.gridtoday.com/grid/738014.html and http://www.gridtoday.com/grid/698929.html) more closely resembles the grids with which most people are familiar than does GigaSpaces' software, and does not focus on the data management aspect of handling transactions, but rather on the time element. Like GigaSpaces, though, Appistry believes its fully distributed architecture is the key to efficiently dealing with transactional applications.

Sam Charrington, Appistry's vice president of product management and marketing, said EAF is engineered from the ground-up to solve time-sensitive problems, and he believes its peer-to-peer model, which eliminates single points of failure or scheduling bottlenecks, is one of the key architectural shifts that separates his company from traditional Grid vendors. “In our world, everything is more geared toward the transactional, or time-sensitive, type of application, where there's a pool of commodity machines that are centrally located within the data center,” said Charrington. “Transactions or jobs, pieces of work or service requests: These things are constantly coming in and dynamically being farmed out to the different machines or workers in a fabric.”

When it comes to dealing with transactions, there are few (if any) hotter buzz technologies than SOA, which Charrington said also benefits from EAF's fabric architecture more so than from traditional grid architectures. Whereas traditional Grid vendors tend to look at SOA in terms of creating a service that sets the front end to schedule jobs, a fabric application is essentially a collection of services, which is more amenable to the Web services types of application organizations are looking to deploy. “People who think that the Grid market is small are looking at yesterday's definition of 'Grid,'” he said. “Who out there that is deploying an SOA doesn't need an environment that allows their services to be scalable? One of the whole points of SOA is that you put these services out there and other people consume them. They use them, and roll them into their own applications… . A model like ours that ensures reliability of these applications is absolutely key.”

One Appistry customer, who just happens to be in the transaction business, is Clearent — an upstart company with its sights set on the credit card payment processing market. To hear Clearent's senior director of product management, Mark Peck, tell it, Appistry's solution is pretty much a perfect fit for this type of work. In the highly transactional authorization process, for example, there is a huge emphasis on low latency and fast response times, as authorization for purchases needs to given in real-time. The next step of any credit card transaction is the settlement process, where all the appropriate interchange rates, fees, etc., are applied. While this is done in a batch fashion several times per day, the individual jobs — like most in a Grid-based application platform environment — are relatively small, certainly nothing requiring processing power of the TeraGrid. Clearent, Peck said, also uses Appistry to handle the various services it offers as part of its unique Web interface.

Aside from the fact that Appistry EAF is able to meet Clearent's needs in terms of handling both transactional and batch-oriented tasks, Peck also points to flexibility and ease of use — two properties often associated with GigaSpaces solution, as well as most others in this space — as big reasons for choosing the product. When it comes to flexibility, he noted that most authorizations take place during business hours while most settlements take place during off hours, which adds extra importance to the ability to dynamically adjust the configuration of the fabric. As for ease of use, Peck cited an instance where Clearent was given some PERL code from a partner, and was able to easily adapt it to run in the fabric environment — something it was not initially intended to do. In most traditional grid deployments, applications must be specifically written or re-written to take advantage of the grid.

However, despite the advantage Peck believes Appistry will bring Clearent when it commences operations in January, he sees most of his competitors still clinging to their old mainframes. “To our knowledge, there are no players who are currently planning to implement something Grid-based,” he said. “They may gain some advantages if they choose to go with just a standard open system and modern computing hardware and programming languages, but they will still incur a lot of costs for management, administration and scalability in terms of the hardware issues that we have managed to take out of our cost equation.”

And, while Clearent won't begin actually processing credit card transactions until next month, there are plenty of businesses already online whose infrastructures have to handle millions of transactions every day, and combine to create a market for what Gartner's Pezzini calls Extreme Transaction Processing, or XTP. From discount travel sites to airline company sites to shopping sites like Amazon, businesses are seeing exponential growth in the transaction workload they have to deal with, he said, noting that before the Internet, hotels and airlines averaged seven looks for every booking, a ratio that has skyrocketed to 300:1. As a result, these businesses need to reduce the cost of processing each transaction on their e-commerce applications, and the big, costly, difficult-to-use mainframes, such as IBM's old TPF (Transaction Processing Facility), just aren't going to cut it for most of these companies. Grid-based application platforms from companies like GigaSpaces and Appistry, with their easy-to-configure software and ability to utilize commodity hardware, are one of the best candidates to deal with this growing problem, Pezzini said.

GigaSpaces' Perry also has noticed this trend taking place, and cites these applications' latency and scalability requirements, especially with the increase in data that accompanies the avalanche of transactions they see, as a main reason his company is seeing interest from the space. “The big question is scalability,” he said. “To achieve true scalability, meaning that I can easily grow my application to [fit my] needs without having to change it … I need a different model — a model that virtualizes or abstracts the underlying resources from my application components. Having each tier tightly coupled with its hardware is not going to cut it.”

As with any burgeoning technology, though, there are some issues the Grid-based application platform market needs to overcome. In Pezzini's opinion, these challenges begin with the fact that their potential customers simply are not familiar with the companies or what they do. While he acknowledges that there are instances (about 5 percent of the potential market) where these vendors' technologies are the only answer, in which case they get discovered, they are most often competing against universally recognized names like Microsoft, IBM, Oracle and BEA Systems. Ironically, perhaps, Pezzini believes these same large competitors also are a key to success for GigaSpaces, Appistry and their peers. He said that by getting buy-in from big systems integrators, software vendors and hardware vendors, these companies could greatly increase their ability to move forward and educate their marketplace of customers. The other big obstacle, according to Pezzini, is something that should sound familiar to anyone in the Grid community. “Those guys, sooner or later, need to get together and agree on some standards,” he said, “because if they remain segmented, with everybody going his own direction, they're not going to grow any farther.”

Just as users of traditional grids often decry the lack of standards — hoping for the ability to build their Grid environments using best-in-class pieces from multiple vendors, as well the knowledge that any applications would run smoothly should there be a big change — potential Grid-based application platform customers would sleep a lot easier, Pezzini said, knowing if, for example, something were to go wrong with their GigaSpaces implementation, they could migrate the application to Paremus or Appistry. Standards are the way to catalyze their marketplace, he added, because while some customers might not be willing to bet all their resources on a little vendor like Majitek, they are more likely to bet on multiple vendors.

Even with the perceived obstacles this space faces, it definitely has the technologies to make a big mark on the Grid landscape should it overcome them. As data stores and the need to manage it continue to grow, while the time limits to process the transaction that created the data continue to shrink, all, of course, under the constant push to cut costs, vendors like GigaSpaces, Appistry and their peers in the Grid-based application platform space will be there, touting solutions that seem too good to be true — even though they often are.

Appistry's Charrington, for one, remains steadfastly optimistic. And who can blame him? “If you think about it, yesterday's strictly computation grids are quickly migrating into today's and tomorrow's Grid application platforms. Some people call it Grid 2.0,” he observed. “Grid plainly has a lot of advantages to offer the enterprise for business-oriented types of applications, and that process of migrating from Grid middleware or Grid scheduler to Grid-based application platforms is really the key.”