Embracing Cloud: Common Cloud Misconceptions and Roadblocks



The reality is that for most of the ICT world, Cloud Computing is a new service. We see this in global trends with the United States only stepping into Cloud in a meaningful way this year, carefully, while other countries are still in the education and investigation cycle.

With all new technology comes misconceptions, concerns, fear, uncertainty, and doubt, which collectively can stall an enterprise thinking and cause roadblocks. Cloud is no exception to this, in fact, of all modern ICT technology it is probably the one that suffers the most from this effect.

In order to transition to Cloud, we must understand it and as practitioners be educated so we are ready to answer these concerns and manage real risk.

How to Manage Risk

Before we get into the concerns with Cloud computing it is worth noting how risk should be managed. There are three steps to this process with Cloud. Let’s use Security as an example:

  • Objectively review your own security today using a checklist. It is not uncommon to find that security infrastructure is ageing, that software is not entirely up to date, that the intrusion detection systems are only monitored nine to five, and that your ingress and egress points are visible to the public. Buy a penetration test if you can afford it. The point being that you need to understand, factually, what level your security is at today.
  • Next, apply the same test to your Cloud provider. Ask your Cloud provider to answer the checklist you created in the first step. Ask your Cloud provider to come and specifically present to you on their security measures. Ask them for a list of their other customers. This allows you to objectively match what you do today, with what the Cloud provider has available.
  • The last step is to write that up into an objective risk document. It should show your security level today and the associated risks versus the security level you will have if you take up the Cloud provider’s service. This then becomes the factual, objective, position that you can lean on whenever the security issue comes up.

The outcome you are looking for is a decision that is based on factual, objective, well-understood information as opposed to the opposite. You will hit this again and again through a transition project, so it is worth creating the templates and the process up front to deal with it.

The Technology is Unproven

This is an older concern that has persisted for the past two or three years. It says that the technology is new, bleeding edge, unproven, and as such, risky.

The reality is that the technology itself is quite old, the service delivery mechanism is new, and Cloud computing itself is quite mature. While the technology is going through a phase of extreme marketing, it’s been around in its current form since 2006[1] and as a concept since 1950.

The risk here is less about the technology itself and more about the management of it. Cloud computing demands a different approach to ICT Service Management and this needs to be managed as a risk in any transition project.

The Two Evil Stepsisters; Privacy & Security

This is probably the most widely held risk about Cloud services, along with Data Sovereignty. The risk is that by placing our data into the ubiquitous Cloud, it will be less secure and as a result you will be more likely to suffer a privacy breach.

Security and privacy are two separate things:

  • Privacy is a business (non-ICT) responsibility that is often placed onto the ICT organisation due to a lack of education. It is the responsibility of the business proper to categorise their data from business operations into levels of privacy. This should be a functional requirement for the build of all ICT services that handle data.
  • Security is the method by which both the business and ICT organisation protect privacy. We only care about ICT so we can say that security is the toolsets that ensure the privacy requirements, that the business have documented and agreed, can be safely met.

I would argue that security in the Cloud is likely, in most cases, to be better than what the enterprise does themselves today given the massive economy of scale that allows providers like Amazon to bring security and frameworks that are extremely strong. We know that the CIA for example trusts Amazon enough to have purchased $615 million USD of services from their Cloud.[2]

Further, the rise of encryption gateways, homomorphic encryption, and tokenization will further secure Cloud services to an almost impenetrable level.

Enterprises can have as much security as they can afford.

A word of caution, it is worth creating a security list as part of your Cloud risk and assurance process to ensure, objectively, that the Cloud service you are buying will meet your requirements. A sample check sheet is included in Appendix A.

Maturity of the Enterprise

This is a risk that is often missed and is critical to manage.

Cloud services are not just about compute power. The way they are delivered and managed is critical.

For example; if you choose to buy a SaaS product from the United Kingdom and you live in New Zealand then what happens when it fails? From the user picking up the phone to call the service desk through to the management of that event with the provider needs to be understood and process put in place to manage it.

Another example; how do you manage the performance of the Cloud service provider month on month from a contractual perspective against stated service levels?

Service Design is a key component of any transition to Cloud with legacy services.

It is not unusual to find enterprises that want to take up Cloud services but require transformational work in ICT Service Delivery before it is safe to do so.

As we work through the planning for transition of your legacy service, you will see the various elements that are important to be in place prior to deployment.

Loss of Control

More of a cultural reaction than an actual risk the older IT Department (vs the newer ICT Service Delivery Organisation) will raise this as a concern. This is far less to do with the Cloud service model and much more to do with letting the go of the reigns of the old “command and control” style of IT management.

The reality is that with careful planning and design, most organisations will find they have increased control.

Cloud services usually come with a slew of monitoring and management tools along with “single pane of glass” portal control. In addition, the provision and decommission of service is far more rapid than the traditional model. Contract terms, if there are any, are easier to manage. The “only pay when you use it” model allows for much better cost control and if necessary, internal enterprise billing.

Network Performance

This is a clear risk, particularly if you live in a country where bandwidth is low and latency high. In the United States and United Kingdom we know that the bandwidth is very high and cross-city, county, state, and country latency is low. The cost of the network is low.

However, in countries like New Zealand and Australia, due to poor, or slow, investment in ICT network infrastructure, bandwidth can be expensive, slow, and due to wide geographic distribution of the population, latency can be high.

When you are consuming services from a Cloud provider this is the one area that is worth carefully managing through investigation and design. The best Cloud service in the world could cripple your enterprise if it is slow, unresponsive, and unreliable.

In the case of legacy services, it is often better to find a Cloud provider close to you physically, if you suffer poor national infrastructure, then deploying dark fibre or other high-speed connections directly in a private Cloud model.

Vendor Lock In

This is a real risk that needs active management during the design stages, however, it is worth noting that vendor lock-in, in some cases, is an advantage.

The risk states that if you move your ICT services to Cloud then you will be at the whim of the provider that you choose. In some cases, which we will get to, this is true, however generally, this is not the case.

As the war by Cloud providers for the enterprise dollar has increased, they have become more open, more standardised, and more agnostic. With careful selection of your Cloud providers, you will be able to move workloads and data between them. In the future, we know that the large providers are likely to have a single Cloud market that allows you to move your workloads around the world to get the best price for your money that day.

There are Cloud providers that you will find yourself locked into. For example, Oracle provides one of the largest, proprietary, SaaS offerings on earth, as does SAP. For an organisation that has committed to and invested heavily in either of those technologies, there is still advantages to moving into that service.

Cloud Washing

Less of a risk today but still something to keep an eye on, Cloud washing is the re-selling of services that are not Cloud, under the Cloud marketing banner.

All Cloud services meet the characteristics described in earlier chapters. Where the Cloud provider does not meet those characteristics, the enterprise should be very wary. Utilising information such as the NIST definition of Cloud Computing and New Zealand’s offering to the Cloud world, the Cloud Computing Code of Practice, will help manage this risk.

Ultimately, as part of your planning, you will build a risk and assurance model that will help you select Cloud providers appropriate for your enterprise.

Cloud will fail

This is a valid risk. We have seen all the major global Cloud providers have an outage in the past months.

However, this is a risk that needs to be objectively measured, like security, against what service your ICT organisation delivers today.

While Amazon may have had an outage of minutes on its storage in the past five years (they guarantee 99.999999999 uptime with some services), how much time, including maintenance (which you will never see in a Cloud), has your enterprise suffered?

Data Sovereignty

Often confused with both privacy and security, data sovereignty is the risk associated of where your data is stored physically. Specifically, it is about which country (legal jurisdiction) your data is in.

This is ultimately, a question for the enterprise legal team and a decision that your executive should be making. Data sovereignty is far more about the law than the Cloud service itself. However, it is not always easy to get this risk right.

For example, in New Zealand, the Inland Revenue Department (tax), requires that all tax records be stored on shore. However, we have tens of thousands of New Zealand companies that use Xero, a New Zealand Cloud company that sells accounting software where all data is stored in the US.

If you examine the letter of the law. It says that you must be able to recreate your tax records in New Zealand. That means that as long as you keep all the paper, despite the fact I use an overseas Cloud provider, you am compliant.

Having a conversation with your legal department is the best approach to this risk.

Other Barriers to Adoption

Component Notes
Skill shortage Resource is scare and it will cost enterprise to buy it. This will be material not only in the investigation stage, but also in the subsequent stages. Project, programme, and transition managers with Cloud skills are few and far between.
Complexity The cloud service required may be overly complex. This is particularly true for legacy systems.
Vendor lock-in Vendors see the Cloud eating into their sales as the world moves from an infrastructure-centric investment pattern to a service based model. Vendors will seek to retain their customers with the legacy investment pattern by locking them into proprietary systems that are not heterogeneous thereby increasing the complexity of a Cloud solution while reducing the economic benefit.
Investment cycle If an enterprise has recently invested in infrastructure, legacy systems or outsourced services then the time to cycle to a new service, such as Cloud based, could be years.
Integration ICT systems in the enterprise are often tightly coupled with each other using a mixture of middleware and other transport tools. Integration is then a complex problem where one or more of those systems are moved out of their environment into Cloud.
Commercial agreements Enterprises may be bound by contracts or other commercial and legal agreements that forbid the uptake of Cloud services for a period of time.
Government policy Government policy may forbid the use of certain Cloud services.
These posts are taken from my book “Embracing Cloud: How to migrate your ICT Services into the Cloud.” The full book is available via Gumroad as a PDF or Amazon in Kindle Format.  The full list of posts is here.

[1] When Amazon launched EC2.

[2] At the time of writing this deal was subject to a lawsuit between IBM, Amazon, and the CIA.

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: