Why design-time service governance makes less sense in the cloud

Designing policies makes sense, but there are key reasons while traditional service governance doesn't fit the cloud environment

I seem to have struck a nerve with my post "Cloud computing will kill these 3 technologies," including my assertion that that design-time service governance would fall by the wayside when considering the larger cloud computing picture. Although this is unwelcome news for some, the end result will still be the same and a prediction I stand by.

[ Get the no-nonsense explanations and advice you need to take real advantage of cloud computing in InfoWorld editors' 21-page Cloud Computing Deep Dive PDF special report. | Stay up on the cloud with InfoWorld's Cloud Computing Report newsletter. ]

My good friend Joe McKendrick pointed out the issue of design-time governance, and I thought the most supportive argument was made by Phil Wainewright, the SaaS and cloud computing blogger at ZDNet:

However I think Dave Linthicum's point was subtler than this. He was saying that, if you don't know where, how or by whom your services are going to be consumed until you've deployed them, then you can't possibly design the governance you'll need in advance. It's only once the service starts running that your monitoring and governance becomes meaningful, as an iterative process that responds to actual, changing usage.

Todd Biske provided commentary as well, largely supporting the use of design-time service governance, or at least the design part:

The real problem with Dave's statement is the notion that design-time governance is only concerned with service design and development. That's simply not true. In my book, I deliberately avoided this term, and instead opted for three timeframes of governance: pre-project, project, and run-time. There's a lot more that goes on before run-time than design, and these activities still need to be governed. It is true that if you're leveraging an external provider, you don't have any need to govern the development practices.

And yesterday Joe thought he'd put a bow on this issue of design-time governance in the cloud:

Okay, the core point of the post calling for the end of design-time service governance was around the fact that many services, specifically those that are part of an SOA using cloud computing, will have much of the policies altered after deployment. More to the point, they are mixed and matched from existing services with the use of cloud computing, thus they need to be operationally monitored and controlled, and the design of that control becomes much less critical. This trend is picking up a lot of steam in 2010, and includes Phil's point that "you can't possibly design the service governance you'll need in advance.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform