Who’s managing your managed services? You, ultimately

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.

While the application monitoring framework sees that the servers are responding and all the processes that should be running are in fact running, some content consistency checks will start failing. This of course assumes that those content consistency checks have been set up properly, which is often not the case (because they are not set up by the managed service provider, but must be designed and deployed by the application admins or developers). In our tale here, let’s assume those checks are in place and the failure happens at midnight.

The managed services admin gets an automated ticket from the monitoring system, which reports that the consistency checks are failing, so he logs into one or more servers to see what’s going on. He literally has no idea what anything should look like within the app service structure. In many cases there is next to no information sharing between the customer and managed service provider on how the app should work, and almost certainly no documentation.

Our hapless admin logs in and tries his best to figure out why those checks are failing. Not knowing that there is a nightly database import that could have failed or that the database is even the core issue, he begins poking around the load balancer, then the front-end Web servers, testing all kinds of things, and eventually winding up on the database server, which looks just fine.

Heck, the admin doesn’t even know if those Web servers should be running Memcached locally (it’s installed, but not running) or Nginx or Apache (both could be installed, and in fact, running in tandem — but he can’t know that offhand). Myriad elements could be causing this issue, and he really has nowhere certain to look.

A really good admin might look through the logs to see if any action was taken by a cronjob right before the checks started failing, in which case he might discover the import process and surmise where the problem may be — but he may not be able to do anything about it. If there are no backup data sets to import (such as a last-known-good data set), he’s still out of luck until he can contact an app admin or developer and obtain a valid data set. This, of course, obviates the concept of managed services.

The fact of the matter is that managed services are not the equivalent of magic. There are many small things that can go wrong that a managed service provider can fix quickly and easily, 24/7/365. There are many more things, however, that a managed service provider can’t handle without proper knowledge.

In the above scenario, we could help our service provider help us by putting a brief overview of the app architecture in a text file, placed on every server and added to the .bashrc of the managed services login, or placed on the desktop of that user in a Windows environment. A few paragraphs about what should be running where, and what happens during those nightly data imports, will make all the difference. Make sure it pops up at login, so there’s no question that it will be read.

Managed services are ultimately a very useful tool, but they require proper preparation — they ain’t magic.

This story, “Who’s managing your managed services? You, ultimately,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.