Make no mistake about it, developers are using public cloud computing, a lot. We certainly see it in our daily business interactions. The high level of usage (and its somewhat clandestine nature) was illustrated at a conference earlier this year when one CIO noted that he had gone through the expense reports turned into him for reimbursement and found 50 different cloud computing accounts being used by developers in his organisation. The reason? It's a lot easier for a developer to obtain computing resources from a public cloud provider than to undergo the extended waits typical of the existing compute environments.
The upshot of all this is that today decisions are being made by developers about use of cloud computing that upper levels of the organisation are unaware of (the CIO just cited is undoubtedly an exception to the general rule). A corollary to this is that IT organisations will discover new public cloud-based applications in a year or two that they had no idea were being placed in those cloud environments.
The ramifications to this are significant:
1. Organisations will be taking on operational responsibility for applications located in cloud environments for which they are unprepared.
They will need to quickly get up to speed on the cloud environment and learn how to operate an application within it. This will include the need to retrofit monitoring, security and management into applications, as developers often fail to address these areas because they are not required for application functionality. We refer to this responsibility migration as the "cloud boomerang." You can see a video we created that describes this phenomenon in greater detail here.
Action: You should have your operations people evaluate how to take over operational responsibility for external cloud applications.
2. Compliance requirements will need to be analysed for these "discovered" applications.
Changes to the applications, or even migration from their initial cloud hosting locations, may be required to bring the applications into conformance with the requirements of governmental and industry laws and regulations. Given the significant semantic differences among IaaS public cloud provider functionality, this will be more challenging than item number one, above.
Action: You should set up a remediation team with skills in these different areas so that you are prepared to respond when an unknown application running on the public cloud surfaces.
3. Investment patterns of IT spend will be modified in a stealthy fashion
This change will happen not deliberately, but unconsciously. While public cloud computing is relatively inexpensive (the complaint of vendors as described in the second of O'Grady's posts), the costs mount up as applications scale and as applications multiply like rabbits (as they inevitably do, that was certainly the pattern with open source, as one project achieved success with open source components, other projects embraced the solution as well). At some point, someone will notice that a bunch of money is being spent on public cloud computing and figure out that it represents some significant fraction of total IT spend. At that point some will call for the cloud spend to be curtailed, while others will assess the benefits being achieved by those cloud applications and conclude that maybe the cost cuts should fall on the internal IT budget.
Action: You should have your finance people looking through expense reports and have others sniffing around to see what use of public cloud computing is being done in other parts of the organisation. Don't be the last to know.
And by the way, that shibboleth about "no one's going to run SAP up in the cloud"? In a somewhat ironic milestone his week, SAP announced that a portion of its on-demand offering has been migrated to AWS. Perhaps a new example of how public cloud computing isn't sufficient to meet the real needs of enterprises needs to be found.