Scale out, not up: the Cloud mindset is different

Just come off a call with a group which meets regularly by phone to think about the issues of moving corporate IT services to the cloud.

The debate is moving on. Originally, it was triggered by the emergence of Amazon’s EC2 and S3, and similar services, which enable individuals to have easy by-the-drink access to high powered and flexible compute and storage power.

Then, it was key questions about how to enable enterprises to move services to “the cloud”: what do you move and how, and what are the risks that have to be understood and managed?

Now, there’s an understanding that a hybrid model will have a lot to recommend it. Cloud services offer flexibility, and that’s more important than cost saving. The question is no longer “In-house or cloud” but “How do we integrate cloud with in-house, for flexibility and overflow”. You set up multiple-hosted services so that when in-house runs out of capacity, the request is routed seamlessly to a cloud resource.

Someone on the call characterised this as “Scaling out, not up”. And it requires a different mind-set when applications are created. Something which recalled to my mind the “reverse assumptions” for heterogeneous wide area distributed systems, created by the UK/European ANSA project something like 20 years ago. I said I’d re-publish them. Here they are.

When building a distributed system, a number of assumptions which are commonly made when engineering systems for single hosts not only become invalid, but have to be reversed. The most important of these are:
local >> remote
more failure modes are possible for remote interactions than for local ones
direct >> indirect binding
configuration becomes a dynamic process, requiring support for linkage at execution time
sequential >> concurrent execution
true concurrency requires mechanisms to provide sequentiality
synchronous >> asynchronous interaction
communication delays require support for asynchronous interactions and pipelining
homogeneous >> heterogeneous environment
requires common data representation for interactions between remote systems
single instance >> replicated group
replication can provide availability and/or dependability
fixed location >> migration
locations of remote interfaces may not be permanent
unified name space >> federated name spaces
need for naming constructs which mirror administrative boundaries across different remote systems
shared memory >> disjoint memory
shared memory mechanisms cannot operate successfully on a large scale and where remote operations are involved.

There was, and is, another one as well. When you’re creating an application – any application! – don’t assume it will always stay with the localised architecture you’ve created it in. The gotcha assumption these days is that the app is being created with links to a private cloud not the public one, so it’ll stay that way. Deal with it – interfaces, databases, security, the whole nine yards – as if, one day, parts of it will sit on public infrastructure.

• ANSA project, 1984-1998, document repository (now free access)
• ANSA: An Engineer’s Introduction to the Architecture, ANSA project, Nov 1989 (see section 2.1 p 3 for the reversed assumptions)
Distributed architectures: reverse assumptions, still relevant, my previous post (ITasITis, Jan 2008)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your 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 )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s