Phil Symons MBCS discusses the more subtle trade-offs that typically crop up when an organisation decides to go down the cloud route.

Working out where to go with technology is a negotiation with the future. At the beginning, fine words. A wonderful relationship is foreseen. Of course it is - there are no facts on the ground to interfere with the dream.

Once you have a conflict between differing views of what should be done, you’re making progress. Extending the fight metaphor, the result will usually be a win on points. In the absence of ‘knockout’ benefits or drawbacks, you’ll be scoring a set of trade-offs. The benefits of moving an activity to the cloud are measured against the demands of using it.

Getting the argument started

Your organisation has (unknown) potential for benefiting from cloud technology. Where to begin? At its simplest, you have a set of cloud service providers, and a list of the services they offer.

On the other side, there’s a list of things your company or non-profit organisation does, or wants to do.

Taking Amazon as an example, you have the following headings for the services they offer:

  • Compute
  • Storage and content delivery
  • Database
  • Networking
  • Analytics
  • Enterprise applications
  • Mobile services
  • Internet of things
  • Developer tools
  • Management tools
  • Security and identity
  • Application services

Under each heading are the actual services offered. Your list of current activities (represented by systems) could include:

  • Customer-facing software
  • Email
  • Your application development environment
  • Your test environment
  • Backup
  • New initiatives.

Going through the list of cloud services and writing up a potted explanation of each could be a good way to start the thought process. The question is: Which services would match which activities?

Even the above list runs to 60 combinations at header level, so there are probably thousands of combinations of service and activity, many of which are nonsensical. Having eliminated those as well as other ‘no-hopers’, you have the basis for a conversation. As stated above, there may be ‘knockout’ advantages or objections which pull the discussion in certain directions. There will also be more subtle trade-offs that typically crop up.

Abstraction versus control:

Delivery of services in the cloud is the culmination of an abstraction process that shifted processing from named physical machines (‘servers as pets’), to virtual machines on hardware that you own (‘servers as cattle’). Now the cloud offers IaaS (infrastructure as a service) where virtual machines reside in a huge data centre (‘servers as battery hens’). By this stage the virtual server is completely disposable. We can even abstract away the hardware altogether, with PaaS (platform as a service) or SaaS (software as a service) which don’t expose the operating system at all.

The advantages have been well-discussed. There is still a trade-off to consider: Do we need any of the control that the abstraction simplifies away?

Incidentally, there’s a lower boundary to hardware abstraction as well as an upper one, and it’s not a matter of choice. In modern multi-core systems, a layer of abstraction built into the hardware makes it impossible to predict exactly how the code will execute.

Efficiency versus effectiveness:

An old theme going back to Peter Drucker at least. This principle hasn’t been updated by technology. You’ll most likely be thinking about this at the technical level. Cloud services are at the end of a wire. The network latency for data transfer may mean that raw performance doesn’t match a well-designed on-premises system.

So, to be effective, do we really need the performance that an on-premises system offers?

A cloud offering might be particularly easy to implement and manage, but more expensive (less ‘financially efficient’). Here, you’ll need to consider whether early and easy adoption is worth the extra cost.

Delegation versus control:

Similar trade-offs crop up whether you’re thinking about cloud services or out-sourcing the tea and coffee.

Financial:

Being able to ‘light up’ extra machines and then turn them off again means you can match your spending to the peaks and troughs in your activity, and to the general growth trend. Some of the new pricing models super-charge this effect by offering free cloud services until a minimum usage level is reached. So you can experiment, knowing that there’s zero overhead until you’ve established something worthwhile.

There’s a trade-off to consider where services are not offered free for low usage. Take a cloud-based development or test environment, for example. For the first time your developers will now spend real money each day on cloud services. This may be negligible compared to your savings in capital expenditure and maintenance costs, but are you going to control it and how? Will you put in a ‘light touch’ policy and trade off the extra cost against the benefits to employee morale?

Robustness:

Can your developers write code of the same quality as Google, Microsoft or Amazon? Unlikely - and their huge population of users are ‘testing’ it every day with a rigour you can’t match. Where’s the trade-off? Well, whatever the advantages of the cloud companies, they do release bugs from time to time.

If you retain control of your code you can hold back a release when it’s a sensitive time. Where reliability is absolutely critical, you do have the option of deployment to two clouds, but otherwise you’re faced with a trade-off: Does the general reliability compensate for losing control of the software and its release cycle?

Skunk Works versus feral prototype:

Getting started is an excellent way for your organisation to learn. You’ll be watching the skunk works in case you need to strangle the prototype before it gets loose in production. Perhaps it can be deployed once the design assumptions in the prototype are checked against the wider needs of the organisation. So - how much technical debt can you tolerate for the benefit of an early deployment?

Realising the benefits

There are other trade-offs that may come to light, but no doubt it’s important not to over-think it. You’re not likely to be making a ‘cloud or no cloud’ decision, and currently the cloud suppliers are making it easy to get on board at minimum expense. To fully realise the benefits though, and avoid some of the pitfalls, you do need to manage how and where you implement cloud services in your organisation. The management begins with getting the discussion going.

Read more about Cloud and data management in the latest chapter of Digital Leaders, available in MyBCS,login required.