Cloud says 'no'
Internal challenges for the public cloud
Workshop Apart from a few laggard evangelists and smaller vendors with nothing else to sell, most people with an interest in cloud computing have concluded that a wholesale move of everything IT into the cloud won’t happen any time soon.
The various reasons boil down to a couple of fundamentals - that some things will always need to happen in-house, and that it makes no financial sense to throw away past investments and create them all again somewhere else, however hosted.
Given this more realistic starting point, the challenges of the public cloud are less about managing some seismic transition, and more making it work with what is already in place, in terms of internal IT environments, operational processes and user behaviours. In this article we look into some of the specific challenges, and consider what you can do to avoid being caught out down the line.
The first complications arise before any data can be exchanged, during the buying process. We use the term “procurement” guardedly, given that many cloud-based services can be purchased using a credit card for a subscription or a one-off purchase of CPU time - but indeed, this very different payment model can cause difficulties if spend goes above certain levels.
The default procurement process for most companies involves gaining approval for a fixed-cost purchase, which is then budgeted within a certain quarter; ongoing costs are budgeted separately and require their own approvals.
Without dwelling on the subtleties of capital expenditure vs. operational expenditure, rental models vs. subscriptions and so on for cloud services, there is bound to be a certain amount of chin-rubbing if executives start paying for core IT facilities on company cards and reporting them through expense claims.
This creates other problems - not least that the procurement process, onerous as it may be, exists to enable traceability and visibility of costs. It just isn’t feasible in the long term to run an organisation’s IT systems using credit cards, particularly if forward costs are unpredictable.
Once an online resource has been selected, appropriate due diligence has taken place (you did check the reliability of the supplier, didn’t you?) and a service has been deployed, the next set of challenges are around integration - with existing systems and applications.
No one system can do everything, so however good cloud services may be, they will always require data exchange with other IT systems, online or otherwise. So, your online CRM may need to feed your offline BI, or virtual machines running protein-folding algorithms may need to transfer large data sets back and forth.
This is the same, age-old challenge that has been discussed and repeatedly solved through generations of applications - most recently in the shape of service-oriented architecture (SOA). The solution could fill volumes - but in a nutshell, ensure you have thought about your data exchange requirements up front, both in terms of interfaces and volumes to be transferred. A bottleneck is a bottleneck, however it is hosted.
Access all areas
OK, so you’ve managed to get procurement under control, and all the data you need is where you need it, when you need it. But can your users access the service? It’s all very well having all of the processing in the world at your behest, particularly if it means people can work in places that they couldn’t before.
All that clever stuff goes to pot as soon as a facility is not available. As many cloud service providers have learned, and are now resolving, services from email to sales automation can benefit from a level of offline access. Enough said - but this is an important factor to consider in the selection process.
The beady eye
The final set of challenges for the public cloud are around manageability, as for any core IT system. The promise of SaaS (software as a service) applications may be that they are self-updating, which helps.
With the caveats of accessibility and due diligence above, cloud providers also claim that they can offer services more reliably and more efficiently than internal systems.
This may well be the case for more commodity functions such as email. Meanwhile however, even smaller companies require an internal IT role to monitor service performance, and (where possible pre-emptively) resolve any issues that may impact service levels.
In some cases this can just be a simple question of being aware when providers schedule downtime, for example for a network service upgrade. As the relationship between online and offline systems becomes more complex however, it becomes harder to separate the two - if an online analytics task using data from in-house systems should fail, say, spotting the fault and diagnosing the cause requires visibility on both online and in-house.
From a front-line support perspective as well, help desk staff and support teams will need to cover a range of environments and problems that were not previously in their remit. Irate callers will have zero interest in whether a service is cloud-based or internally managed. Sadly, cloud computing is not some alternate universe where everything just works. Whatever new opportunities are offered by online services, we’re also stuck with what we have.
On the upside, this means that all that best practice about systems and software architecture, IT management and indeed procurement is still valid. Indeed, given the option to just outsource responsibility to the cloud doesn’t exist, it becomes even more important to ensure the necessary measures are in place up front.
Later in this series will get into the specifics of making cloud work, drilling into some of these topics as well as the financial, security and sustainability aspects of using cloud-based services. For now we’d be interested in knowing whether you’ve got any experiences of your own to share, good or bad - and what lessons can be passed on to others thinking of incorporating the public cloud in their own journey towards better IT delivery. ®