DevOps and what you wont hear

DevOps is about Automation, the ‘A’ in the CAMS acronym so you really need to understand the following to make a success of it.

Data, Data, Data – metrics and instrumentation are key to planning, execution and understanding progress

Necessity is the mother of invention; if it ain’t broke don’t fix it <Powershell or bash might be the right answer>

Legacy businesses may be able to use existing automation tools as effectively as emerging tools for automation

Choreographing a service is more important than automating a server

Redressing the failures of historical behaviour is hard nee impossible; tread carefully with legacy

Open source changes rapidly; keeping current needs a process

Workflow ideas are emerging but confused in the Configuration Management community

You write positive actions when building something. Removing something needs a positive action too. Is an immutable infrastructure practical for you?

Physical infrastructure is harder than virtualisation which is harder than cloud

Community doesn’t replace your own expertise

It is all about infrastructure as code – consider your need for a UI and how your user experience will benefit | suffer

You can test from the inside out or the outside in; which is better is yet to be decided

Advertisements

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

Enterprise Service Bus

I have heard many very smart people talk about the benefits of the enterprise service bus (ESB). I like the idea and am familiar with brokers, subscribers, queues etc.

ESB’s work for developers and for the business systems they build. But the most recent context is to use the ESB as a configuration management subsystem to build complex cloud infrastructure.
It just wont work for the following reasons:

  1. ESB’s are the domain of developers; sys admins don’t understand messages, brokers and queues – you might as well be talking another language
  2. The complexity of the ESB makes orchestrating a solution very difficult
  3. ESB’s are not real-time, declaritive.

I wait with baited breath to see whether VCE has yet delivered its’ solution uisng SonicMQ.

Now, DevOps – that is an approach that might just work but it needs a more educated IT management specialist.

Converged Infrastructure = So What!

Dell, HP and EMC/Cisco have all jumped on the band wagon and been joined by some interesting startups too ( step forward Nutanix)

What is it all about?

A single pre-engineered system that incorporates storage, processing and networks.

Is this new?

No. Isn’t that what you got when you bought from IBM or DEC in the 90’s? And wasn’t this sort of system considered a risk due to vendor tie-in and replaced in favour of open, and more recently, commodity systems?

Nothing is black and white.

It is clear that many big IT shops spend too much time tweaking the hardware ad nauseum which does not add to the bottom-line for the business.

It can be argued that they have felt the need to do this because the right balance between cost, availability and performance come at the expense of good engineering.

The thing is however that hardware has become faster, cheaper and pretty much everything is a commodity CPU these days. Too much time is spent playing with tin while not delivering anything so the infrastructure guys only have themselves to blame for the re-emergence of the pre-built system.

While I want a guarantee of performance and availability the hardware really on matters a little. I want my hardware on the floor quickly and ready for me to run my applications nearly instantaneously; and I want to be able to deploy may applications at the touch of a button. So, sure, Converged might be good but I want self-service and I want it now.

Only you can determine if converged is right for your business. The primary sales propositions are:

  1. we do the engineering to deliver a secure, scalable, high-performance platform
  2. we certify it for specific workloads

The moot point is that you are delivering a ‘service’ and your service is hopefully distinct from that of every other service provider…….

  • so this certification……… is it actually worth anything; does the profile of your lync|UCS|SAP|PaaS mirror what got certified?

I reiterate: converged might be good but I want self-service and I want it now and that is a proposition about software and process automation!

Disclaimer: I  worked for VCE and Digital Equipment.