So there’s a train wreck coming. It will be another blow against Ops. It’s where the cloud self-service availability for Dev/Test train arrives at the traditional IT Ops station and its historical role of provisioning and configuring. And it’s IT Ops that will be most impacted: what does self-service on-demand cloud mean for the traditional command&control corporate IT structure?
What happens now that you can do formerly complex or difficult things, or things that required cooperation from the branch of IT controlling the hardware — things now replaced with spinning up what you need in the cloud immediately.
In other words, your wait time has become radically shorter because standing a server up is automated and easy to do right now, but your pre-existing policies for the provisioning and configuring still take a long time? What do you do when your policy has become a jokingly bad speed bump because the time it requires has become the heavyweight burden in the process? When it no longer enables but almost disables agility and responsiveness?
Welcome to a new Meta-world where global change has collided head on with local policies about changes. Where self-service instantiation has become on-demand easy, but governing existence of said instantiation throws a whole bunch of previously settled notions into question. It was one thing when standing up a set of servers took 6 weeks but now that it takes 6 minutes, there’s a problem with the old ruleset.
This self-service standing cloud in Dev — often without even worrying anymore about Ops, more than making sure whatever gets spun up looks like what production requires — is a part of the change that DevOps is bringing to making a business more agile. It should be not just a good thing but an awesome thing.
Is Ops ready for it? I don’t know, but I do know the literal provision and configure dominion once held by Ops is no longer competitively realistic. Those companies that do not adapt and evolve will join the ranks of those companies that insist on retaining use of typewriters.
Jason Bloomberg: If you look at cloud computing, we have automated providing and automated configuration and management that pushes the responsibility for operations to essentially the IT end user. Any developer, any techie can provision instances. That shifts the whole challenge from a technical challenge to now a governance challenge. What are the policies and processes for understanding how the organization wants to leverage cloud computing?
We saw the same thing with SOA. SOA governance became a key challenge. […So,] publishing all of these services, and now the services are available, they’re discoverable, and now anybody can come along and compose them and consume them to build anything. But without proper governance, it can just go off the rails.
So we have this automated approach for representing policies and enforcing policies in an automated way, and that enables us to achieve – to basically approach governance from a different approach – [a] different perspective.
So governance – that word governance, it sort of has some baggage, because it’s traditionally been something your compliance department handles and they think about making sure people follow rules and it becomes very sort of onerous and heavy-handed.
But we’re reinventing governance, because we’re automating the ability to create, communicate and enforce policies, and so we have this automated aspect of governance that is by no means all policies, but there’s a whole core set of policies that we can now deal with in an automated way.
So we represent policies in a metadata format. In the SOA world, it started off being, Web services-based, XML-formatted. In the cloud computing world, it’s increasingly JSON-based policies. But it doesn’t really matter.
What matters is that we have a standard way of representing a policy in a machine-readable way, and that brings the governance story up a level, so – where it’s not just about creating the policies, but now governance becomes a set of policies for how we deal with policies. That’s what we call meta policies, and we sort of raise the whole discussion up to this meta level, where it’s not about the policies, it’s about, ‘what are our policies for dealing with policies?’
And that becomes a new way of looking at governance, where it’s a more – essentially architected approach to governance. And that pattern repeats itself. It repeats itself with how we do development and it repeats itself, how we do operations. So it becomes the whole agile architecture story is based at that meta level.