When Too Much Control Is a Bad Thing

I know, more control is an axiom! But the above statement is more often true. When we're talking about configuration control in the public cloud it can be especially true, as control over the configuration of your application can put control in the hands of someone who knows less about the given platform and thus is more likely to get the configuration wrong. Have I fired you up yet? Then you're going to love (or loathe) my latest report, published today. 

Let's look at the facts. Your base configuration of an application deployed to the cloud is likely a single VM in a single availability zone without load balancing, redundancy, DR, or a performance guarantee. That's why you demand configuration control so you can address these shortcomings. But how well do you know the cloud platform you are using? Is it better to use their autoscaling service (if they have one) or to bring your own virtual load balancers? How many instances of your VM, in which zones, is best for availability? Would it be better to configure your own database cluster or use their database as a service solution? One answer probably isn't correct — mirroring the configuration of the application as deployed in your corporate virtualization environment. Starting to see my point?

Fact is, more configuration control may just be a bad thing.

Another scenario: You wrote a Javascript-based application on CloudBees. You know what kind of availability and performance you want but haven't a clue how this cloud service runs its infrastructure and they really don't give you very many options. This latter situation might just be your best deployment yet. Because it's job one of the IT operations team at CloudBees to ensure the performance and availability of its environment — and thus your application. And they know best how to get the most from their platform. Second guessing them probably won't buy you much, other than headache and confusion, as this cloud doesn't behave the way your data center does.

So before you conclude, as many before you have, that more control and more configuration options must be better, think again. In my latest report, "Which Public Cloud Platforms Offer The Right Configuration Controls?" we leverage the research conducted for our "Forrester Wave™: Public Cloud Platforms,"added a number of public clouds to the analysis, and concluded with some valuable data to help you determine what level of configuration controls and options each of the major cloud platforms provides. We then balanced this information with analysis to help you determine when and where you need the most control and who needs it

Bottom line: Give control to those who can wield it effectively (those who have the experience on the given cloud). Don't seek it out when doing so can lead to configuration errors. 

You might read my examples above and draw a quick conclusion that Infrastructure as a Service is where you should seek the most control and in Platform as a Service you should trust the cloud provider, but the answer isn't that black and white — nor is the line between IaaS and PaaS. Within the leading IaaS platforms you will find PaaS solutions and PaaS-like services that limit your configuration control — and that's a good thing. These days, PaaS vendors are giving more configuration transparency and control to address the desire (and not always the need) of enterprise clients. These controls often tie right down to the IaaS underneath, while others give IaaS like controls while maintaining the middleware-level abstraction you would expect. 

Control is also something that can hurt productivity. If you are a Java coder and on deadline to get a new service to market, do you really want to slow down the deployment cycle so you can learn about a vendor's configuration control options? I thought the value of the cloud was its agility?

Access this report today

Comments

Great report! A bit too much

Great report! A bit too much focus on what is to be developed and not enough on who is going to develop it. Additional thoughts here http://t.co/6E1qyiWYFX Last year there was a good piece on the various developer types, which should be overlayed

Post new comment

If you have an account on Forrester.com, please login.

Or complete the information below to post a comment.

(Your name will appear next to your comment.)
(We will not display your email.)
Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.