I might be risking any credibility I have created in the technical community by saying this, but: Cloud computing might not be for you. Now, before you gnash your teeth and tear your hair out, bear with me.
Cloud computing / The Cloud / Cloud has been oft-touted as a massive advance both technologically and as a solution for those without access to serious hardware grunt.
The concept of cloud computing or at least the commoditization of run time has been discussed in the real world since the middle of the last century, and in science fiction for even longer than that. John McCarthy suggested in the 60s that in the future we might view computational power in the same way we do with our public utilities now.
It’s an idea that continues to find favor – Union Square Ventures’ Albert Wenger wrote about our proximity to that point only recently. It’s only really since the 1990s that availability and distribution of sufficient bandwidth has allowed us to approach that point, however. After that point, grid computing became practically possible, and single entities suddenly had the ability to summon and utilise an array of hardware as a service.
In the early 00s, Amazon launched its AWS platform, and we created a new lexicon of terms – SaaS, IaaS, elastic beanstalk, mechanical turk. From that point, any business no matter the size had access to the Cloud, and everything was rainbows and glitter.
Except not quite.
To understand why not, we have to push past the jargon to the nub of what cloud computing actually is. So, stripping away the terminology and glamour, what do we find? Server farms. Huge edifices stacked to the rafters with blinking, humming racks.
If you’ve ever been to a colocation space or if your business has a “server room” it’d be familiar to you, even if the scale was different. If you haven’t, then try to imagine a warehouse filled with cupboards stacked full of screenless laptops and you wouldn’t be far wrong.
It may be a little disappointing to learn that cloud computing is little more than a MacBook in a Billy bookcase, so why is it such a hot subject? The clever bit isn’t the hardware, it’s the way it’s used.
Cloud services use virtualization. Simulated computers within computers. Services can be deployed on demand, virtual dedicated machines spun up as and when they’re needed. You don’t have to pay for anything you don’t use, your cloud infrastructure can be as flexible as your demand for it is. This is the core of the appeal – an on-demand service deployed and costed according to need. If it had been able to see the future, Amazon might have gone with “Uber for server instances”.
That all sounds great – commoditisation of resource, lower expenditure on infrastructure, distributed risk – why then did I lead with something so patently nonsensical? Simply because there are risks inherent in any network design, and outsourcing and virtualising some of your infrastructure is not free from danger.
Further, there are some applications for which cloud isn’t (and possibly never will be) suitable. The following discussion of cloud downsides is listicle-style, so if you like, imagine it’s prefaced by a linkbait title like “This Business Virtualized Its Network Storage, And You Won’t Believe What Happened Next!”
Choosing to use cloud facilities means making a choice about where you’re physically placing a part of your network. Considering using AWS’s Virginia Elastic Compute Cloud datacenter? Well, I hope the weather stays nice. Ok, that’s a rare and extreme example, but it goes to show that geography must be a consideration. If you wouldn’t build a datacenter there yourself, why would you buy cloud services there?
Beyond that, there are other considerations to physically locating infrastructure remotely. Light and electrons in a copper wire only move so quickly. Why is that relevant? Well, by using cloud services on another continent, you introduce latency. In applications where response time and speed of individual packets is key, making them traverse the Atlantic just isn’t going to work.
High Frequency Trading for example would be a lot riskier. Even in situations where it’s less obvious, delay introduced because your database is distant can make your site or application seem slow, choked or buggy. If your customers are globally distributed, this might not be a huge issue. Where they’re located local to your site, but halfway round the globe from your IaaS supplier, it can be.
Do you have redundancy factored in? Have you considered the routes between your network and the remote site? What about the routes back? Are there issues with upstream peers? I hope you’ve considered how high-profile events will affect the service (football, other football, tennis, Olympics etc.) and I hope no-one bodges a DNS update.
AWS isn’t alone, Google, Apple and so on have all experienced connectivity issues with their cloud sites. What happens to your productivity if access to (say) your customer information database drops – the rest of the business is still viable, but will it grind to a halt?
It’s worth noting that cloud providers are now moving to a model where they offer “direct connect” services that bypass the internet, to improve compute performance.
3. Service and support
An elementary caveat is that the service you’re buying isn’t necessarily a direct replacement for one you’d build yourself. Some cloud services are more suited to particular tasks, some to particular technologies and protocols. The same can be said of providers.
It’s important to remember that when you outsource part of your network, not only will it mean that you’re relying on third-party support with any technical issues, but also that means that the services you offer your customers are now dependent on them too. This is an adjunct to the connectivity issue, but distinct from it.
Can you offer an SLA if you can’t guarantee resolution times? What sort of insurance do you have (possibly literally) if there are complaints and compensation claims from your customers? No matter how good your reputation, quality of support and the skill of your agents, they’re now being fed from a third party.
Also, there is a tendency to assume that if you’re substituting a local function for a remote one, then the tasks associated with that function are similarly parallel. Again those are being conducted by your providers, so you will need to investigate things the times / frequency / rollover of backups, what logs are available and so on.
As with almost any other kind of commercial service, the contract that exists between yourself and your cloud host lays out the rights and responsibilities of both parties. When you buy into that service it’s important to bear in mind where the control of it lies, and what modifications can be made to it.
If you’re tying your infrastructure into a system for a given length of time, you should ensure that that system will remain as you expect it to for the length of that contract.
5. Security and privacy
It’s a concern that I suspect has come more to the fore in recent months, but as with any other kind of outsourcing, you are handing over your data and the handling of it to your provider. It should go without saying that the more parties that handle your data, the more opportunity there is for it to be disclosed (either accidentally, or through a request from a government agency) or misused.
For all the time and money you invest in securing your own network, if your cloud provider is more lax, commercially sensitive information could be leaked.
In the early days of cloud computing, there were a lot of concerns about the storage of multiple customers’ information on the same device – whether some kind of escalation in privilege could give one access to another’s files. These fears seem to have been unfounded however, as there haven’t been any reported major breaches of this type.
Something else to consider is the reputation of the platform you’re on, or rather the reputation of the other users of that platform. If a given range of IP addresses is quickly known for poor behaviour (spamming etc.), what impact will that have on your own ability to be trusted by other networks? The ‘direct connect’ model mentioned above can also help with security.
6. Flexibility and cost
Seen as two key differentiating advantages of using cloud facilities, flexibility and cost can still trip up the unwary. We talk about scaling business, and Cloud’s ability to scale with it, but with performance, costs similarly scale. Indeed, several suppliers use a “stepped” approach. Whilst initially cheap, the more instances (or more resource-intensive instances) that are spawned, the more those individual instances can cost.
What about the nature of the traffic that is sent to the provider – how does it handle bursting? Or lulls? Upon whom is the impetus to create the instances? What provisos are in place around bandwidth?
Having a service that is handling a small amount of traffic one day, then following an advertising push sees a dramatic uptick in use can easily alter the requirements of that service in the short term – if instances are spawned automatically to handle inbound requests, costs can rapidly spiral.
Further, what about if that traffic isn’t “genuine”? Should your facility be the target of a denial-of-service attack, who then would bear the brunt of the impact? In the event that your cloud space is suddenly flooded, what happens? Will the service be suspended to limit the impact (which would hit genuine customers), or will you face a hefty bill for bandwidth at the end of the month?
7. Environmental impact
This needs to be mentioned. It should be a consideration, even though establishing the “right” way to go is going to be hard for any business. Cloud sites, with their masses of servers and cooling requirements will need power. That has to have an impact on the environment (no matter how “green” or efficient the credentials of the supplier).
The decision you’d have to make as a socially responsible consumer of that service is whether you can take ownership of a share of the provider’s environmental impact, or whether hosting a low-power device locally is a better choice for the planet.
Cloud computing arrived as the Next Big Thing in a fanfare of cheap, scalable possibilities. Since its inception, services have improved and early teething problems have been rectified. More entrants into the market have only benefited the customer as costs are driven down to gain competitive advantage.
The big cloud players are all backed by household names, and yet cloud computing is certainly no panacea. Opting to outsource or offshore your data isn’t a decision to be taken lightly, and despite the many advantages that the cloud can offer it should be approached as warily as any other partnership.
It is possibly this aspect of engaging in moving to the cloud that is missed most often, and causes the most issues to the unprepared. Shifting to an “as a service” model – whether it’s software (SaaS), infrastructure (IaaS), platforms (PaaS), security (SECaaS), (Big) data (B)DaaS or any number of other acronyms that have been invented to bring mundane computation functions into a 21st Century format – means taking on a relationship with another business instead of purchasing a piece of hardware off the rack.
In fact, with advances in the capabilities of microservers (which might be the NEXT Next Big Thing) the decision of which aspects of your business to virtualize (if any) is of crucial strategic importance. A step which sees your infrastructure costs drop dramatically, but pushes latency and poor support and service on to your customers could well be the worst false economy possible for your business.