The 7 Most Common Challenges to Cloud Computing Pt. III
With this post, I wrap up this three part series covering the findings of the GAO’s report on the overall progress of the Cloud First initiative. If you missed the first to parts, you can find them here and here respectively
Quick recap: Earlier this month the Government Accountability Office released the results of their study on the Office of Management and Budget’s (OMB) Cloud First policy. The GAO assessed the progress selected agencies made and identified challenges they are facing in implementing the policy.
• Ensuring data portability and interoperability: To preserve their ability to change vendors in the future, agencies may attempt to avoid platforms or technologies that "lock" customers into a particular product. For example, a Treasury official explained that it is challenging to separate from a vendor, in part due to a lack of visibility into the vendor's infrastructure and data.
Vendor lock-in is seen as one of the potential drawbacks of cloud computing. In order to avoid vendor lock-in, agencies should push for use case-based standards. That assertion is a two-part requirement. The first requirement is to standardize Use Cases while the second is interoperability and portability.
Standards Development Organizations (SDOs) exist to help consumers avoid vendor lock-in. One such SDO is NIST’s Business Use Case Working Group (BUCWG). The BUCWG helps interested agencies (and industry) define target Cloud Computing business use cases (set of candidate deployments to be used as examples) for Cloud Computing model options, to identify specific risks, concerns and constraints. BUCWG also coordinates with other NIST Cloud Computing working groups. Another group is the Standards Acceleration for the Jumpstart of the Adoption of Cloud Computing (SAJACC).
The goal of the SAJACC initiative is to drive the formation of high-quality cloud computing standards by providing actual examples showing how key use cases can be supported on cloud systems that implement a set of documented and public cloud system specifications. The group develops and maintains a set of cloud system use cases through an open and ongoing process engaging industry, other agencies, and academia. Simultaneously, the SAJACC initiative collects and generates cloud system specifications through a similarly open and ongoing process.
The initiative also develops tests that show the extent to which specific use cases can be supported by cloud systems and publishes test results on the SAJACC web portal. One such guidance was performed by the Virtual Machine Portability sub-group of SAJACC. The sub-group’s whitepaper describes the current technologies, formats and tools that support virtual machine (VM portability). It identifies challenges and opportunities for further improvements to interoperability and presents a high-level summary of key VM portability problems faced by cloud consumers today. Most, if not all, of the respondents to the GAO survey should review this resource because it addresses many of their interoperability and portability concerns.
IT vendor lock-in is as old as the IT industry itself. Some may even argue that lock-in is unavoidable when using any IT solution, regardless of whether we use it “on premise” or “as a service”. Define an exit strategy for each (vendor/CSP) first, per sound architectural principles. It is a good idea to have an exit strategy during the beginning stages; this also applies to traditional IT! With respect to vendor lock-in, it has been stated that critics hold Cloud to a (much) higher standard than current on-premises computing. My advice is to take the architectural best practices we have learned and leverage for the Cloud.
• Overcoming cultural barriers: Agency culture may act as an obstacle to implementing cloud solutions. For example, a Department of State official explained that public leaks of sensitive information have put the agency on a more risk-averse footing, which makes it more reluctant to migrate to a cloud solution.
Leaking of sensitive data to the public is a real cause for concern. While agency officials still want to maintain control, there is alternative perception that Cloud computing reduces control.
Cloud Computing should be seen for what it is, another form of outsourcing. In fact, Cloud service acquisition through FedRAMP is simply the newest form of government outsourcing. Agencies can use FedRAMP to outsource a portion of the security controls authorization process. One strategy for dealing with employee resistance is to organize workshops for the buyer organization’s managers and team leaders that provide them with “talking points” to use when discussing the outsourcing initiative with employees. Such workshops help managers and team leaders become comfortable with the facts, changes, and impact on their business units or teams so they could more effectively help alleviate employees’ concerns, such as sensitive data leaks.
• Procuring services on a consumption (on-demand) basis: Because of the on-demand, scalable nature of cloud services, it can be difficult to define specific quantities and costs. These uncertainties make contracting and budgeting difficult because of the fluctuating costs associated with scalable and incremental cloud service procurements. For example, HHS officials explained that it is difficult to budget for a service that could consume several months of budget in a few days of heavy use.
Studies of both commercial and government IT projects have found some disturbing statistics:
- Only 16% of IT projects are completed on time and on budget.
- 31% are cancelled before completion.
- The remaining 53% are late and over budget, with the typical cost growth exceeding the original budget more than 89%.
- Of the IT projects that are completed, the final product contains only 61% of the originally specified features.
- Must be derived from commercial best practices. There are proven methodologies and industry should provide leadership and guidance
- Must avoid MilSpec by leveraging existing investments and capabilities. Most IT acquisition in government is not MilSpec; it shouldn’t require such rigorous vetting
- Should favor standards of practices processes already proven in the market. Agencies have to stop buying yesterday’s technology tomorrow
- Should be based on open, consensus based methods. Government’s current procurement process is still too proprietary and closed
- Must be modular and services oriented. Design it to procure for services, not systems
- Should be measurable, repeatable and sustainable, with supporting training, education and mentoring. Approach it from a lifecycle perspective. It should not be just a one-time implementation, change in acquisitions should evolve.