What You Don’t Want — the Cloud and Cost to Deliver

Providing cloud computing at scale is about economics. The delivered services have a narrow range of margin over the first 2-3 years, as to be expected when you outlay some cash for infrastructure, design, implementation etc. Hopefully after year 2 you achieve positive margin and start to pay yourself back. This works well in an environment that meets the Cloud’s perceived “80/20” rule where your meeting 80% of the needs of 80% of the customers out there. The economics and time to market should help offset the 20% of remaining need, and customers can shop elsewhere for the 20% “doesn’t fit here” remainder.

With that said, how does one manage the cloud delivery process? In many hosting situations, hosting companies have done customized negotiations for clients, one-offs, and custom designs depending on how large the opportunity is. Many hosting companies are getting into the cloud game, e.g. AT&T, Telstra, and Terremark. How does one balance custom requirements with the cloud? When does it make sense to deviate from the 80/20 rule? Or when does it make sense to sell 10-20% of your capacity to one customer or workload?

This can be a difficult decision. There are many factors. It plays to standardization and service management. It requires careful analysis on who else might want that feature and when.

I theorize that a significant change to the “cloud” services to provide a specific new feature for a customer or two will likely result in changing the cost of service for the entire platform in a bad way. The deviations need to be managed and well thought-out.

There will be an effect on cost to deliver — can your pricing sustain that? Can you pass on that cost to the new customer and not effect overall delivery margin? Maybe the addition of this new feature or platform will help drive adoption of your cloud, in which case that may certainly offset the overall change in cost. Can you do it without adding additional complexity? The “zen of cloud” would almost state that you must.

Hopefully some of the questions work out! It will hopefully avoid this…


What’s an example of a significant change — let’s say your definition of SMALL LARGE compute service doesn’t fit with a customer’s definition. They want something that is medium plus more memory. That’s ok, but if you spec’d your PODs (point of delivery) with re-stacking workloads in mind (and you should) you now may find yourself with spare capacity on a node that you might not be able to utilize.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: