Concept
The general concept is quite different from all the cloud providers I worked with. What I've usually seen is the main abstraction of the cloud providers was a 'Server' (or node, or vm, whatever) -- just a single VM with properties like RAM size, CPU power etc, and which is created based on some 'Template'.
Skytap does things differently: 'Server' model doesn't play the main role. The thing all the stuff's built around is 'Configuration', which is basically a collection of VMs. Configuration is created from 'Template' which is also actually a collection of VM templates. You cannot directly add a VM to configuration, you have to merge the template with a VM.
I haven't decided if I like this way of representing things or not. Surely, in some situation it's convenient to be able to group VMs and work with them as with single object and we've even implemented a similar scenario at work on top of other cloud provider. On the other hand, when you need to work on single VM level it's a bit confusing and cumbersome.
Web UI
It's ok but has some usability problems IMO. Well, I'm not a usability expert by any means, but these things just seem wrong to me.
For example: a way to API doc: Dashboard -> Support -> API -> 'How do I access API' solution -> link to developers page -> link to pdf guide. 5 steps from dashboard, not very good IMHO.
API
I have an impression that a lot of people treats any http service as REST service, that's obviously wrong. Skytap is good at this matter and their REST service is really RESTful. They even use all these fancy HTTP methods like PUT or DELETE.
Based on some error messages and headers, I assume API is powered by Rails and Mongrel. The tutorial suggests using XML, but it looks like the API supports JSON as well, but not for all resources though. Having full JSON support would be really nice. Moreover, I've been playing with Firebug on web ui and noticed that AJAX is actually using JSON to communicate with the API, so it's strange why JSON is not fully supported.
Also, API gives quite a low lever control to VMs. I.e. if you want to assign an IP address to a VM, you have to think not on VM level (like "assign address A to VM 'alice'") but on VM's OS network interface level (like "asign address A to the first network interface of VM 'alice'").
This forces you to make more API calls to get things done.
Let's look at the quite typical task: create a VM with some of public IP available on our account.
| GoGrid | Skytap |
|---|---|
|
|
So Skytap forces you to make twice more API calls than GoGrid. On the other hand, the feature of assigning public IPs wasn't documented at all in the API reference, so probably it will be changed in future and will become better. I've figured out how this works using Firebug. One more thing I haven't figured out how to handle better is the definition of term 'available IP' by Skytap. Basically, it treats IP as 'available' if it's not used by a running VM. Sooo... you can assign the same IP to several VMs. You will be able to start one of these VMs even, but other VMs with the same IP will fail to start.
There is one more thing that makes me feel quite worried: it looks like the credentials are stored in per template basis. So, if you create two configrations from the same, say, RHEL public template, the root passwords of VMs in both of your configurations will be same. I really really hope to be wrong on that or maybe that passwords are generated on per-account basis (which I cannot check as I have only one account).
Conclusion
Summarising things up I have a strong feeling that I probably don't quite understand philosophy behind Skytap and probably it's targeted for the use cases where API is not very important.
