In enterprise application development, the LAMP (Linux, Apache, MySQL, Perl / Python / PHP) stack is rapidly gaining momentum on Java and .Net. The Globus Consortium Journal recently spoke with ActiveGrid CEO, Peter Yared, to learn more about how LAMP addresses enterprise app development and integration issues, and to hear his thoughts on why today's enterprise transactional apps typically do not scale to Grid environments.

GCJ: You've commented in recent interviews that consumer-facing web applications today are in many ways more sophisticated than what we're seeing on most corporate web sites. Explain what you mean.

Yared: Well, my background is in infrastructure software. I was at Sun for five years, and was the CTO of the application server division there. And before that, I was the CTO of Net Dynamics, which is a Java application server company that Sun acquired.

In '96 / '97, consumers could use their computers to buy plane tickets, check the weather, and buy books. But when they went to work, if they wanted to change their health plan, they had to call HR. If they wanted to find the latest price of a part, they had to call their supplier and have a price sheet faxed to them. This disconnect between home and work life very quickly evaporated, and now virtually all information that people need at work is available online.

I think we're at a similar point today, where consumers are seeing great new capabilities on Web applications, then they go to work and are frustrated not to have that functionality there.

GCJ: So what sort of new functionality are they looking for?

Yared: Naturally, enterprises have taken notice of the rise of "mash-up" applications on the Internet that integrate data from a variety of sources in new and useful ways.

Large organizations also want to deliver composite apps, like CRM applications that can call other services. That way they can show, for example, that a customer's last five orders have been delayed before they make a sales call and get ambushed by an irate person on the other line.

The days where each enterprise application is an island are coming to an end--even things as simple as an employee directory now need to integrate the HR systems of multiple divisions, accommodate cross-reporting and virtual teams, and integrate outsourced third parties. Like it or not, essentially every enterprise application today requires integration.

So enterprises want to start developing their own mash-up applications, with feature rich AJAX user interfaces that integrate data from multiple data sources.

GCJ: So how do corporations do this sort of heavy integration with enterprise-class applications?

Yared: Front-end integration has become the enterprise equivalent to the mash-up movement. It works by integrating Web services and databases at the web tier, using lightweight technologies like LAMP. With lightweight architecture, it is very simple to integrate data from a variety of internal and external sources and present the data with a rich AJAX user interface. If you look at the companies that are doing exciting new application -- from Google and Yahoo!, down to the rest of the "Web 2.0" pack, such as Facebook, flickr, Friendster, and MySpace -- they're all running on LAMP.

Remember, however, that back-end integration is still necessary to create non-user facing services that require multi-phase commits or long-lived processes. Multi-phase commits involve coordinating across multiple data stores to ensure that data is updated on all of them or none of them, most commonly for financial types of transactions where money is being moved. Long-lived processes involve coordinating multiple steps across many systems, such as handling exceptions in supply chain management where a shipment needs to be diverted automatically to a new plant. These types of projects are very expensive and cumbersome, and the most popular technology for back-end integration is of course J2EE servers and their Integration Server offshoots from vendors like IBM and BEA.

But as evidenced by the growing use of mash-ups on the Internet, very useful integration projects can be delivered quickly and economically on the front-end, using lightweight architecture.

GCJ: For the Grid community -- what would you say the biggest challenge is from an application development perspective?

Yared: The Grid community -- before they solve world hunger with the 'big pool of virtualized resources that you can tap into' vision -- needs to concentrate on making enterprise-class applications that can scale horizontally in their own dedicated clusters. That's step one, because if you look at any J2EE application, it wasn't written to scale beyond four to eight machines.

Back in the late 90's, customers wanted to run small clusters of SMP machines. That's why Sun made so much money. Now that Google and Yahoo! and Amazon have started running large clusters of commodity machines, everybody wants to do that. But you can't take the software that you wrote on small clusters of SMP machines and expect it to scale horizontally to 200 or more machines in Grid environments.

When you're running transactional applications, you typically need to run commodity machines that are identical. For example, you want them to be Linux and x86, and on one subnet or on one set of network controls. And that's the only way it's going to scale. So there's the Grid vision that you can have free resource pools -- of any sort of heterogeneous combinations -- available to jump in on the fly. But for transactional applications, forget about it.

So that's the fundamental application challenge that the Grid community faces -- most hard core enterprise applications were simply not written to perform in scale-out, heterogeneous Grid environments.

GCJ: Are you seeing anyone making money off of the utility computing model anytime in the near future?

Yared: I don't see how. There are too few enterprise applications that are suited for it. What apps do enterprises have that they can just throw over the firewall to a third party vendor? Definitely none of their transactional applications, definitely not their CRM applications. Most transactional applications have gobs of associated data, so how are you going to get that data over to the third party to perform the computation? And when you factor in the related data movement requirements, it just still makes a lot more sense to run the processing on the machines that you have in-house.

GCJ: You were previously CTO of Sun Microsystems' Liberty Network Identity initiative. So what's your take on security in SOA environments? Do you think that enterprises are ready for SOA from a security perspective?

Yared: Well, it's still early. What needs to happen is for what's out there to solidify a bit, and for people to get comfortable with it. And that's just going to take a little bit of time. We as an industry have spent a lot of time and energy adding a lot of different security protocols and stuff. The problem is that a lot of the products aren't interoperable, and it's very confusing and complicated for customers. And it's going to take time, just like SOA has taken time. I mean, we were talking about SOA and XML Web services five or six years ago, and it's only just now starting to get traction. So I think we're going to see a similar lag time with security.

With SOA - what you're doing is exposing endpoints to other applications. When you had a monolithic application, it didn't talk to anything else, by definition. But now you have a bunch of applications that are calling each other, so the fears become how to validate that it's actually an internal app calling. How does an organization ensure that it's not publishing data outside of the firewall that it shouldn't? How does an organization know, when they get something, that it really came from where it was supposed to? Those sorts of security questions become very important in SOA environments.

close window