Grid Designer's Blog

GoGrid is officially out of beta, so now it's time to compare GoGrid with the public cloud market leader, Amazon EC2. Both vendors have relatively stable performance metrics and they both implement the basic functionality of a cloud provider:

• Programmatic control via REST API
• Scalable data storage solution: Elastic Block Storage in Amazon AWS and CloudStorage in GoGrid
• Ability to assign external IP addresses
• Ability to grant root/administrator credentials
• Many options to configure the cloud cluster
• Windows and Linux support
• Web console for monitoring and management

So far, as cloud providers GoGrid and Amazon EC2 look very similar, but practical experience of using them in real-life projects helps us identify some unique features that can be important for specific applications.

For Amazon EC2 we can highlight the features listed below:

• We can choose instances with different performance characteristics: Amazon EC2 has a product line that can be scaled by performance
• Support for multiple OSes, some of them powered by marker leaders such as Oracle, Sun, and IBM. Also, the community has made a big commitment to Amazon EC2 resources.
• User-friendly web console and web help
• Service popularity: most questions about EC2 can be answered on the web; it's very possible that someone else has already solved the same problem
• Start-up time for instances based on a popular AMI. It takes from 2 to 4 minutes to invoke an AMI and start the OS.
• We always have access to instances. Even if we can't have SSH access into an instance we can look onto system logs or reboot and instance using the web console.

Although there are many positive aspects for Amazon EC2, some negative points can be identified as well:

• There is no SLA for CPU, very low performance for m1.small and performance level of m1.small is unstable
• Pricing for high performance instances m1.large and m1.xlarge is not attractive
• No logging for API access
• There is only one way to build hybrid clouds: use a VPN connection to boxes outside the EC2 cluster.
• No control over instances deployment. It may happen that instances will be deployed onto one physical box, but for some applications it's critical to have instances deployed on different boxes. We can specify different regions and geozones for this application, but further control would be desirable.
• Independent namespaces for different regions: each region has its own namespace for keys, AMI, instances, etc.
• Security management isn’t always logical. For example, we can create instance without specifying a key-pair that will be inaccessible via ssh (in those rare cases when we really need it) or we can accidentally have access (and even terminate) instances that belong to the same account, but which were created with other security keys; for example, another development group in the same company.
• Startup time of custom AMI : an instance's pending time can be about 10-15 minutes.

Compared to Amazon EC2, so far GoGrid does not have a big list of different features, but despite their recent entrants to the market, they already have some unique features:

• True hybrids: we can build hybrid clouds along with colo servers, which will be located in the same network switch with virtual cloud instances.
• Logging API usage by a job's history. Actually, we can monitor all requests to GoGrid’s API.
• Non-transient instances: We can reboot instances without data-loss.

And, as with Amazon EC2, GoGrid has some challenges as well:

• The web interface needs to be more user-friendly.
• Using and mounting Cloud Storage is more complex than it is expected and it performs as a local disk drive only in case of low network load.
• Choice of OS is limited only to Windows, RedHat and CentOS.
• For cloud instances we can choose only RAM size, not different CPU levels. This point can be partially reconciled by using bare metal as part of the cluster infrastructure.
• Practical experience with GoGrid's instances shows that maintenance windows happen more often than anticipated.

Obviously, choosing a cloud infrastructure provider for a particular project should be based on determining which application's requirements will be best fitted for this cloud provider and which requirement will not be satisfied. Providing hybrid clouds with bare metal boxes can be a unique differentiator, but not all applications really need it. The main promise of cloud computing is 'resources by demand' and this can be delivered by Amazon EC2 more than GoGrid—they provide a wide variety of different infrastructure parameters (such as CPU, RAM, and OS) for instances, they have more users, and they're currently more experienced as an infrastructure cloud provider.

Labels: amazon ec2, cloud, gogrid, ~Alexey Bokov