Conducting your Cloud

A fellow blogger suggested blogging on what had happened to me over the previous week, and although getting drunk and eating too much would probably make a great post, it doesn't quite fit with this site, so....

....I have to talk about Cloud Orchestration and Automation.

In the first instance I think it might be worthwhile level setting some ground rules around Orchestration and Automation in the context of Cloud Computing. There is a discreet difference and I find myself having to explain this perhaps more often than you'd realise.

Firstly, automation in the context of Cloud Computing relates to the removal of human interaction in low level tasks, such as installation of Operating Systems and management tools, installation of applications, configuration tasks and firmware updates (yes, this list could continue on - for a long time).

Secondly, orchestration in the context of Cloud Computing relates to the way in which multiple services or capabilities are executed to deliver an end product, be that to the Cloud Consumer, Cloud Provider, Cloud Auditor or the Cloud Broker.

So why is this important?

Well most companies will already have some level of automation, whether they realise it or not. System Administrators have been writing and fine tuning automation tasks in ksh, perl, bash, php and C since the beginning of time. In fact it is hard to find a customer who doesn't have some level of automation. These tasks have often been lovingly (I don't use that word lightly) nurtured to ensure that they meet the specific requirements of each individual business and more often than not are the glue that holds entire business processes together.

So when a big vendor offers to transform a legacy architecture which will undoubtedly involve the migration from one Operating System to another the first thought that rushes through an Architects mind is 'What about all the bespoke scripting we've developed over the years?' - 'I remember that bloody EDI script causing no end of problems' or 'We lost an entire month end processing run because the SAP upload script failed'. 

This is only natural, and although this isn't the exact reasoning given to not wanting to migrate it is more often than not the reason that ignites the 'Technical' debate and introduces the Fear Un-certainty and Doubt (FUD) into the minds of the senior Enterprise Architects and IT Decision makers.

But is it a real risk?

Well no, and I say that as somebody who has both developed and migrated legacy scripts from one Operating System to another. This is particularly true of UNIX scripting as 9 times out of 10 a simple tweak can ensure the script will run on the target system. Sometimes you may be required to perform a little more in-depth detailed discovery and analysis to understand why a script is behaving in a different way on the target system, but this effort will in no way out weigh the cost savings of migrating from a legacy architecture to a Cloud architecture.

The other benefit is that the scripts to be migrated can be analysed to identify the potential for migrating the functionality back into an application or an automation/orchestration tool. This will suddenly allow for the introduction of full life-cycle management and service alerting for your business processes, as no longer would they fail due to 'unknown' scripts.

It would also becomes easier to impact business process change on your IT architecture and to deliver a more agile service back to the business, and then you would be really 'conducting your cloud' ;-)