SOA environments are defined by loosely coupled application modules (services) that can be brought together and shared in different ways to address the dynamic needs of the business. This kind of interdependent environment, in which multiple moving parts combine together in unpredictable patterns to form business services, poses a number of production challenges.

The Butterfly Effect
Perhaps the greatest challenge to SOA is the butterfly effect. Complex dependencies between the different application modules mean that a slight change to a remote service can have a dramatic (sometimes drastic) impact on an end user or an application on the other side. SOA applications also often rely on third-party services, increasing the dependency on elements that are out of the application owner's control. Widely distributed modules, coupled with a lack of centralized ownership, only increase the complexity.

At the same time, code changes are frequent and each one has the potential to impact the underlying infrastructure in ways that are hard to foresee. In a SOA environment, ensuring consistent service delivery levels and meeting end-user expectations requires constant vigilance from a team of highly skilled experts.

The Age of Social Applications
SOA applications are dynamic not only in terms of their internal structure, but also in terms of their interaction with users and external applications. Since multiple applications and end users can subscribe to each service dynamically, usage patterns are highly unpredictable. In a SOA environment, it's a challenge to allocate resources or govern usage and service levels effectively.

We're entering an age in which application components exhibit "social" trends, represented by organic and viral growth that tends to be both unpredictable and exponential in nature. Use of successful popular services grows exponentially while the unsuccessful ones show a linear growth pattern followed by a decline.

The Hidden Cost of SOA in a Conventional Data Center
While in their infancy, it's still possible to run SOA-based applications on existing physical infrastructure. However, the cost of scaling and manual support operations rapidly begin to grow in an exponential pattern that makes current operations models unfeasible.

Each time there's an application change - say, the code is updated or a new application subscribes to a service - and there's a demand spike from the user side, the application is vulnerable to availability or performance failures. Preventing this entails constant maintenance of a large buffer - up to 10x is appropriate given exponential growth patterns. The other option is to implement a manual procedure in real-time that modifies the infrastructure in response to every change on the application or demand side. Over time, both of these approaches will become too expensive and too resource-intensive to be practical.

To handle the flexible unpredictable nature of SOA applications, data centers need a corresponding Service Oriented Infrastructure that features adaptive programmable building blocks, application-aware networking, and service level automation.

SOI = (Virtualization)Service Level Automation
SOI should be based on real-time, adaptive, programmable building blocks that change and react to service level requirements as defined by the business. Each application module instance should run in a separate envelope with the ability to expand and shrink on-the-fly. Additionally, multiple, distributed instances of each application module should appear as one single instance to end users and other applications for scalability, high-availability and disaster recovery purposes.

Enter Virtualization
Virtualization is defined by the ability to separate the physical from the logical. For example, virtualization could make one physical server appear as multiple logical machines or make multiple physical machines appear as one logical machine.
SOI requires both kinds of virtualization; the first, to run multiple application modules on the same machine without interfering with each other's logical environments and the second, to assure the scalability and high availability of the service across multiple physical locations.

Server Virtualization
The ability to run multiple logical instances on one physical machine and allocate resources dynamically to each environment can be found in server virtualization technology (such as the ones provided by VMware and XenSource). Flexible sizing, coupled with the ability to run multiple containers in parallel on a single physical server, maximizes the utilization of infrastructure.

Network Virtualization
The second kind of virtualization, which allows for multiple distributed replicas of an application module to appear as one to the external world, can be found in network application switches. To get the most out of SOA, the application should run on an adaptive, programmable, and application-aware network that connects the user to the different services and the application modules to each other. Since the service "containers" change in size and physical location constantly (based on demand, physical constraints, and geographical cost factors), the network should be able to adapt, so that all changes are seamless to the end user as well as to additional application modules up or down the logical stream.

The network must be able to make the necessary decisions to assure that there are no interruptions to business services due to these internal or external changes. Today, this kind of adaptive network is supported by application switches (such as Citrix's NetScaler). These switches provide an API that can change policies on-the-fly as well as view and change parameters in application payloads (beyond the existing protocol fields handled by regular switches).

Service Level Automation
Service level automation is the orchestrating tier that aligns infrastructure and operations with business objectives. This tier goes beyond simple availability to ensure that each business service gets resources according to the service level goal set by the business. Ultimately, the service level goal is equal to the price - in infrastructure and operational terms - that the business is willing to pay to deliver a service.

Service level automation synthesizes the various application and infrastructure components and puts them into the context of user transactions. It can recognize and map the logical structure of a business service and maintain that knowledge as it changes at both the application and infrastructure levels. This makes it possible to manage them - and automate them - according to pre-defined policies.