Whenever there is a shift in architectural thinking about technology, such as is happening right now with cloud computing and virtualization, we start thinking forward, past the now, and into the future about how that technology might be leveraged. We start looking at the impact to architecture from the top of the stack to the bottom. For a company that's focused on application delivery, that means taking a good hard look at how that new technology might impact the architecture of applications.

It's been suggested that perhaps, just maybe, we'll see service-oriented clouds; that the concepts of SOA (service oriented architecture) might be abstracted even further and moved into the cloud. Basically, it's like ripping apart the n-tiered application architecture we've been building on for years and spinning each tier into the cloud; database there, presentation layer here, middleware layer over there. And not just in one place, either, but rather duplicating these "services" to provide failover, availability assurance, and context-aware access that takes into consideration variables like location and response time.

That would certainly be more efficient than current architectures which deploy entire applications as virtual images or packages in the cloud. If the database tier needs more compute resources, then just the database tier expands, rather than the entire application. That's the principle of SOA at work, as well. Decompose business processes and applications into their composite services and deploy. If one service is heavily reused, you can replicate and load balance just that service, not the entire application.

But applying SOA to the cloud may be more difficult than it sounds. While there are often discrete tiers of architecture within an application, even within a SOA-based architecture, it is still somewhat difficult to envision deploying those tiers across multiple clouds. Application infrastructure is certainly just as capable of communicating across the Internet as it is a local network, so the problem isn't so much with technology and its capabilities as it is with actually managing such a dispersed and distributed application infrastructure.

ideabulb Troubleshooting such an architecture would certainly be problematic. Trying to recreate an issues for troubleshooting has always required replicating the environment as closely as possible, and it may be exceedingly difficult to even get that information in a service-oriented cloud architecture. Which data center, which database instance, which front end, which network? The variables become as overwhelming to manage as calculus appears to a third grade math student.

Further complicating the potential deployment of databases, specifically, into the cloud is the integral web of applications and systems reliant on those databases for day to day operations - both IT and business focused. Data mining, business activity monitoring, business process management, supply chain, and ERP systems are often all tied into databases around the enterprise. Move any single database and you become mired in a dependency chain that is serial, not parallel, in nature with the database being the foremost link in the chain. Access or availability to that database can bring applications - and the business - to a screeching halt.

It's that kind of risk rather than the traditional security risks and concerns surrounding offsite data storage that needs to be addressed before critical infrastructure like databases can be decoupled from the internal control that exists in the local data center. SOA addresses the architectural coupling of data and logic to applications, but it cannot adequately address at this time the need to have tightly coupled control over the availability of that data.

Applying the principles of SOA to the enterprise and the cloud can indeed have benefits in terms of reduced infrastructure costs and the ability to scale on-demand, but it still can't address the vulnerabilities inherently present from our reliance on data.

Data is the lifeblood of an organization. Applications, like the heart, keep that data pumping through the complex network of veins and arteries that are the corporate and Internet infrastructure. But like human beings even though the heart and some of the infrastructure can be outsourced, without blood (data), everything else is irrelevant.

Given our dependency on data and its availability, it's unlikely we'll see fully service-oriented clouds in the ether anytime soon. Not until we have the same guarantees of availability and access and ultimately, control, that we have in the local data center.


Follow me on Twitter View Lori's profile on SlideShare AddThis Feed Button Bookmark and Share