Okay, so the title is a shameless attempt to grab your attention - glad it worked! But in truth this week's blog is actually about what your applications depend on, and understanding what impact deployment in a Cloud environment may have.

As we continue the discussion about the potential mistakes with Cloud (see here), this week we are diving into Service Dependencies.

What do we mean by Service Dependencies? Anyone who's had the pleasure of doing a sizable data center move or consolidation project knows exactly what we mean. They are the annoying little links between applications and/or services that seem to defy documentation and slip from the memory of the application development team when interviewed. They are the reason most data center move projects end up significantly over budget.

At this point you may be asking why we are talking about this here...after all, this is a Cloud discussion forum, right? Given the challenges most enterprises have with executing server consolidation and/or data center optimization activities, there's no reason to believe that this will be done any better as companies migrate applications to private or public clouds. Put simply, most enterprises don't understand the multitude of interactions between services, data sources, and other applications that support their business functions over a daily/weekly/monthly cycle. Any attempt to port applications to a Cloud environment without this knowledge will likely result in broken applications, or worse...difficult to diagnose suboptimal performance.

Let's explore some examples to help illuminate this issue.

The easiest example of a critical service dependency is around data. All applications and services need some sort of data in order to do anything useful. So the key question is, if you move the systems that are doing the processing (i.e., the application servers), have you kept the data repository in either relatively close proximity, or provided enough network bandwidth to make sure the latency is acceptable? Pretty simple, right? Unfortunately, in the real world it's rarely that black and white; more often, there is a shared database server and you're only moving one of the applications, or perhaps there's a frequently accessed reference data file that's stored in a separate repository. Those are the things that can really trip you up.

Another example might be a service dependency around security. It's fairly common (if not a best practice) for large enterprises to leverage a shared infrastructure for authentication and authorization services. One of the most challenging diagnostic exercises we've performed entailed trying to find the root cause of intermittent (but completely unacceptable) lengthy login times for a critical web application. Part of the application (a complex transactional system) existed in the DMZ, while part existed inside the enterprise firewalls, making it difficult to use standard monitoring tools. We eventually isolated the problem to one of the authentication and authorization servers in a clustered pool, but how we solved the issue isn't the point. It's entirely likely you may elect to deploy parts of a transactional application to a Cloud environment for rapid scaling, reliability, or other perfectly valid business reasons. Be sure you factor in both the performance and operational support complications that will come with that hybrid environment.

The last and most troublesome service dependencies are those that are cycle-based. You might have done everything right: interviewed the app owners and developers, studied documentation, even deployed an automated discovery and dependency mapping tool. And then comes the end of month, quarter, or end of year...suddenly a boring but critical process isn't running and nobody knows why. Eventually you figure it out, but by then the damage is done - SLAs are breached, deadlines are missed, and suddenly that glorious Cloud initiative that seemed too good to be true has a bad name with the entire business team.

Enough of the horror stories, you get the point. It's critical to truly understand every aspect of an application before you move it anywhere, let alone into a Cloud environment where you will have much less visibility to the physical systems. Cloud Computing has much to offer; do your homework and don't let a simple item like service dependencies derail you.