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 Technologies and Exodus Communications 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 Internet Inc., Volera Inc., 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" further on in this article) have seen only limited uptake for specific applications such as personalisation 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.
Mobile apps on the wireless edge
When Boeing's Connexion in-flight Internet service begins its test rollouts this fall, it will give new meaning to the phrase "application delivery on the edge." The project, designed to provide Internet connectivity and applications to passengers and crew at 30,000 feet above sea level, will use an innovative architecture to cache key application components and data onboard for access via the aircraft's LAN.
The architecture will include a "ground server" that runs BEA Weblogic and Oracle on Solaris, plus an edge server on each aircraft consisting of an open-source jBoss application server running on Linux, and a small-scale IBM Cloudscape database. Synchronisation between the two sets of servers will be handled by software from White Plains, N.Y.-based startup OP40, which provides middleware to distribute and synchronize applications and data across heterogeneous edge environments -- typically mobile environments with intermittent connectivity.
As interest in edge delivery of applications grows, mobile environments are likely to provide early insight into key edge computing issues because much of the research on distributing applications and data out to the edge is being done for mobile environments. Specifically, business logic for message routing and data transformation (to accommodate a variety of end-user device formats) will increasingly be placed near the network edge, whether that edge is defined as an end-user device itself or as some kind of intermediate network, as in Boeing Connexion's wireless LAN.
"Eighty [percent] or 90 percent of all the devices that are going to be used at the edge are going to be wireless," predicts Hewlett-Packard's CTO for software Rick Hayes-Roth, adding that he believes application logic will be spread across four infrastructure tiers, including origin servers, network pipes, wireless base stations, and intermittently connected wireless devices. Palo Alto, Calif.-based HP, among others, is developing middleware to distribute application components and data to the wireless edge and to synchronize them when a mobile user reaches a connectivity "hot spot."
Applications using speech recognition, for example, will likely encode and encrypt voice on the end-user device and then send the data to an edge server for processing. "It won't be possible for everybody to be calling the same speech-recognition server at the same location," Hayes-Roth says. "The only reasonable thing to do is move most of the logic near to the end-user."
Companies such as Research in Motion, Seven, and ViAir have already begun moving business logic out to the edges of wireless data networks, including e-mail routing rules and proxies. And wireless providers must increasingly distribute logic for transformations performed near the edge such as transformations from XML to WML (Wireless Markup Language), those for mobile phones, and secondary transformations to meet specific device attributes.
Middleware for distributing application components to the edge of mobile environments is likely to resemble edge server infrastructure in wired networks, with a focus on delayering applications and incorporating appropriate business rules for provisioning, synchronization, and replication.
"You want to maximize use of computing resources while maintaining the integrity of the application," explains OP40 CTO Shuang Chen.
ESI: Inching toward edge computing
Architects planning the future of edge computing should take a lesson from a recent industry initiative: Don't make developers write special code to make their applications run at the edge.
Known as ESI (Edge Side Includes), the initiative is an effort to realize some of edge computing's benefits by making it easy to dynamically assemble the presentation layer of applications at the edge based on a set of content markup tags instead of distributing the application components themselves.
Launched in April 2001 by Akamai and Oracle and recently published as a World Wide Web Consortium (W3C) note, ESI has met with mixed success: endorsed by several leading vendors such as BEA, deployed in the application server by a handful of vendors such as IBM, and completely ignored by others such as Microsoft.
The idea behind the ESI concept is that dynamic, database-driven content -- such as a personalized Web page -- can be assembled close to the edge using a content markup language consisting of 10 tags that are recognized by each element in the delivery chain, from databases and application servers to routers, caches, and browsers. Developers can specify where and under what conditions a page can be assembled -- usually at a cache as close to the end-user as possible. ESI also deals with "invalidating," or expiring, cached page fragments when fresh data becomes available at the origin.
Critics say that given the overhead of inserting the tags, the benefits of ESI are marginal and can be achieved by other methods, such as using XML and style sheets coupled with specific technology for geographic targeting, parsing query strings, and identifying cookies. These capabilities can be present at the edge, and can then be leveraged by Web services and other distributed apps. The special tagging required to implement ESI "will definitely add a burden to the enterprise," says Shuang Chen, CTO of OP40, a White Plains, N.Y. edge computing middleware company.
ESI supporters, meanwhile, cite the benefits of doing simple assembly at the edge as opposed to running distributed processes, which could hang a machine and increase manageability requirements. They also point out that the development of JSR 128 (the Java Server Pages Tag Library for ESI) simplifies the work required within a Java application to define dynamic fragments, content invalidation, and personalization.
However, the initiative's progress now seems limited by a general perception that it will be co-opted by more robust Web services protocols and the distribution of application components themselves closer to the edge. Even ESI co-creator Akamai acknowledges that ESI-enabled page assembly is only a first step toward computing on the edge, and may become redundant when you can generate pages on the edge using distributed resources.
Some see ESI as one of many vertical protocols that will be superceded by -- or at best, coexist with -- Web services for specific types of apps. "Over time, [Web services] will be a superset of ESI," says Ted Middleton, director of content delivery at Santa Clara, Calif.-based Exodus, which at one time had its own edge tagging language called DSI, but found that without native support from mainstream development tools, the implementation overhead was too high.
THE BOTTOM LINE: Edge computing
Executive Summary: As Web applications proliferate, enterprises are looking for ways to enhance performance, including less latency and higher availability, for remote users. Planned "edge computing" offerings from partnerships between CDNs and application infrastructure vendors will let enterprises distribute "cacheable" application components, including both business logic and data, out to the edge as a seamless part of the development process.
Test Center Perspective: Despite potential security and manageability issues, it's clear that a thin layer of application business logic and data is already moving closer to the edge. Enterprises should limit edge experiments for now to applications with lightweight business logic and easily replicable data -- where latency is an issue and security is not -- as opposed to database-driven transactional applications with high integrity and state management requirements.