When I talk to prospective customers about the Cloud Storage Engine for MySQL (ClouSE) the question of cloud reliability often comes up, especially recently in the light of the outages in AWS.
Cloud outages lead to a lot of publicity. Cloud opponents jump in with “that’s why I haven’t moved to the cloud and never will”, cloud proponents rebut with “N rules for building highly available applications for the cloud”, cloud competitors call on customers to move to their cloud. But it’s important to look into details, because not all outages are created equal.
Here is the data I found on the AWS outages in the last couple of years:
Can OLTP database workloads use Amazon S3 as primary storage? Now they can, thanks to the Cloud Storage Engine (ClouSE), but the question is: how fast?
When I was a little boy, I thought the Old New Year (Jan 14) was the day when the New Year becomes “old”, becomes the current year, the thing of the present. To the mind of a little systemic thinker it made perfect sense – if there was not a date when the New Year stopped being new, how would we be able to celebrate the New Year that comes after it?
Later I learned that the Old New Year was just Jan 1, but by the Julian calendar. So in a sense the reason for this informal holiday is that little details of the relationship between the Earth and the Sun were ignored and it led to a growing gap between the tropical year and the calendar that tried to express it.
At OblakSoft we have other things to celebrate besides the Old New Year. We started a new company and launched a public Beta of our first product: ClouSE – the Cloud Storage Engine. At a high level, though, the problems that ClouSE is trying to address in Cloud Computing are somewhat similar to the ones the Gregorian calendar has solved in date counting: to take into account little details of the relationship between the cloud provider and the cloud consumer and to close the gap between the cloud computing promise and cloud computing reality.