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.
Sign up for MIS Asia eNewsletters.