I signed up for Apple's Mobile Me service a while ago as it offered convenient syncing between Macs and other devices. As part of the package, I also got some online storage which I used as backup for archival material - stuff that didn't change. I hoped that I'd never need it. Now, mobile me is shutting down and I have to decide what to do.
My requirements are pretty simple - I need 7-8GB of storage that I will write once and hopefully never read. I don't want to share files, access them from my phone, etc. I don't mind paying so long as the cost is commensurate with the usage i.e. I don't want to pay for 50GB when I only need 8.
If you are a Mac user, then icloud offers some online storage - but I don't use Lion on my principal Mac laptop - I have not been impressed by Lion and see no real benefits to upgrading. It is possible to upload files from a browser without Lion but it's a pain. So - that's out.
I already use Dropbox as my normal working storage system and, as an early adopter, I've recommended a few people so I have an 8GB free quota, of which I use just over 50%. However, Dropbox don't have a pay per usage model and I really don't want to pay $99/year for a lot more online store than I really need. One option might be to put some stuff into my Dropbox and other stuff elsewhere if I can't get the free storage that I need.
Google launched their Google Drive a few months ago, as a Dropbox competitor. I accept that Google have to make money and if you want free services, then you have to give up something. I'm happy to host this blog on Google and if they scrape it and target advertising to me so be it. But there's nothing of value on this blog or on my Google-hosted website but my files do have something of value (the text of a number of published books) and I am reluctant to hand these over to Google. There is a key sentence in their terms of conditions that make them different to over providers:
The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones.
By contrast, Dropbox says:
You give us the permissions we need to do those things solely to provide the Services.
So, if Google decide to develop publishing services (by no means impossible) then in principle at least, they could use my books as examples of these services. OK - I am maybe being paranoid here but I really don't trust Google. On the other hand, Dropbox are less likely to expand into different areas so I'm more willing to take the risk with them.
There are several alternative storage providers - Microsoft who offer 7GB free with their skydrive system, Sugar Sync who offer 5 free GB and Box, who also offer 5GB. Skydrive was the most appealing as it would allow me to keep more or less everything I needed to archive in one place. However, my experiment with Skydrive lasted only a few minutes however. It shared the usual Microsoft idiocy about restrictions in file names - it didn't like names like C3-examples(C++). I had no intention of trying to find all the files it wouldn't like and change the names so abandoned Skydrive.
Sugar Sync was my next attempt. It is obviously trying to attract users and compete with the market leader Dropbox so they offer quite a lot of free storage for referrals and for sharing links. I referred my wife and shared a few links with her and my daughters so managed to get the free allowance up to more or less what I needed for my archive. No nonsense with file names this time and the nice thing about Sugar Sync was that it didn't require me to move the files to a separate directory.
Because it doesn't use a dedicated syncing directory, unlike Dropbox or Skydrive, SugarSync is wee bit more complicated setting up the syncing across computers - but I didn't find it too bad.
Upload is not fast - in fact, it is very slow over a home ASDL connection.It will take a while for me to upload 5GB but once it is there, the slowness won't matter.
I am a bit paranoid about the free services going out of business and the possible loss of files. Therefore, I would NEVER rely on any of these to maintain the main copy of a file. So, I reckoned that I should have a backup for SugarSync. Box.com offers 5GB free to personal users, although it is primarily aimed at businesses. Facilities for personal users are minimal - no syncing so I don't see it as a Dropbox alternative. But this is what I wanted really as I had no idea how syncing the same folders across two different services would work
Box.com may be geared to businesses but I really can't recommend it. Like skydrive, my experiment with it only lasted a few minutes. I couldn't select a folder to upload - it would only upload files. It had a thing called 'Bulk upload' but this wouldn't work on my browser - possible because my default is to disable Java. I couldn't be bothered wasting time trying to get it to work.
Dropbox is the market leader - for good reason - I reckon it's the best for personal cloud storage. Sugar Sync seems to be OK but the others are certainly not for me. I will try Google Drive sometime but probably just to maintain things that are linked from my website.
Update: September 2012
I used SugarSync for a while and it was OK - but the client is very processor hungry on a Mac - it shortened battery life significantly and my laptop ran very hot. So, I stopped using it.
Monday, 25 June 2012
Thursday, 26 January 2012
Cloud security: A risk driven perspective
One of the reasons that organisations give
for not moving their IT to the cloud is concerns about computer security. As a
consequence, the area of cloud security is a ‘hot topic’ – an appropriate
classification as the debate sheds more heat than light on the issue of
security and cloud based systems.
A fundamental principle of security is that
you should always approach it from a risk-driven perspective. It is impossible
to achieve complete security so you assess the most likely or the most
consequential risks and protect against these. You may insure against some of
the other risks or you may simply accept them because they are unlikely to
arise.
It seems to me that this has been forgotten
in the discussions on cloud security. There are extensive discussions on ‘security
risks of moving to the cloud’ but these take place in isolation, without
considering the security risks of ‘not
moving to the cloud’.
A simple example will illustrate this. A
possible security risk, which is unique to the cloud, is that hypervisor
vulnerabilities allows data to leak from one virtual machine to another. This
is certainly a theoretical risk and I believe that it may have been
demonstrated as a possibility. But I could not find a single example of this
arising in practice, with ensuing loss to cloud users.
Contrast this with the figure in the SANSsurvey of top cyber-security risks which found that the most common
vulnerability was unpatched client-side software. If you move to a SaaS environment, you can
dramatically reduce the effort required for management and it is much more
likely that the services offered are updated in a timely way when
vulnerabilities are discovered.
If we take a risk driven perspective, we
should not worry about theoretical risks but about the real everyday risks that
affect operation. The CSI computer crime survey suggests that more than 40% of losses are a consequence of
insider attacks. Moving to the cloud will, at worst, be neutral here. It could
improve security as the centralized operation means that there are likely to be
fewer local vulnerabilities that can be exploited by insiders.
The other major common risk is the risk of
vulnerabilities through the carelessness of users. These may be weak passwords,
systems left logged on, sharing of authentication, and so on. Moving to the cloud won’t solve this problem
but again there is a possibility of more control improving the situation.
Two other areas are presented as cloud
security risks but are no such thing:
- Third-party access to data. This is a general outsourcing risk rather than something that is specific to the cloud. If you outsource your payroll processing, you are taking exactly the same risk. Before you outsource anything, you should go through a due diligence process to convince yourself that the service provider can be trusted. Cloud services are no different here and the old adage that ‘you get what you pay for’ is as true for clouds as for every other area.
- Compliance risks where specific types of data have to be subject to particular jurisdictions. For sure this is a serious issue and, for sure, it may make the choice of cloud provider difficult. The possible hassle may mean that it’s simply easier no manage the data in-house. But this is NOT a security risk (security is about confidentiality, integrity and availability), nor is it specific to the cloud. Again, it is an outsourcing risk that has to be considered – and which will become less of an issue as cloud providers are able to guarantee where your data will be located.
In summary then, we need a common sense
approach to cloud security. The reality is that if you believe that your
current system is secure, you are probably deluding yourself. Moving to the
cloud may not bring any extra security issues of any significance but may
improve the security of your information.
Thursday, 8 December 2011
Hidden costs of cloud computing
This Computerworld article on the real costs of cloud computing makes a lot of sense. Cloud providers never tell you about these when they are hyping their offerings. In my opinion, cloud computing still makes sense economically for most companies but you have to be realistic about the savings that you can actually achieve.
The costs that are hidden/unanticipated are:
1. Data transfer costs. These can be pretty significant one-off costs when you move your data to the cloud.
2. Integrating apps from multiple vendors. More of an issue for SaaS than IaaS but a real problem if you go for multi-platform cloud providers. I'm not sure I would class this as a 'hidden' cost though - its a pretty obvious problem.
3. Software testing costs. You can't just move software to the cloud and expect it just to work. You need to spend significant resources on a testing programme.
4. Space and energy. Many organisations meet space and energy costs centrally and these don't show up on departmental budgets. Don't expect to get this money back when you move to the cloud - and you will have to meet these costs upfront.
The costs that are hidden/unanticipated are:
1. Data transfer costs. These can be pretty significant one-off costs when you move your data to the cloud.
2. Integrating apps from multiple vendors. More of an issue for SaaS than IaaS but a real problem if you go for multi-platform cloud providers. I'm not sure I would class this as a 'hidden' cost though - its a pretty obvious problem.
3. Software testing costs. You can't just move software to the cloud and expect it just to work. You need to spend significant resources on a testing programme.
4. Space and energy. Many organisations meet space and energy costs centrally and these don't show up on departmental budgets. Don't expect to get this money back when you move to the cloud - and you will have to meet these costs upfront.
Monday, 26 September 2011
How long should cloud outsourcing contacts be?
It was announced last week that Thomas Cook (TC), the travel company, had signed a 10-year contract for cloud services with Accenture. (Computerworld article). Their aim was to make annual savings of up to (my italics) £50 million in IT services.
Now, I don't know how much that Thomas Cook spends on IT but according to their own website their turnover in 2010 was £8.9billion and profit was £429 million. So, let's say they get close to their £50 million annual saving and all of this shows on the bottom line - a 10% profit increase - looks pretty good.
However, the whole cloud computing landscape is changing incredibly quickly - 10 months let alone 10 years is a long time and tying yourself into a long-term contract at this stage means that you may not be able to take advantage of what I suspect will be much greater savings that will emerge from the use of cloud systems in the next few years. These savings are not just going to come from IaaS (TC's savings) but from SaaS where services from different providers are put together to allow much more end-user self-service.
It seems to me that this is particularly likely in the travel industry which has, in many respects, led the way in self-service - on-line check in, print your own boarding pass, etc. So, by tying themselves to a 10-year contract, I think it is going to be harder for TC to take advantage of this innovation. Even worse, as other more agile companies do so, TC risk losing customers - they may save £50 million in IT costs but could lose much more as customers move to companies that offer better cloud services.
So, what is the balance between stability and flexibility that companies should be looking for? Obviously, constant IT change is simply disruptive and so some continuity is essential. But companies need the ability to be agile as cloud computing develops and to take advantages of both costs savings and new opportunities to partner with other innovative companies in the sector. Obviously, the balance between stability and flexibility will vary from sector to sector but having any contract for cloud services that ties you in for more than 3 years seems to me has the major risk that you will simply either be left behind as the world changes or that your projected savings will evaporate as you have to make new investments to keep up.
Now, I don't know how much that Thomas Cook spends on IT but according to their own website their turnover in 2010 was £8.9billion and profit was £429 million. So, let's say they get close to their £50 million annual saving and all of this shows on the bottom line - a 10% profit increase - looks pretty good.
However, the whole cloud computing landscape is changing incredibly quickly - 10 months let alone 10 years is a long time and tying yourself into a long-term contract at this stage means that you may not be able to take advantage of what I suspect will be much greater savings that will emerge from the use of cloud systems in the next few years. These savings are not just going to come from IaaS (TC's savings) but from SaaS where services from different providers are put together to allow much more end-user self-service.
It seems to me that this is particularly likely in the travel industry which has, in many respects, led the way in self-service - on-line check in, print your own boarding pass, etc. So, by tying themselves to a 10-year contract, I think it is going to be harder for TC to take advantage of this innovation. Even worse, as other more agile companies do so, TC risk losing customers - they may save £50 million in IT costs but could lose much more as customers move to companies that offer better cloud services.
So, what is the balance between stability and flexibility that companies should be looking for? Obviously, constant IT change is simply disruptive and so some continuity is essential. But companies need the ability to be agile as cloud computing develops and to take advantages of both costs savings and new opportunities to partner with other innovative companies in the sector. Obviously, the balance between stability and flexibility will vary from sector to sector but having any contract for cloud services that ties you in for more than 3 years seems to me has the major risk that you will simply either be left behind as the world changes or that your projected savings will evaporate as you have to make new investments to keep up.
Thursday, 30 June 2011
The Cloud and the Patriot Act
The Patriot Act is a US Act that essentially says that the US Government can access and intercept any data held by anyone on US territory. There has been quite a lot of vagueness about whether or not the scope of this Act extended beyond US territory and cloud providers such as Amazon have, in my view, avoided making any statements on this.
Microsoft in their official release of Office 365 have now clarified the position as they see it. Their view is that any US-headquarted company that maintains data are bound by the Act irrespective of where that data is stored. Therefore, data stored on a public cloud run by one of the big providers can be accessed by the US Government.
This hasn't yet been tested in court but what it means for cloud users is that if you have any reason to think that your data might be of interest to the US Government, then don't use a US headquartered company for cloud services. Even if (like me) your data is completely innocuous, Governments have been known to get things wrong and you may not wish to take the risk.
This clarification is great news for local cloud providers in the UK and an opportunity to pick up business from organisations that are risk averse on compliance issues. For sure, they are not bound by the Patriot Act and they can guarantee that there will be no US Government snooping.
Microsoft in their official release of Office 365 have now clarified the position as they see it. Their view is that any US-headquarted company that maintains data are bound by the Act irrespective of where that data is stored. Therefore, data stored on a public cloud run by one of the big providers can be accessed by the US Government.
This hasn't yet been tested in court but what it means for cloud users is that if you have any reason to think that your data might be of interest to the US Government, then don't use a US headquartered company for cloud services. Even if (like me) your data is completely innocuous, Governments have been known to get things wrong and you may not wish to take the risk.
This clarification is great news for local cloud providers in the UK and an opportunity to pick up business from organisations that are risk averse on compliance issues. For sure, they are not bound by the Patriot Act and they can guarantee that there will be no US Government snooping.
Tuesday, 14 June 2011
Cloud confusion
We are involved in project where we are helping a number of companies in managing the migration of their software products to the cloud (website here). At today's meeting, it became clear that even these technically-sophisticated companies were a bit confused by the fact that everyone is talking about 'clouds' but are (perhaps deliberately) using the term in quite different ways.
This blog post by Paul Woodward from Symetriq, a Scottish hosting company, sums up part of the problem but some of the confusion comes from mixing up the notion of service provision (infrastructure, platform, software), remote hosting of servers, payment models (pay per use rather than outright ownership) and the management of scale and elasticity. The notion of 'private' and 'public' clouds doesn't help, especially when sometimes 'private clouds' are remotely hosted by a 'public cloud' provider.
So to clarify what I am talking about, here are my thoughts on what some of these terms mean.
A cloud is a set of servers that is controlled by some cloud management software that can automatically start and stop virtual machines running on these servers. The overall cloud configuration therefore is elastic and changes dynamically. A statically configurable set of VMs which is manually configurable is not a cloud.
You have a private cloud if the physical servers running your software are only used for that purpose. These servers can be remotely hosted but you should be able to identify your specific servers at that site which are yours.
You are running on a public cloud if the cloud provider decides on the server where your virtual machines will be scheduled and you have no control over this.
There is no such thing as 'the cloud' as an entity. However, 'the cloud' may be an easy way to refer to the general notion of running software or managing date on remote clouds, without being specific about what these are.
A service is something that is potentially offered to a number of customers who use that service without owning the underlying system that provides the services. Now ownership is a confusing notion for software anyway. When you buy a licence for some software, the terms and conditions mean that you don't necessarily own it in the same way that you own a book that you buy from a bookshop. However, I think of owning software as paying for the right to deploy the software on whatever machines I wish, obviously depending on the licence. If I don't control the deployment, I don't own it.
Therefore, if you buy some software functionality from someone else who deploys that software, you are buying a service. Buying a service doesn't have to be pay per use - you might pay according to a subscription model, which allows unlimited use over some time period. Dropbox, for example, offer a storage service where you pay an annual subscription for a given amount of storage whether or not you use it.
A cloud service, however, is distinguished by pay per use. Therefore, buying storage on Amazon is definitely pay per use - you pay according to the amount used. Dropbox don't offer a cloud storage service although they may actually use a cloud storage service to implement their service (this is a guess - I don't know). Interestingly, you can offer a cloud service without actually hosting the underlying platform on a cloud.
So, if we are talking about migrating software products to the cloud, then there may be a number of stages in this process
1. Moving the payment model for the product from a one-off licence to an annual subscription, with the product provider responsible for hosting the software.
2. Re-architecting the software product so that it is implemented as a set of services. The product is still presented as a monolithic system.
3. Selling individual services rather than the whole product, perhaps on a subscription model
4. Implementing a metering system that allows services to be charged according to usage
It is only when you have reached this last stage, that you can say truly say that you have implemented services on the cloud. But, from a business point of view, you might want to stop earlier in the process.
This blog post by Paul Woodward from Symetriq, a Scottish hosting company, sums up part of the problem but some of the confusion comes from mixing up the notion of service provision (infrastructure, platform, software), remote hosting of servers, payment models (pay per use rather than outright ownership) and the management of scale and elasticity. The notion of 'private' and 'public' clouds doesn't help, especially when sometimes 'private clouds' are remotely hosted by a 'public cloud' provider.
So to clarify what I am talking about, here are my thoughts on what some of these terms mean.
A cloud is a set of servers that is controlled by some cloud management software that can automatically start and stop virtual machines running on these servers. The overall cloud configuration therefore is elastic and changes dynamically. A statically configurable set of VMs which is manually configurable is not a cloud.
You have a private cloud if the physical servers running your software are only used for that purpose. These servers can be remotely hosted but you should be able to identify your specific servers at that site which are yours.
You are running on a public cloud if the cloud provider decides on the server where your virtual machines will be scheduled and you have no control over this.
There is no such thing as 'the cloud' as an entity. However, 'the cloud' may be an easy way to refer to the general notion of running software or managing date on remote clouds, without being specific about what these are.
A service is something that is potentially offered to a number of customers who use that service without owning the underlying system that provides the services. Now ownership is a confusing notion for software anyway. When you buy a licence for some software, the terms and conditions mean that you don't necessarily own it in the same way that you own a book that you buy from a bookshop. However, I think of owning software as paying for the right to deploy the software on whatever machines I wish, obviously depending on the licence. If I don't control the deployment, I don't own it.
Therefore, if you buy some software functionality from someone else who deploys that software, you are buying a service. Buying a service doesn't have to be pay per use - you might pay according to a subscription model, which allows unlimited use over some time period. Dropbox, for example, offer a storage service where you pay an annual subscription for a given amount of storage whether or not you use it.
A cloud service, however, is distinguished by pay per use. Therefore, buying storage on Amazon is definitely pay per use - you pay according to the amount used. Dropbox don't offer a cloud storage service although they may actually use a cloud storage service to implement their service (this is a guess - I don't know). Interestingly, you can offer a cloud service without actually hosting the underlying platform on a cloud.
So, if we are talking about migrating software products to the cloud, then there may be a number of stages in this process
1. Moving the payment model for the product from a one-off licence to an annual subscription, with the product provider responsible for hosting the software.
2. Re-architecting the software product so that it is implemented as a set of services. The product is still presented as a monolithic system.
3. Selling individual services rather than the whole product, perhaps on a subscription model
4. Implementing a metering system that allows services to be charged according to usage
It is only when you have reached this last stage, that you can say truly say that you have implemented services on the cloud. But, from a business point of view, you might want to stop earlier in the process.
Subscribe to:
Posts (Atom)