What is Cloudorado?

Cloudorado is a price comparison service of cloud computing providers. It could be also referred as a price calculator for multiple cloud hosting providers, since the comparison is performed by calculating price for individually set server needs. It currently focuses on Infrastructure as a Service (IaaS) providers.

Can't you just say which cloud computing provider is the cheapest?

There is no cheapest cloud computing provider. Each provider has different pricing models, different relation between resources, different packages and so on. If you play with Cloudorado a bit, you will quickly find out that a provider which is the cheapest for one cloud server might be the most expensive for another one. The price is multidimensional function, where are at least 9 factors which can be taken into consideration. We allow to you to find the cheapest provider for your needs without effort.

Do you also compare PaaS providers?

We are working on providing a comparison for PaaS (Platform as a Service) providers. Stay tuned.

Why can't I set a number of servers of a given type?

When you need more than one server, it usually means you need some resource in a quantity that cannot be delivered in a single server. It might be, for instance, CPU for computation, RAM for Memcached tier, or HDD for Hadoop storage. So instead of specifying a number of servers, just specify how much RAM, CPU, or storage you need and select Distribute. The engine will automatically find the best type and number of servers to fulfill the need. This option is available only in advanced mode.

What does the Distribute switch in advance mode means?

It is used to tell the engine that the provided value for that resource is for a whole server group, regardless how many servers are going to be needed to meet the requirement. The engine will determine the best number of servers to meet the requirement.

See also Why can't I set a number of servers of a given type?

How do you measure CPU power?

Unlike other resources like RAM or HDD, CPU power is not so easy to quantify. Even with a physical computer, various benchmarks give different results for the same computer. In cloud servers, it gets even more sophisticated, since multiple servers sharing the same computer and load with other servers might influence CPU allocation. It is even less predictable if a cloud provider allows CPU bursting, which means using otherwise unused CPU power of other machines. Many providers don't even provide any measure of computing power.

We have decided to use an approximation of Amazon's CPU power measure - ECU. We have benchmarked various Amazon instances and it turned out that ECU is directly proportional to single-threaded UnixBench results multiplied by the number of cores. To get ECU value, it is enough to divide the single-thread UnixBench result by one of a machine with 1 ECU (Standard Small). An absolute average error of this approach compared to values provided by Amazon was just 7%. We use this method to measure ECU for other providers.

UnixBench mainly consists of Dhrystone and Whetstone benchmarks, so it reflects general purpose integer and floating point operations (MIPS and FLOPS). Obviously, you should benchmark a cloud server for a particular application, especially because the performance is virtually never directly proportional to the number of cores as ECU assumes. The ECU values we provide are just to get an idea of relation of computing power.

Note also that some IaaS providers allow only typical server use. Therefore, check the terms of use for a chosen provider if you plan to do some heavy computing on a cloud server.

What is ECU unit used for CPU power?

I get a slightly different result compared to the calculator from a provider?

Such discrepancies usually happen due to different assumed hours per month. Some providers assume 30 days (720 hours), others 365 days divided by 12 (730 hours) or even 734 hours. We assume 720 hours.

Usually such discrepancies are negligible and do not change the relation between providers. If you see larger discrepancies, please tell us.

How do you approach persistence storage?

Virtually only Amazon Web Service (AWS) has non-persistent instance storage. Therefore most of the people ignore instance storage and use Elastic Block Storage (EBS) for instance storage. With EBS severs behave as normal servers, which you can turn on and off without losing data, which is not true for instance storage. For this reason most of people accepts additional cost of EBS. Cloudorado therefore assumes EBS as storage and ignores EC2 instance storage.

We are currently working on separating persistent and runtime storage in advanced mode. Stay tuned.

Feedback