The Cloud and Being Nimble

By Avi Deitcher

In our most recent article, we explored why "true cloud" really matters: it has a significant impact on:

  1. Your gross margins
  2. Your speed

As a company providing technology services, as opposed to products like software, you cannot get cloud-scale gross margins and speed - and therefore valuations - unless you are operating as a true cloud.

Today, we will look at a different set of advantages to running your service as a true cloud: how nimble you can be.

The Oxford Dictionary defines "nimble" as "Quick and light in movement or action; agile."

In business, being "nimble" means being ability to respond to events, which usually are one of three types following:

  • Issues: These are problems that arise with your offerings. They can be bugs, but just as easily be performance problems, security weaknesses, or anything else that evolves internally from your company.
  • Features: These are additional functionality that you need in order to remain competitive with existing customers, or to get new deals. It can be as simple as "we need a new colour scheme", or as complex as "we require a whole new set of compliance logging so our customers' auditors can review their activities."
  • Shifts: Shifts, or more correctly market shifts, are tectonic changes in the market that require not just new features but wholesale application of new or changed offerings or paradigms.

Whichever you are dealing with - issues, features or shifts - there is a clear scale in your company's ability to respond:

On-premise < hosted < true cloud

On-Premise

If your offerings are deployed on customer premises, your ability to deploy even small changes is constrained by each customer's willingness to deploy the changes. Here is a painful but unavoidable fact: once a customer has paid for your product, they will spend the absolute minimum necessary on infrastructure and labour to deploy and maintain it. Does this make it harder to upgrade? Sure. Do they care? Sure. Do they care enough to invest more in it? Very very rarely.

While on-premise deployment was the fastest and cheapest way to get a customer, it also locked you into the least nimble way to keep a customer.

Additionally, when deployed on-premise, customer perception of your services will be locked into your product when it was deployed. To illustrate this element, let's imagine a conversation between the VP Sales and VP IT of your potential customer (yes, I have partaken in conversations just like this one):

Sales: I really like these new offerings from Company X; they really seem to be able to solve our sales lead management issue.

IT: Looks great, and the design you showed me from their collateral is pretty advanced thinking. Let me ask our Senior Engineer about our history with their product.

Senior Engineer: X?? Remember their previous product, the one we installed 3 years ago? It was a nightmare to install, took 6 weeks longer than estimated, and has sucked up untold hours in maintenance because they clearly cut too many corners in designing it! 

Sales: You know, I remember that, and features took forever to deploy. But they say they have changed!

IT: And sales never whitewashes anything to get the deal done, right?

Sales: (laughing) Good point! OK, let me see if I can find a younger and more nimble company with a similar offering.

... and there went your deal. While you did have to cut corners to get that first product in, and you have improved dramatically since then, it is extremely hard to change the customer's perception of you once you are in-house. The fact that the it was customer's IT that could never find time to deploy your great new versions, and so impress their people, matters not a whit.

Hosted

The one advantage of hosted over on-premise is that you have a greater level of control over deployments. While a customer will never find the time to deploy a great new version to impress their business customers - why should they invest $50,000 in their IT staff time to improve your reputation? - if your team is doing the deployment, you can determine if the reputation improvement is worth that $50,000 and allocate the staff.

In a hosted environment, your incentives are better aligned.

In fact, because this is your product which you know so well, the cost of deployment is probably 10-20% cheaper than it would cost the customer, who has a learning curve with each deployment, and may lack expertise in certain component areas.

Actually, with hosted, the customer's IT never had to wrangle with deployment. All of the headaches - and reputation hits - that go with learning and then deploying a new product simply never occur.

With greater control over the environment, you have more ability to control your reputation, deploy features, or even deploy entirely new versions.

So what is the problem with hosted?

Proliferation.

While not as bad as nukes in the hands of rogue states, proliferation is still a major issue. If each customer has its own installed base, inevitably, two bad effects will occur:

  1. Variation: Each customer will vary, even just slightly, in their deployment. Perhaps at the time of customer A we were short quad-core servers and used a dual-core, since, after all, "it will be 12 months before they get anywhere near capacity." Maybe the Oracle license discussions were bogged down so we used Postgres, "just for a few months." Maybe the dedicated T1 into our East Coast data centre was available today, but the backup into our West Coast data centre won't be for another quarter. Either way, each customer will vary from the next.
  2. Versions: In September 2013, version 2013.8765 of your product was the latest, so you installed it for Customer A. In January 2014, version 2014.0016 was the latest, so you installed it for Customer Q. Of course, you really want to go back and update Customer A to the latest version, but Customer R is coming on board imminently, and we have that database issue with Customer C, and... There always is more work to do than people to do it, and less pressing issues (like upgrading Customer L two minor versions) fall by the wayside.

Sure, when you started, you said each customer would be their own installation, but they would be identical except for scale (number of instances or storage capacity) and data. Over time, however, these variations and versions grow, until each customer is not a unique mirror of every other customer, except for the data; each customer is its own completely unique install base!

A different type of variation is the sales pressure. Your company really needs that last $100,000 deal to close the quarter. The customer, however, wants one last $3,000 discount. If you do it, you kill your margins. So you remove one piece of redundancy just from this customer, just for the next 6 months. 3 years later, the piece is still missing, the customer has suffered during an unplanned event, and you are left holding the bag. Go tell the customer you cut corners.

The hosted model creates temptation to customize the deal for each customer, which in turn creates an operational and cost downward spiral.

While the hosted model is much more flexible than the on-premise model, you are still constrained by a legacy that continues to grow.

True Cloud

True cloud liberates by constraining. Since, by design, you cannot create a unique service for each customer, you are forced to create a system that consistently gives the best experience for the lowest cost to every customer.

  • Versions: With a single version deployed at all times, all customers always have the latest version.
  • Variation: Since customers never have their own servers, firewalls, storage, database, caches, load balancers, or even software, it is impossible for there to be any variant between customers except for the data itself. Essentially, you create a fence around the data and say, "everything in here is unique and yours, everything outside it is uniform."

Let's revisit that sales pressure example. No matter how much you may want to, there simply is no way to cut corners by eliminating the redundant component. After all, all customers have all components! Actually, it is bare minimum extra cost for you to put this new customer on full redundancy, since it happens automatically and its cost is amortized over all of your customers.

Being in a unified, true-cloud environment causes everything you do, every advance you make, to be applied to all customers all of the time.

To be clear, true cloud does not mean that you only have a single offering. Salesforce has multiple levels of product and plenty of add-ons (or apps). Amazon Web Services has many tiers of server in EC2 and different types of data storage solutions. True cloud does mean that any solution is offered equally to all customers and is never deployed on a unique basis to just one customer.

Ah, you will ask, but does that not dramatically increase my risk? With the hosted model, if I updated customer R to version 2014.0167 which had a hidden bug, only customer R was affected; I could catch it there and fix it before affecting all of my other customers!

Yes, you are right. It does increase your risk... which is why classic technology quality control paradigms simply do not work in the cloud! Moving to the cloud requires completely different paradigms that manage the risk much better.

Summary

Hosted solutions cost more but provide more flexibility to respond to internal, customer or market events. Nonetheless, they create issues of variations and versions, including sales pressure to customize, leading to ever more variations. Incentives are better aligned, but not great.

True cloud creates the highest level of nimbleness by creating constraints on customer variations, but requires entirely new methods and organization of architecture, engineering, quality control, product management and finance, as well as metrics for the above.

If you are just deploying your own software into the cloud as is, you are increasing your risks without getting the benefits. We can help you get there.