For all its benefits, you can bet SOA will saddle your network with increased requirements and complicate network management and operations, consultant David Jacobs writes in a paper for IT professionals.
Since each application in a SOA is composed of many individual software components, a failure anywhere in the network can bring down an application, he notes. Your own performance in monitoring the network and immediately responding to problems is thus even more important after an SOA is deployed.
The way you measure network performance may also change, according to Jacobs. A metric like throughput is misleading because each process generates many interactions among application components. Since each one of these interactions involves little data by itself, the important things to measure are the overall transaction rate and responsiveness.
“Productivity is measured by how rapidly user transactions are completed,” Jacobs notes. “Data rates and the time required for each interchange between components are a factor in transaction rate -- but only one factor. Management software must be able to detect problems at the application level and then be able to drill down to find the root of the problem.”
At Avis Budget, overseeing network performance and management is one of the obstacles IT executives face as they attempt to roll out SOA into more of the organization.
“A lot of our users are distributed in small places where there’s not a lot of bandwidth,” Kumar says. “If we’re going to start rolling out a lot of this SOA functionality that we’re building, the network bandwidth will be a bottleneck.”
Avis Budget is using SOA for customer services, including reservations, checkout and sending receipts. Bandwidth availability is fine for internal corporate users, but Kumar says they have trouble providing enough bandwidth to remote users.
Hurwitz notes that SOA brings scalability concerns depending on how far one reaches outside a company’s firewall and into the systems of customers, suppliers and partners. But “I don’t think the impact on the network is really any different than when you’re doing any sort of distributed application where you need communications abilities,” she says. An enterprise service bus will help facilitate the communication among components and services, she adds.
SOA technology vendors have focused more on enhancing features and functions than on enabling scalability, and users are paying the price, argues consultant David Linthicum.
“The SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads,” Linthicum writes. “SOA implementers were happy to get their solutions up and running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology.”
Linthicum recommends performance modeling and testing of real-life scenarios before putting a SOA into production. “You won’t know how it will behave until you put it through its paces,” he writes.
Linthicum also recommends improving performance by adding processing power at the origin of each SOA service.
There is always room for “more network,” Fulton notes.
“I can always build a system that performs better if I’m willing to send out binary data and not have something that has to be parsed the way XML does,” Fulton says. “But can I build it as fast and modify it as quickly? We’re always asking the hardware and operating systems and the layers on top to support higher and higher levels of abstraction. … “Is it more efficient to do it a harder way? But how many CPUs are less than a gigahertz today? Not many. We let the computer do some work for us again and again through the life span of the application just so we can get it built quicker.”
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Subscribe to this comment's feed