2030 the Personal Computer will be reinvented by several independent start-ups who dislike the lack of independence they get from a centralized processing net with dumb tablets connected to it. They will point out the efficiencies and cost-effectiveness gained when every user has their own computer on their desk.
2031 Apple will sue them.
"Some mission-critical enterprise apps will not lend themselves to cloudification and security concerns for some will trump cost considerations. But why would you not use cloud versions of software such as CRM, email, billing and office apps?"
This is all from a very jaundiced security perspective, and it is only scratching the surface.
Due Dilligence.
A good starting point is probably ISO27K certification to verify that the controls are documented and then SOC1 and SOC2 certification to verify that the controls are being operated effectively. Map this to a not uncommon scenario where the 'service provider' you are dealing with is using compute infrastructure from a second party who is, in turn, using physical facilities from a third party. The physical guys may have heard about SOC1 and may well have ongoing certification because it's good for business, the layer up may have heard of ISO27K and are likely to be getting certification 'any time now' but a SOC2 will bring a wrinkle to their brow. The organisation that your business wants to deal with is looking at you blankly on all fronts.
Stop that or you will go blind.
Are you getting on top of your network/system/application/user/admin/.... monitoring? Have a SIEM and starting to get some value out of it? Factored that into your Cloud solution? So you have events arriving via syslog or you are polling using WMI to get a view of your assets that is comparable to that which you get with on-premise solutions? Dream on.
Dependence on exposed services.
Calling web services or doing other fancy stuff with DNS resolution on public DNS servers? Are you factoring in the risk of these services being compromised? The more entangled you get from an infrastructure perspective with your cloud service provider the greater the likelihood that you will have to start looking at these issues.
Human resources.
Disgruntled employees. Is it a concern for you within your organisation, how do you deal with them? How do all the potential organisations in your supply chain deal with them (see Due Dilligence).
Procurement.
There are some interesting challenges here. Is the cloud provider signing a contract with you are are you signing a contract with them, if the latter then you are going to have very little control. The whole due dilligence here will also be way beyond your procurement folk and concepts like data sovereignty are going to take a lot of explaining. If you are also moving into an environment where date breaches can attract serious penalties (like here in the land of Vulture South) then you have to try and factor that into the contractual arrangements.
Contract Management.
So you have a contract. Fabulous. Has anyone seriously seen all the clauses in the contract managed and enforced? Have you estimated how much effort that will take given that you have lost visibility of a lot of things that are important?
Conclusions...
"CRM, email, billing and office apps". These are all probably significant if you have data breach legislation.
Is it really worth the effort?
Excellent post and all good points.
The resources required to do what you say in house are significant and are realistic only for the size of business that has always been able to run complex systems in house.
The promise of cloud based services is to bring some of the benefits of complex business systems to companies that have no prospect whatsoever of being able to afford to deliver them in house, namely SMEs and startups. For those businesses the choice is either to use the cloud or to become progressively less competitive, and eventually die. The risks you describe are, for this class of company, unavoidable risks of doing business. What they probably need is a bit of consultancy from someone like you who understands the risks of the cloud and can help to mitigate them.
The resources required are in this case related to the effort dedicated to governance. This doesn't really correlate with the complexity of individual systems but will be correlated with the complexity of the systems run across the organisation and the impact of a compromise of those systems.
Looking at it from a different perspective, Email may be (relatively) simple (ever configured sendmail?) but the contents of email will be very sensitive. This warrants a high level of governance.
So the simplicity of the technology is trumped by the sensitivity of the information it maintains.
This is bang on; it's not the technical complexity of the systems but the governance, regulatory requirements and compliance monitoring that elude the techies but can seriously impact a company's risk and liability profile.
Cue blank look on your local cloud vendor's face.....
"Since when are email servers and office apps "complex systems"?"
The last email system I worked on had over 140k clients (vastly more addresses, groups, mailboxes, etc) and had at the time one of the largets email archiving systems in the world (by data size), we also had 140k office clients. This was all distributed globally, backed up, replicated and as high availability as possible.
Yes, it was complex.
"The last email system I worked on had over 140k clients (vastly more addresses, groups, mailboxes, etc) and had at the time one of the largets email archiving systems in the world (by data size), we also had 140k office clients. This was all distributed globally, backed up, replicated and as high availability as possible."
Err no, thats not complex. Its just large. If you want complex try an air traffic control system. But then I suppose anything is complex to someone who's never actually worked on something complex.
The Due Diligence issues can be summarised in one word
2e2
All the while an administrator (financial, that is, not systems) can say "Pay us more than you agreed to contractually or we won't return access to your data to you", just what cost/reliability improvements are really there vs rolling your own, if you properly risk-manage this ELE possibility ??
It comes down to whos contract is being executed. If it is the service providers then what you say is very true. If, on the other hand, it is your contract in your jurisdiction then you may have a leg to stand on. But if it is a big provider you are probably signing their contract.
What I'd really like to see (purely from my selfish individual viewpoint, I'm not making business decisions about cloud strategy) is an analysis of the financial stability/viability of cloud storage providers.
Given they are (almost) all pursuing the freemium approach, how confident can I be that my 5Gb of files at cheekycloudstartup.com won't be switched off by the administrators tomorrow or that Google won't suddenly decide that drive is non-core (I feel that this one is fairly low-risk :~) and will be deprecated next week?
I've been wondering about the etymology of the term 'cloud computing'. I suspect it's a case of a term with negative connotations being embraced, but I'm looking for some evidence.
i.e. I assume it started with fans of on-premises computing saying you want your data to be where you can see it, not 'in the clouds', and then became the term used by the people making the opposite argument.
Anyone know?
As I recall it, the term 'cloud' used to refer to network-based SaaS was around before the 1997 Chellappa paper; the long-dead company General Magic (a spin-out from Apple, founded by Bill Atkinson and Andy Hertzfeld) pioneered the notion of mobile code that could migrate across what they called the "Telescript Cloud" (Telescript being their mobile language) in the min-90s.
Even for a "potted" history, this article has some big holes - Service Bureaus and Grid computing to name just two.
IBM's Service Bureau Corporation and Lyons' LEO bureau are worthy of mention as an "economic concept" that underlies and predates Cloud, even if they weren't part of the direct technological lineage.
The total omission of Grid computing is even more bizarre; it was an important step beyond cycle stealing and the commodity compute clusters developed in academia - mostly for HPC - in the late 1980s/early '90s. Ian Foster's notion of the Grid was a computing utility grid; Cloud computing is largely an embodiment of that idea with some of the practical issues ironed-out (or maybe not).
One important aspect that was lost (or did I miss something?) is the availability of high-speed broadband internet, without which the Cloud make no economic sense whatsoever to SMEs. Trevor Pott wrote an excellent piece on that issue.
Even now, where one has facilities "off the beaten track", ie: away from the well-served urban areas, broadband is non-existent or very expen$ive.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
