Cloud Systems: The IT Architecture for the Future IBM Blog
Written by Mike Briercliffe
Cloud has changed over the years.

The first time I heard the word “Cloud” in computing was probably about 35 years ago. A very talented techie was drawing a system architecture on a whiteboard. He drew something like a fork of lightning going upwards. On the end of it, he wrote “Cloud!”

The term “The Cloud” in that context, as I understand it, had first come from IBM. At that point it referred to a place where another service existed, usually to be called upon for storage and backup from the in-house computing set-up. Any thought about actually using it for processing in normal business life was rare, chiefly because response times were limited by the access speed to and from the potential compute resource. Broadband has changed that of course – though it’s still not universally up to a great standard is it?

So – What is Cloud?

Well – I’m tempted to say that it’s the label that finally gained the consensus of the industry to describe the non-local information technology phenomenon, after dozens of other terms didn’t stick! And – like other acronyms and buzzwords that we have spawned over the decades, it’s often used inaccurately by the industry at large, often confusing themselves AND the user population.

Wikipedia has this to say: “The term Cloud Computing comes from English-speaking computer professionals who sought to name new computer systems that operate by the joint action of disparate elements brought together regardless of their geographic location and underlying infrastructure”.

Remember “Grid Computing” (the use of huge numbers of computers inter-netted networked together for processing power), “Utility Computing” (IT supply akin to electricity, gas and water), and “ASP” (application service provision)? They are terms that have been popularly subsumed into the general cloak of “Cloud”, with at least one of them representing an approach that really isn’t “Cloud” as we think we know it at all, in my opinion.

“Software as a Service” has largely avoided becoming thus cloaked – and “PaaS” (platform), “IaaS” (infrastructure) and also other “XaaS” FLAs (four letter acronyms) were/are frequently born out of this Cloud approach. The reality is that most of the computing requirements of any organisation can now be served with the use of remote compute and storage resources.

What about the subsets of the Cloud Approach?

This part of my blog series is too short to reach into the why and wherefore of Public Cloud, Private Cloud and Hybrid Cloud. Save to say that most of what I see in business these days is ”Hybrid” – an approach that combines the advantages of Public, Private and often no true Cloud at all.

We are still in Cloud transition in many senses, though I’d suggest that the construction of new application services really cannot and for the most part does not start where it used to do! Cloud and Mobile are the places where new applications start their life these days, surely? Acquiring large computer servers to put in-house is much less common these days and Cloud architectures are truly in the ascendency.

So what are the key questions for the future?

First, I would focus on the resilience and the security of the environment. How good is the support from your vendor and how durable is that organisation? How commercially reactive are they? How security conscious AND security capable are they?

In future blogs I’ll ask questions relating to the nuances of the architectural models, skills and training requirements, operating costs, deployment, integration and migration issues and other aspects that require consideration in this architecture for the future.

The Journey

I now want to delve a little deeper, exploring some of the issues that accompany the Cloud “journey” – and in this post, that’s the twin challenges of integration and migration, both of which I’ve been discussing recently with folks in the industry.

So, what are the integration and migration issues surrounding Cloud?

To my mind, these break down into two distinct scenarios that are both demographic and technical in nature.

On the one hand, there are developers who have only ever known the Cloud and are extremely proficient in that environment – ‘Cloud Denizens’, if you will. On the other, there are developers who are skilled in pre-Cloud development and, by necessity, have acquired (or need to acquire) Cloud fluency too – let’s call them ‘Cloud Settlers.’

This creates an interestingly skewed dynamic, because so much of the integration and migration activity around Cloud is focused on making legacy systems work with Cloud systems – a requirement that fits better with the Settlers’ wider skillset than the narrower purview of the Denizens.

An immediate issue, then, is this: how do we rebalance this skew of skills? What are the integration and migration tools that can rapidly equip a Cloud Denizen with understanding of the environment that a Cloud Settler has understood for years?

Another pressing integration and migration issue peering down at us from the Cloud is this…

When it comes to making legacy systems work with Cloud systems, which is the best approach: integration or migration? Or some of both?

These are two very different beasts. Integration can be ‘slight or tight’, giving dev teams considerable scope to vary the degree of interconnectivity, and the workload and risks associated with it.

With migration, the legacy code is probably redeveloped to create a Cloud-based translation of the original legacy programming, with the slick availability, ubiquity and elasticity of the Cloud right there in its own DNA, rather than being dependent on a conversation with another code environment. But this is high-risk, high-stakes stuff, with almost limitless potential for error – as some banks attempting to move from legacy integration to legacy migration recently (and bruisingly) found out!

So, integration or migration?

Despite the undoubted benefits of migrating legacy systems directly into a Cloud environment, integration has the advantage that it meshes with the legacy code that’s proven to work and therefore likely to carry on working.

But nothing’s ever that simple in our world, and the reality is that developers and their teams, in order to navigate the relative risks and returns of each approach, would be well advised to seek the advice of an experienced, established Cloud technology partner (and that goes for the other Cloud topics I’ll be looking at in the next few posts in this series as well).

Back to top