If you have anything more than a trivial server and storage estate in your organisation, the chances are that you use some kind of management tools to keep an eye on everything and to manage the various layers. If you place services in the cloud, however, you'll have to give some thought to how you maintain the level of monitoring and management that you're used to.
There's actually a very good chance that you can use many of the tools you're used to, though this is dependent in part on the level of connectivity you have to the low-level parts of the cloud installation. Let's go through the various management layers.
In the cloud you have absolutely no sight of the physical layer of the installation. Frankly it would do you no good to be able to see the physical layer anyway, because unless you can put what you see in the context of what's running on it, what you see would mean nothing anyway. And since no cloud provider is about to tell you their precise architecture or who else is running on the physical kit you're looking at, you might as well forget it.
It’s for this reason that you should always ask searching questions about the infrastructure before you sign up to a provider – you're never going to see it for yourself, so all you can do is make sure you're happy that it’s resilient and use whatever dashboard it provides to watch service levels.
Network ports
Similarly you're not going to be able to monitor the ports on either the physical or virtual switches in your installation, because it will be carrying data other than your own and will be rendered invisible to you by the provider.
What you can do, however, is monitor the traffic on your virtual devices – which is reasonably useful since although you won't see things like packets that are dropped due to physical faults, you will be able to see traffic levels and breakdowns.
Whether you can manage the network ports to any extent depends on what the provider exposes to you. Some providers give you the out-of-the-box management interface for your virtual servers, or at least something it has written itself based on the platform's API which mimics the behaviour of the vendor's own interface.
At the OS level you should be able to do your own thing with your own tools, provided of course that the tools are able to connect in. If you're able to set up a VPN tunnel between your premises and the cloud setup then you can manage everything from the server OS upward (and possibly the VM-level stuff if it's available) from your home base; if you have a large server installation in the cloud you'll want to consider installing the management application within the cloud setup so you get maximum responsiveness and you're not filling your interconnect with management traffic.
Just to go back to the VM-level stuff: the big cloud vendors all have APIs which more and more management packages and services support (we looked at RightScale not so long ago, for instance). Be prepared to consider switching horses to one of these packages or services, then.
The application level tells the same story as the OS level: once you've got above the virtualisation layer you can use pretty much what you want to manage the apps. Again you'll want to consider installing your management tools in the cloud in order to keep performance up and traffic down.
It should be clear by now that except for the low-level stuff, you're reasonably free to do your own thing. Although do bear in mind that you're stuck with what the vendor gives you for monitoring the physical bits of the installation.
Or are you? Just because you can't see into the network and servers doesn't mean you can't learn something about them using secondary means. For instance doing an IP traceroute between two of your hosts will show you the complexity of their internal routing; similarly tracing paths in and out of the cloud setup shows you something useful about the edge configuration. And even the basic round-trip (ping) time between your hosts will tell you their relative proximity, while analysing your DNS lookup time for external hosts tells you whether the provider's DNS is hunky or flaky. Just because you can't see something with SNMP doesn't mean you have to live with zero input (and hey, why not put an SNMP monitor in your cloud and point it at every IP it can see with a “public” community string – you never know!).
Additional concerns
When your services are in the cloud there are a couple of things you need to consider that you probably didn't worry about on an in-house setup.
First, and we've alluded to this already, it may not be super-efficient to have a management station in your office talking over the WAN or internet to the cloud; if you've shifted most of your servers to the cloud then why not move the management and monitoring stations over there too? At the very least, use some kind of agent-based setup to aggregate traffic and minimise management traffic on the interlinks.
Second, use whatever tools you have and measure the connectivity between your office and your cloud, and between the cloud and the outside world. If you're accessing services from a number of locations via the internet you really should use one of the umpty-squillion services out there that monitor your services from different bits of the internet; you could try Site24x7 but there are literally hundreds to choose from).
The best way to manage your cloud service is, then, to look at the tools you use and see where you can and can't make them manage the cloud; after all, you chose them for a reason so they presumably do what you need them to.
When you've identified the gaps in what you used to do and what you can do now, look to see if there are tools that you don't use but which your cloud provider supports (we mentioned RightScale earlier, but the list of options grows weekly).
Last but not least, when you've looked at both of the above you should look to the vendor's own tools; they're likely to be useful but there's huge value in having your own tools as well to “check your provider's homework”.
