Every technology success story is also a story of unintended consequences. Take virtualization, for instance. Virtualization gave us unprecedented utilization of hardware resources. It transformed a provisioning process that used to take months into one that now takes minutes. It gave us flexibility and speed that was once unimaginable and formed the core foundation of the public cloud and private cloud platforms so prevalent today.
However, with that speed and access to public clouds came the ability to circumvent established processes, also known as “shadow IT.” Today line-of-business teams simply swipe credit cards on public cloud providers to get the self-service, on-demand provisioning they can’t get from their internal IT departments.
Cloud anarchy is shadow IT’s better-behaved cousin. You’ll find it in IT shops that centralize cloud accounts that get passed around among different line-of-business teams, so that at least the accounting funnels through one place in the IT bureaucracy. In truth, IT typically doesn’t have much control over who is deploying what or where. Instead of per-team or per-individual usage line items, IT only sees the final bill.
Among the strengths of a cloud management platform is that it can apply the governance IT needs without sacrificing the flexibility and speed the business demands. Line-of-business teams get that highly prized self-service, on-demand provisioning, and IT can anoint specific applications -- like those passing security audits -- and dictate who is allowed to access the applications and from where. Add metering and billing to keep track of who is spending what, and IT gets accountability without hampering line-of-business agility.
What does such governance look like? Here are five ways to implement governance of public cloud usage that successfully avoids cloud anarchy:
Step 1: Don’t reinvent the authentication/authorization wheel
Any new governance IT introduces must have less friction associated with using it than with circumventing it. Shadow IT will continue to persist if it is more painful to use an internal IT system to provision cloud workloads than it is to swipe a credit card on a public cloud. This is why it is important for your chosen cloud management platform to integrate with existing single sign-on solutions: so users do not have to remember new logins. Ideally, you can also use existing group definitions from your directory server. If administrators have to create these fundamental pieces in two places, the war has already been lost.
Step 2: Group clouds into an abstraction
In addition to lumping users into groups, an IT department should use its cloud management platform to place cloud regions into groups. This makes it easier to apply access control lists to logical segments of clouds. Such an abstraction should include cloud account-level separation. For example, perhaps you want two different constituents to use Amazon Web Services, but one group uses an account tied to a central IT billing credit card while the other uses an account tied to a line-of-business credit card. That level of cardinality brings maximum flexibility when designing the various groups of cloud that different constituents will be granted access to use.
Step 3: Create a service catalog of blessed applications
To accommodate all technical levels, you’ll want to provide an easy-to-use, familiar interface -- like ServiceNow or Cisco Prime Services Catalog -- that offers workflow approval tooling as part of the deployment process. Interfaces like this enable an administrator to grant or deny access to individual applications for deployment and ensure that a management approval process is followed prior to resources being provisioned on cloud infrastructures.
Step 4: Assign access based on role
Generally speaking, development and test workloads are best steered toward public clouds because the variability of the load they generate is a good match for the elasticity public clouds provide. Operations staff will need access to both public and private cloud platforms so that they can make intelligent decisions that involve considerations such as data gravity, data security, and private cloud capacity before making a definitive decision. Nontechnical line-of-business users, on the other hand, will only need to deploy specific applications on a more restrictive set of infrastructures and only through the service catalog. IT teams can customize and quickly change access if they've taken the steps to set up the authentications, authorizations, abstractions, and service catalogs described previously.
Step 5: Track usage with metering and billing
There is a balance to be struck between tracking spend on cloud accounts and creating a different cloud account for every individual user. Cloud management platforms often provide a mechanism for system administrators to track application deployments on an individual or group basis with internal metering that then maps to a single cloud account. Metering enables central IT to minimize cloud account administration, providing granular account usage reconciliation that optionally gets integrated into part of a larger internal chargeback mechanism.
Line-of-business teams in years past never had choices for provisioning resources like they do today. Now that the genie is out of the bottle, there’s no getting him back in. Line-of-business teams demand self-service, on-demand provisioning. If they can’t get it from their IT teams, they will get it themselves, creating shadow IT in the process.
Simply reining in cloud access is not the answer. Cloud anarchy, which features central billing of otherwise unorganized access to clouds, is not much better. Instead, a governance solution can provide self-service, on-demand provisioning in an organized manner that also offers granular metering and billing. Everybody wins when you implement governance that includes authentications/authorizations, cloud abstractions, service catalogs, role-based access assignments, and cost tracking.
Pete Johnson is senior director of product evangelism at CliQr.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.