Who's managing your managed services? You, ultimately

Managed services aren't magic. Before your provider can provide relief, it will need some help from you

With all of the hubbub surrounding cloud services, application hosting, managed services, and the like, the reality of offloading the management and administrative burden of applications and business services is often overlooked. It's easy to say you're covered because you're paying a company to handle all the administration of the hardware and software underlying your app, but in many cases, that support is extremely limited in scope.

Let's take a look at a few of the differences between managed services and unmanaged services of cloud server instances. Say we're deploying our app on a handful of Web servers fronted by a load balancer and backed by several database servers. This is a standard application design found everywhere. It might have a few dedicated Memcached or Redis servers, or it could make use of a Cassandra data store or other widgets, but that's the basic design.

[ Also on InfoWorld: To troubleshoot, mix two parts observation with one part magic | Get expert networking how-to advice from InfoWorld's Networking Deep Dive PDF special report. | For the latest practical data center info and news, check out InfoWorld's Data Center newsletter. ]

In an unmanaged scenario, our multitier app would exist on a cloud provider's infrastructure with some manner of back-end interlinks and a management portal to build servers from images or templates, deploy and destroy server instances, and so forth. We deploy our app to those cloud instances and get everything up and running smoothly. We then monitor the instances ourselves, and respond if the monitoring indicates a problem with the service, a particular server instance, the database, or whatever else may be wrong. We need to provide 24/7 reachability for our admins to maintain the integrity of the application.

The cloud provider doesn't get involved other than to process payments and to make sure the infrastructure underneath our instances is stable. The cost of these cloud instances is low, but the administrative expense is higher because we're handling it ourselves.

On the flip side, we can deploy the same application on the same cloud infrastructure with managed services. This means that the cloud provider will monitor the application and the servers and take action when something goes wrong, no matter what time a problem should occur. Thus, we don't need to have our admins and developers available 24/7 -- we can offload that responsibility to the managed services provider. The cloud instance cost is much higher for this service than without, but we can rest easy knowing that our provider is actively monitoring our application and servers all the time.

In many cases, that confidence is misplaced. There are limits to what managed service providers can actually do when problems occur. If it's as simple as a service needing to be restarted, that's one thing, but for more complex situations, the managed services admin may find himself without a clue to fixing the problem simply because he lacks the depth of knowledge about the app and its construction that's necessary to fix it.

As an example, let's say a nightly database import process goes haywire. This means a data set has been imported into the production database server with questionable data. The import passed all the consistency checks developed to catch this sort of thing, but the end result is that the application is returning bad data or is crashing.

1 2 Page 1
Page 1 of 2