In his post he first mentions some "absolute minimums" that the service must have/be:
- Readable access to all data, code, frameworks and meta data that may have been created as a result of using the service
- Secure, scalable, resilient and charged for on an "as use" basis
- Clearly communicate T&Cs that cannot be changed without reasonable notice, and reasonable alternatives
- Transparent pricing
Rule 1: I want to run the service on my own machine.
This enables me to trial out a service before even considering adopting a cloud version and gives me a last resort fall-back option. I certainly don't want to be in an environment where I can't do this for whatever reason, including vendor failure or discontinuation of a product.
Rule 2: I want to easily migrate the service from my machine to a cloud provider and vice versa with a few clicks of a button.
If the test went well then I'll probably consider dipping my toe in the water. Hence I want an easy to use transfer mechanism for my data (including any code or framework elements) from my machine to an external cloud provider and vice versa. I do not want to learn any specialised skills nor require any technical knowledge beyond pressing a button.
Rule 3: I want to easily migrate the service from one cloud provider to another with a few clicks of a button.
If I'm going to use a cloud service then I want a choice in providers and an easy mechanism of switching between alternatives. I do not want to discover that switching only covers half of the service and fails to cover other elements like the storage subsystem or a messaging service.
He ends his post by saying that, "For these reasons, I'm not very happy with most of the current cloud offerings".
After reading Simon's post there was a sense of validation. His bare minimums and rules are all core to our fundamentals at Reasonably Smart. Portability, transparency, ease of use, reliability, security, scalability are what we are building and delivering with the RSP. The only exception could be meeting the "pricing transparency" requirement but that's only because we aren't charging yet. Once we start billing (launch of v1.0), we are going to be billing for consumption in a utility model (pay for use) and our pricing plan will be clearly explained on our new website. See the post on our pricing model.
We realize we have a ways to go to prove out that the fundamentals are consistently delivered. However, we will continue to build the business based on our core philosophy. The great thing is now we can print out Simon's post and put it on the whiteboard as both a reminder and encouragement.
Thanks Simon.