There’s no doubt about it: cloud computing is a leveller, both outside organisations and in. But do we really want a free-for-all democracy in which anyone can procure anything at will? And if not, how do we stop it?
Back in the day, the operations staff held the keys to the kingdom. They got to decide who got what hardware, and could dish out software licenses as they saw fit. They could make you wait months for an extra few Gb of storage, if they so wished.
These days, things are more egalitarian. Thanks to the cloud, business managers can stand up new computing instances for their collaboration software on your systems if they want. Oh? They can’t? Then off they jolly well go, to expense some dodgy -looking web app on their credit card. It’s the shadow IT effect, and it’s real.
Some may long for the good old days, when a server was always made of tin, and requisition forms had to be signed in blood. Most of us don’t want to go back there entirely, but it would be nice to keep some of those old disciplines; the ones that prevented server sprawl, stopped lazy code at the door, and made the IT department feel just a little bit in control. Discipline in cloud-based resource procurement breaks down into three broad areas:
- Making sure your users aren’t buying the wrong stuff
- Making sure that you’re buying the right stuff
- Giving people what they need in a controlled way (which may not mean giving them what they want).
What these users need is a damned good listening to
Let’s take these in order. One of the first things to do is tighten control on the users. By all means empower them, but define some boundaries. Just like teenagers, really.
“The development of shadow IT has grown more out of necessity than anything else, as increasing the tech savvy employees seek to introduce their own solutions to specific line of business problems,” warned Alex Hilton, CEO of the Cloud Information Forum.
“Discovering and understanding some of the unmet employee needs can help to reduce the risks associated with unsanctioned filesharing,” he said.
IT guys: that means talking to your users, or getting someone else more tolerant to do it, so that the IT department can understand why they are fleeing to third parties, and then give them something better.
Greasing the procurement wheel
Updating the procurement process is crucial here, explained Lee Newcombe, senior manager in KPMG’s cybersecurity practice. In the past, procurement teams would thrash out a set of requirements and make major systems integrators or vendors bid for them. There may even have been competitive dialogue in which the bidders would help to refine the requirements. In a cloud-based world, that’s changing.
Procurement departments must change too. If they still require triplicate blood-stained requisition forms, then all the charm offensives in the world won’t help. So educate procurement pros on how buy common services off the shelf rather than embroiling themselves in RFPs just for the sake of it. “If the central processes are slicker, there’s less of a reason to avoid them,” Newcombe said.
Buying cloud-based services to offer up in some kind of internal app store for users is no longer about fastidiously describing the requirements for every single system you buy.
“It’s now a case of defining your requirements and then identifying the best fit available to you from the relevant cloud providers,” said Newcombe. “It may be that there isn’t a perfect fit. It’s down to you, your product owners and your procurement teams to know which of your requirements are flexible.”
There are still procurement rules when buying cloud-based services, but they’re more to do with defining and supporting common standards, said Jon Creese, president of the British Computer Society.
“The role of CIOs and IT departments is to create a new architecture for IT provision which allows diversity and devolution, but which also creates discipline and control over the things that matter,” he said.
They must create standard requirements that can be applied across all of these purchases, greasing the wheels while still making sure that cloud-based services stick to some strategic goals. You’re looking at common standards applied to cross-company IT concepts like unified communications, data handling and security, and identity management, Creese said.
These rules apply to purchases at all layers of the cloud stack, from IaaS through to PaaS and finally SaaS. Once you’ve built your hybrid cloud empire, you have to manage the usage of that internal resource, too. That’s just as much of a challenge as stopping Bob in accounts from storing your CEO’s pay schedule in Evernote.
"Infrastructure as code" is a core part of the DevOps story, that’s meant to see internal IT staff provisioning their own code, mostly via software APIs. In a DevOps world, developers are encouraged - nay, mandated - to spin up their own machines.
It’s a lovely idea, but only if you have guidelines in place to stop devs littering your infrastructure with zombie VMs and chewing their way through your storage capacity with poorly-thought-out API calls. “Organisations would be well advised to design the DevOps journey from the outset, defining what needs to be controlled in terms of methodology for design, development and testing, and where more flex is appropriate,” said Creese. “This includes having some form of overall design authority to ensure that discipline exists.”
Those guidelines include a workflow for freeing up resources when they’re done with, as a basic rule, but they go beyond merely using resources conservatively, warns Newcombe. Hybrid cloud customers have to be clear what applications and data go into different cloud services.
”If you’re an Amazon Web Services house, you don’t necessarily want your developers spinning up services on the competing Microsoft Azure just because they have a preference for, or more experience with, that particular technology stack or service,” he said.
Companies embracing the cloud – whether on their own premises, or in public domains, or both – need discipline for all users, from the internal devs through to the end users. We needn’t go back to the dark ages, but let’s be realistic. After all, the cloud is built to be flexible, not completely free.