IMO cloud services are just services. There is nothing cloud about them. From an end user perspective, whether or not the service is hosted on a dedicated server or on a cloud, there is little difference. I usually have the same amount of vendor lockin. Your use of these services are so small, you probably cannot differentiate between one service that is not scalable, versus the other which is. Only customers who have huge spikes in usage would really be concerned with the benefits of a cloud host. So really many of the uses of “cloud” to me are pretty silly. Anyhow, I use three “cloud” services. A password manager, a bookmark manager, and an email account.
My business relationship with the hosts of these services falls into three categories:
1) I get the service for free, they get ad revenue.
2) I get the service for free, what they get IDK(I have never seen them display an ad to me).
3) I made a one time payment for a tool which saves data to a cloud service.
#1 is the only service I am still happy with. The other two have no real financial motivation to keeping legacy users happy, and therefore have been on a downward usability spiral.
What frustrates me is the effort I must make to migrate to another service, and that none that I have found are as good as the other services used to be. Should I want to implement the pieces which are broken, I really can’t because there is no layer that I can wedge my own functionality in. The whole stack, from client to server, is proprietary and has no interoperability layers. Even if I write my own solution, I need a host for some executable code. This rules out shared web hosts, leaving only cloud computing hosts like Amazon or a dedicated host. The former leaves you somewhat locked in to their architecture, and the latter is far to expensive to use as a personal service. Steps can be taken to layer your architecture to make it more portable to other cloud computing systems, but this is not a trivial process and many solutions have drawbacks.
I see two alternative or possibly interworking solutions to these problems.
1) Standardized data storage API which various hosts supply. Imagine being able to go to DropBox, or SkyDrive, or your data storage paltform of choice, purchase space, then point all your cloud services at them saying “Store my data there”. In combination with this, some standardized APIs that allow you to setup cross provider redundancy/sync. Clients would be able to automatically failover to the other service whenever one is down. You would be protected from vendor lockin, or any of the many unfortunate things that can happen to your data when you really on a single company for that data. Additionally, these providers should offer a reduced redundancy pricing option, where they do not backup your data, and instead you depend upon the redundancy offered across the multiple providers.
Everything from password managers to bookmark managers would utilize web APIs to persist your data to the storage providers which you have purchased space with. Whether or not the data is encrypted before it is stored in the storage service is up to the author of the tool. The problem with services like dropbox is that you usually must take steps to encrypt your data if you want it protected in the case they have a malicious employee or are compromised by a hacker.
2) Aside from the standardized storage API, the services/clients that utilize this API, should share some standardized file formats or APIs. Perhaps even the service software should be open source. Consider subversion for example. It is free and open source, yet there are lots of service host making money off of it. How? Well hosting your own subversion server is usually cheaper if you rent shared hosting for it. You can instead purchase hosting from a variety of providers.
The important thing is if you want to utilize your own systems to host the service, you have that option. If you want to switch to a different service, you have that option. Your data is stored with the storage providers, not with the service application host. Why are you paying the service application host? Because they are providing the compute hardware. They installed the server software and configured it. They did all those little things that they are good at doing, and can do quickly and inexpensively, which would instead take you hours upon hours to do yourself. They monitor the systems. They can setup the system to notify you if one of your redundant storage providers goes down(meaning you are still online with your remaining storage providers).
For performance reasons, service providers could offer both the application hosting and storage hosting(similar to Amazon) yet still have redundant failover and vendor flexibility because both services interact through a standardized API.
There may be services and APIs like this already. If there are, or if there ever was, the key will be lots of developers creating various services or clients that make use of these APIs. Initially people would probably install open source services and storage providers on their own hardware, but as hosting companies see an opportunity to make money, they will install the services themselves and begin offering shared or cloud hosting options that expose these APIs.
Unfortunately it is something I really don’t have time to work on, or else it would probably be something I’d be very interested in prototyping and thinking about some of the grittier details.