When a friend of mine shared this image on LinkedIn it reminded me of Cloudyn’s philosophy to developing cloud cost management tools in a rapidly evolving, multi-cloud space.
Everyone knows it’s hard to make a one-to-one comparison between cloud platforms. But while some folks use this as an excuse for not even trying, we take a different approach (A perfect, apples-to-apples, cloud commodity market where identical offerings can be cleanly compared, might be very long in coming).
So in the meantime, we use available data for comparing cloud offerings and make the most of it. Like someone’s Momma used to say “if life gives you lemons, make lemonade”.
This approach not only lays the groundwork for highly accurate cloud-comparison in the future, it also adds tremendous value today for many large cloud consumers.
In this post we share our current methodology in hopes that it will aid you in getting educated more easily on available options.
Choose Your Winner
When trying to decide where your cloud workload will perform best and at the lowest price, be prepared that there rarely is a clear winner. Just as in real life, every option has its pros and cons.
With that in mind, the practical challenge is lining up comparable options from multiple clouds, based on the criteria most important to you.
At Cloudyn we’ve developed a straightforward method for doing just this.
Introducing the Best Match Policy
So let’s say you are looking at moving your workload from EC2 to GCE or vice versa and want to see the best matching instance type from the competing vendor.
While there are many criteria and factors to consider for creating a “successful deployment”, getting the right blend of CPU, RAM, and cost plays a very prominent role.
(Note: Since both AWS and Google have created their own compute units – ECU and GCEU respectively – both representing roughly the same CPU power, we will be referring to ECU/GCEU instead of CPU.)
In this example, if we do a best match search for an m2.xlarge instance based on the primary search criterion of ECU/GCEU, we get matched with an n1-highmem-2 as follows:
If we switch the primary search criterion to RAM, our m2.xlarge gets matched with an n1-standard-4 as follows:
With this comparison in hand, you now can begin to determine if it makes sense to move workloads or new projects to a different cloud, or perhaps justify why it might not make sense to do so.
What about regional proximity?
Currently AWS offers services all around the world with multiple data centers in the Americas, Europe, and Asia. On the other hand, GCE is still limited in their regional offerings.
Despite this asymmetry, we’ve mapped AWS regions to GCE regions based on physical proximity so you can modify your search based on that as well. For example, if you are running an instance in Amazon’s Asia Pacific-northeast-1, if proximity is important, we’d match it to a comparable instance in Google’s us-central2. If you have an instance in Asia Pacific southeast-1, we’d match that to Europe-west1.
Of course, as Google rolls out more regions, our comparison will incorporate these.
Start your multi-cloud comparison and porting journey
Whether you are using AWS, GCE or both, check out Cloudyn’s offerings for managing your cloud deployment cost. From pricing optimization to cost allocation and of course multi-cloud comparison, we’ve got the right tools for you.