We’re Automating! What to do?

I am delighted, you have decided to automate your “applications|process|infrastructure”. I’ve been automating since the mid-90’s.

Your cloud is already automated ….. of course. ( It is, isn’t it? )

So where do you start?

Do you choose to use Chef, Puppet or even HP CSA and get writing some code. Or shall we pause for breath and consider what to do carefully?

Don’t stop but I recommend pausing, pausing is a good option.

There are many ways to tackle the task at hand so I will share some of the options.

Note: automation and standardisation go hand in hand. Work out the common patterns, valid and illegal configurations and address those. It is not necessary or desirable to solve every problem when automating but focus on your needs and application landscape.

And it really doesn’t matter which tool you use – make a selection based on your use case and your organisations ability to adopt. A domain specific language (DSL), script or PowerShell or a packaged solution – it doesn’t matter provided it fits with your organisation. You will ultimately end up with policy setters who are highly skilled in the tooling and users who consume the policies.

Anyway – onto approaches.

1) Take a vertical approach and iterate to ensure you deliver 100% of one product. Bear in mind that with most applications you will need to choreograph actions i.e. build one server followed by another or start process B after A. So automating 100% of a n-tier application will need orchestration – and to do this you will need more than Chef.

2) Take a horizontal approach and cover one aspect of your operation – historically this would have been something you may have done to address a patch management problem or perhaps deploying an agent technology like backup. Again, consider carefully whether patching (OS) is core or whether containers or images can help you to solve this problem in another manner.

3) Go passive. This will very much depend on the technology you have chosen to automate with. You may have an option to deploy an agent in a read only mode. This can be invaluable but emerging ‘convergence-centric’ tools like Chef are not appropriate for this approach. You need something that does discovery AND probably compliance.

Passive allows you to gather data on your estate in order to gather metrics or identify problems (think compliance) so that you can tackle your problems systematically. Metrics are crucial so this has some real merit.

4) Look at operational metrics and….
– automate the task that you do most often and which already has a ‘run-book’
– automate the task that costs most time|effort
– automate the task that only Joe knows how to do
– take on the issue that costs most downtime or is the highest revenue

(separate blog on this)

5) Tackle one task and automate every single aspect of it. The ports, virtual hosts, primary and secondary controllers for a specific agent. Or perhaps automate until you have achieved 80% of the use cases.

Consider automating Oracle deployments as an example. Should you extend this to include RAC, all of the RAC pre-requisites, every conceivable RAC configuration option?

6) Bite it all off and get everyone automating!
Please don’t do this, at-east not until you have thought long and hard.

So know you have some ideas you really need to start thinking about the metrics; they are core to your success. Actually the only way you will know you have been successful is by gathering and using metrics.

Post script:

Other thoughts you must consider:

– How to upgrade a service and keep within your SLA
– How to upgrade a service
– incremental change (does my tool replace or update my configs)
– hard cases (schema, brokers) XML
– giving users access to your tooling; as a user, to set policy

– can you treat infrastructure and apps the same

– do you create a team specifically focused on automating, configuration management or DevOps

Confused Cloud & clear thinking

"Clarity of Thought"

Space to think










Public, Private, Hybrid, Legacy Рseems like mission impossible?

Cloud computing, whether delivered on-premise or by exploiting platforms such as Salesforce, EC2, Rackspace etc. is well within the grasp of anyone; just be clear what you want to achieve.

Remember Cloud is two things:

  1. Ubiquitos access – secure but available over the Internet
  2. IT delivered as a service; on-demand and with the implementation invisible to the consumer

Based on this definition you can probably see why I do not see exploting Cloud computing as a significant leap.

Caution must be advised when you engage with suppliers or you might be persuaded by your suppliers that Cloud is far more:

  1. An entirely new architecture such as Vblock [or FlexPOD for that matter]
  2. A 100% technology refresh running in isolation from legacy services
  3. VMware / HyperV or another flavour of virtualisation
  4. complete automation [even autonomics]
  5. Springsource
  6. A new, dedicated management stack

While it might be desirable to incorporate some of these aspects into your cloud strategy it is not mandatory.

Economies of scale might demand that you can support multiple tenants on a single infrastructure; but again this is not a technical requirement more of a commercial consideration.

If you build your own Cloud from the ground up you might find that you have missed the boat. Of course large enterprises still have a window of opportuntiy; but emerging service providers need something exceptional to get a foothold.

More to follow.

So have you got your Cloud running? Really?

Along with every other enterprise and many medium-sized businesses you have decided your future lies in the Cloud.

Like many before you perhaps the first stop is Amazon EC2; you will not be faulted for using this platform and I have certainly used it too. Amazon are undeniably the lead in this space but there are also many other contenders including Salesforce to name just one.

If your business relies on IT or you are in the service provider space it is likely that your tenure on EC2 will be short-lived, afterall it is not as cost-effective as it appears at first and performance can be a bit of a gamble.

You decide to build your own cloud – great!

Do you build it for any one of the IaaS, PaaS models that is out there? How about a Private cloud? Does the cloud also commit you to massive virtualisation? How about incorporating those critical systems that you run your business on into your cloud; making it a hybrid cloud.

Does your cloud platform need to co-exist with existing IT management capabilities like ITIL or are there industry specific audit requirements like PCI that might affect you?

This is rapidly becoming really complex so let’s try and take this in stages….

Your goal is to create an efficient, flexible platform that is as easy to manage and change as it was to build, essentially an IaaS platform for now.

How are your plans progressing, are you on track? Has VMware or Microsoft promised you agile, dynamic and maybe even autonomic computing? Did one of your hardware suppliers tell you that the only approach was Flexpod or Vblock or perhaps you decided that a ‘converged infrastructure’ was what you needed.

Perhaps it is not surprising that the most successful deployments share some common characteristics and these are probably not on your suppliers agenda:

  • Tight control on the services that the client wants to deliver; based upon areas that they already have packaged and a solid process for delivering
  • They have driven their suppliers & selected only the components they need and already know how to use
  • They are happy, even determined, to start small and simple
  • Implement on top of known hardware rather than a rip and replace
  • A strong, considered leader