Apps on the edge

WILL MISSION-CRITICAL enterprise business logic someday reside on distributed application infrastructures rather than in corporate datacenters and thus span the globe to deliver improved performance? A recent flurry of announcements has put a spotlight on “edge computing” as the newest entrant in the race toward distributed computing, alongside grid computing, peer-to-peer architectures, and Web services.

Microsoft and IBM have recently announced deals with companies such as Akamai and Exodus to distribute .Net and J2EE (Java 2 Enterprise Edition) edge servers and related infrastructure software to hundreds of POPs (points of presence) worldwide, and are planning to launch edge application delivery services as early as this fall. Other CDNs (content delivery networks) such as Mirror Image, Volera, and InfoLibria are building out distributed POPs with J2EE and .Net capabilities and are planning to market their networks as value-added edge delivery platforms for Web services.

In theory, the proposed architectures make sense and are a logical extension of the CDN concept: By caching application logic and data closer to the edge, you can perform routing and load balancing more efficiently, thereby serving applications and data faster and more reliably to end-users.

In practice, edge computing must overcome a slew of challenges related to security, manageability, and appropriateness for transactional applications requiring high data integrity and statefulness — the same issues faced by other distributed architectures. What’s different about edge computing is that a thin layer of business logic and intelligence has already started moving out toward the edges of the network, including logic for doing content delivery and data transformations, message routing, and other functions required by an increasingly edge-oriented computing world.

As Web services start to move outside the firewall, moving selected application logic toward the edge will make even more sense. Ultimately, Web services could become a service layer to the edge, where application logic would be used to assemble applications and data on the fly from multiple origin servers for access by nearby end-users.

Changing the app-delivery vision

Precursors to edge application delivery, such as application streaming, push technologies, and dynamic content fragment tagging (see “ESI: Inching toward edge computing,” below) have seen only limited uptake for specific applications such as personalization and distributing large files and application updates out to remote offices. The new vision for edge computing — as articulated by IBM, Microsoft, and the CDNs — would be a wholesale shift to distributed edge servers as a standard part of enterprise environments, for application offloading both within an enterprise’s own network and via hosters.

Here’s how the new services would work. Developers would use standard .Net and J2EE development tools to “delayer” applications, identifying which business logic, data, and application components — ASPs (Active Server Pages), DLLs, C code, JSPs (JavaServer Pages), servlets, JavaBeans, etc. — could be deployed to the edge and which should stay at the origin. Any data access components that talked to cacheable or third-party data would go straight to the edge, in theory; the caching and invalidation of those components and that data would then be managed by a central set of business rules. The services would rely on existing protocols such as the J2EE RMI (Remote Method Invocation) API for robust transaction support and Microsoft’s ADO (ActiveX Data Objects) .Net data access technology.

The new services, a combination of edge-aware application server software and routing and load balancing algorithms from CDNs, would then determine the ideal distribution of the components throughout the network. Akamai claims it has built integration hooks into its routing algorithms to feed them data about application load and scale in real time across servers in multiple datacenters.

Initially, logic residing at the edge would be used to transform content or to customize the presentation layer, enabling personalized pages or data to be assembled closer to the edge, for example. McAfee.com — Microsoft and Akamai’s first announced customer — will use the distributed environment to recognize end-user licenses and to generate customized virus signature files for load-balanced distribution to its subscribers in the form of a SOAP (Simple Object Access Protocol) message, using ASP .Net server, when a new virus hits.

But edge computing should quickly move beyond the presentation layer to incorporate more back-end business logic and more data replication. “Anything that has a large data set that’s being delivered out of a transaction to a wide range of geographies” will be a prime target for edge delivery, says Bob Hammond, CTO of Woburn, Mass.-based Mirror Image.

An e-commerce application where more users are browsing than are performing transactions, for example, could be entirely pushed out to the edge, except for transactional data such as inventory and delivery availability, which would be kept back at the origin.

Datacenters and distribution

Edge computing gets more controversial when the aforementioned application starts calling third-party processes such as credit-bureau or payment-processing services straight from the edge, without going back through the origin. “Interoperability makes you want to put [the next-gen distributed application environment] on the edge,” says Scott Collison, group product manager for the platform strategy group at Microsoft in Redmond, Wash.

A product configurator, for example, might take inputs from several manufacturers’ catalogs on different origin servers while taking an order. “Part of the capability on the edge [will be] the application intelligence to know how to process that transaction,” explains William Rogers, director of product development at Santa Clara, Calif.-based Exodus.

Not so fast, say true datacenter believers. Lots of questions remain: How do you provide SLAs (service-level agreements) and guarantee reliability on distributed machines you don’t control, potentially running multiple applications? How do you provision, monitor, and manage apps? How do you provide versioning, support, and upgrades? How do you deal with authentication? What strategy should you implement in billing for resources?

“Sensitive business logic can’t just move around willy-nilly,” says Benjamin Renauld, director of technology in the office of the CTO at San Jose, Calif.-based BEA Systems. “You’re not going to go and distribute that on some server in North Dakota.”

It’s the application data you’ll be distributing, not the business logic, adds Renauld, and the best way to do it will be distributed regional datacenters where the SLA issue can be addressed. Other observers, such as Hewlett-Packard’s CTO for software Rick Hayes-Roth, say that the need for manageability and data integrity in database applications has always outweighed the performance benefits of distributed architectures.

“Caching is all about ‘at least once’, not ‘exactly once,’ ” agrees Jason Douglas, vice president of product management at San Francisco-based Grand Central, predicting that distributing stateful apps, which are most of the apps that run on app servers these days, on the edge will be CDNs’ toughest challenge. He points to transaction-related challenges such as nonrepudiation, authoritative logging, and role-based provisioning as examples of generic problems that will need to be solved for a distributed application architecture to take hold.

Vendors rolling out edge computing respond that they’re working on security and management, leveraging existing software (for example, IBM’s Tivoli and Microsoft’s ISA) plus techniques such as sandboxing, workload partitioning, and dynamic provisioning to address some of the key concerns. They’re also looking at protocols such as WS-Security and brokered trust models, which would allow for authentication without going back to the origin, to address security issues. Some vendors claim edge computing is really just an extension of existing app server technologies for mirroring applications in distributed datacenters, with robust administrative capabilities at the cluster and domain level, and an existing model for decoupling presentation layers from business logic.

At the heart of this conflict is an ideological debate about the monolithic, tried-and-true datacenter versus an edge architecture that might someday optimally scale to meet the needs of large, Web-enabled enterprise apps. But more significantly, it’s a battle for control of the application infrastructure, which seems certain to eventually reside not just at the datacenter and on the edge but also at the device OS or client software level. Microsoft in particular seems headed toward more interactivity between the client and the edge, initially driven by communication or collaboration functionality. IBM, in its deal with Akamai, seems to be hedging its bets and trying to understand how to extend its WebSphere franchise to the edge.

Whether CDNs have the technology horsepower to work with application infrastructure is an open question — as is whether or not they can work with app server partners whose architectures they potentially undermine. CDNs seem to have visions of leveraging edge computing into the business-to-business integration market, but whether the performance benefits they promise materialize and outweigh other disadvantages remains to be seen.

A wholesale exodus of transactional applications from the enterprise datacenter to the edge is not going to happen overnight, but there’s no reason not to start building the edge infrastructure to pick the low-hanging fruit such as lightweight application logic (as in a configurator application) or logic to manage the discovery of or routing to a transaction service. Another good candidate would be data replication opportunities, such as in a store locator application, where a little staleness is OK, latency is a driver, and security is not a big issue.

Shifting bits of application logic to the edge will also add fuel to the fire of other distributed architectures, including Web services. Whereas CDNs have traditionally been about performance, Web services are about messaging — getting function at a distance with location transparency — and the two make natural complements.

Source: www.infoworld.com