Perhaps you have taken the plunge into the fluffy cloud of the virtual data center. If so, there might be a few of those pesky physical servers still awaiting their eventual destruction. There’s no reason not to include them in your dashboard views of the cloud you created.
Let’s take a look at how you can use Cloudkick to bring your physical servers along for the dashboard ride.
Four software agents walk into a bar
RWW covered Cloudkick earlier this year. The list of cloud providers you can manage from API oriented controls is the following list:
- EC2
- GoGrid
- Linode
- Slicehost
- Rackspace
- RimuHosting
- VPS.net
- SoftLayer
Now, in addition to API oriented controls and management for cloud providers, Cloudkick offers a growing number of software agents for the following Linux distributions and has a private beta for Windows. By using software agents you can also keep watch over one-off virtual servers that do not have an API control option or even other physical servers:
- Cloudkick Agent for Debian and Ubuntu 8.04+
- Cloudkick Agent for CentOS, RHEL 5.0+ and Fedora Core 8 and 13
- Cloudkick Agent for Gentoo
- Cloudkick Agent for Windows (private beta)
Why use an agent? Well, for one, you may not want to go all in on API with your cloud provider. Another reason might be that you just want to test with a local server or determine if the agent approach is sufficient for your project goals until you go cloud.
In the following example, we’re going to imagine a print service running on a server called migrateme01. While migrateme01 was actually tested on a Linode VPS that could have been much more easily via API, this is simply to illustrate that you could still manage a cloud system or stand alone physical server in this way using Cloudkick.
Of course, the benefits of API controlled nodes becomes apparent as you move beyond simply one or two servers. Frankly, agents are a lot of work and if you can go API — by all means do so and don’t look back unless you have strong reasons otherwise.
Now for the agent example…
The instructions from Cloudkick are straightforward and the completion of those instruction will appear much like this basic example for RHEL/CentOS system we’ll call migrateme01 that handles printing services:
Once you get the [OK] you’ll want to go back to your dashboard to see that migrateme01 has appeared.
Now that migrateme01 has been added the benefits of Cloudkick come to life.
Keep in mind that with any agent architecture, including Cloudkick agent, if there is a mismatch between the agent and the service behind it, you are the one having to perform the updates and upgrade the agents. That’s fine for a handful of systems but when you move beyond two or three that starts to be a massive distraction.
Having the flexibility of an agent approach for your cloud dashboard is important. It becomes critical if you are using solutions like Google SDC to connect to the Google Apps cloud. Otherwise, you would need yet another solution to keep watch over the behind the scenes portions of a Google Apps project. So if you want to get a more encompassing picture of your other cloud services, Cloudkick agent is a nice compromise until there is a API approach.
In short, the Cloudkick approach to cloud management via API is a sound choice but even when you have the odd situation of a physical server (crazy right?) there is coverage in the form of an agent approach.
How are you managing your mix of physical, virtual, and cloud services today? Let us know in the comments below!
