This work is licensed under a Creative Commons Attribution 4.0 International License.
(An addendum to "Increasing Freedom and Confidence in Software as a Service")
| Problem | Likelihood of happening | Risk of harm | Degree to which free cloud ameliorates problem |
| Availability/Reliability | |||
| Provider can go out of business or withhold service | Wikileaks and social networks provide examples, and shake-outs in the industry are likely to happen | Data loss can be mitigated by redundant storage, but unique application is | New instances of application can be started quickly on a new site |
| Provider can lose service temporarily | Occurrences range from occasional to common | Business is interrupted, and customer can face liability issues | New instances of application can be started quickly on a new site |
| Upgrade can remove a feature I need or introduce a bug | As with any software upgrade, this is likely to happen | No recourse except to ask for restoration of old version | Customer has option of running old version or fixing current version |
| Provider may lose or corrupt data | No well-known instances yet, but errors are likely | Data loss can be mitigated by redundant storage | Because data is always stored off-site, redundancy can preserve data |
| Security/Privacy | |||
| Cloud presents attractive target and may have exploitable flaws, as well as malicious staff who steal or alter data | Many large institutions have been targeted, so cloud providers will be as well | Encryption can prevent loss, but consequences could be extremely serious and unknown for some time | Storing data off-site may decentralize targets |
| Provider may surrender data to government | Google and others provide examples | Encryption can prevent loss, but consequences could be extremely serious | Storing data off-site makes it harder for government to find, and need to demand data from customer creates more assurances of privacy |
The separation of layers, with well-defined public interfaces, maximizes innovation and maintainability by allowing one layer to change and still interoperate with other layers. But some system features cannot be isolated to one layer, so once in a while, one cannot escape the need to change a lower layer to accommodate a change in a higher one. By the same process, a change in a lower layer may occasionally stop a higher layer from functioning properly. This provides a mechanism for cloud providers to remove support from old versions of software, whether inadvertently or deliberately.
If a cloud provider decides to actively suppress the use of an old version--or simply loses interest in supporting it--the provider can change the underlying software in such a way that the old version no longer works. As mentioned, the separation of layers was designed to minimize this possibility and will do so if treated in good faith. But we can expect incompatible changes to crop up from time to time.
If a cloud provider refuses to provide an old version of a platform, open source should allow other providers to do so in its stead. But there may not be enough business reason to do so, or the old version may have bugs severe enough to make its removal from usage truly well-advised. The other solution to incompatibility is for someone to marshal the resources to port the old version of the higher-level software to the new lower-level platform.
Andy Oram is an editor at O’Reilly Media. This article represents his views only.
Author’s home page
Other articles in chronological order
Index to other articles
This work is licensed under a Creative Commons Attribution 4.0 International License.