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

Advertisements

The value of metrics

If you do not measure it you cannot manage it. That has been an management consultants mantra for as long as I can remember, yet so few IT operations have defined performance indicators and this surprises me.

Sure, people talk about 5*9s and mean time to repair, mean time to fail and mean time to isolate but real operational performance indicators and key performance indicators are rarely considered.

It is true but put more appropriately….
If you cannot measure it you cannot improve it so please get measuring!

What to measure? Well that is the most important decision.
I take a range of approaches – clearly if you do something often you can measure effort, iterations and the impact on your operational team. At the other end of the spectrum perhaps there is one task that occurs rarely but is so costly (SLA, effort, risk, knowledge) that it warrants automation. You know your business and are best placed to judge.

If you want advice on what to measure then get in touch.

Technology Leadership

The shelf-life for many leaders in IT is dreadfully short and often leads to organisations being unable to comprehensively execute strategy.

Achieving balance between delivering today and innovating and setting stretch goals is incredibly hard.

Perhaps the issues in many organisation are compounded because too many technology leaders have a distant relationship with technology?

Clearly there are a number of topical debates around technology at the moment and I have participated in, and led, many discussions around them.

With many organisation having broad ranging strategy that touch:
– Cloud
– DevOps
– Big Data
– Mobile
– Security
Is there little wonder that CIO’s and even CTO’s struggle?

Perhaps we need to look at this debate from a number of angles.
1) Education

Too few of the innovators in the technology world can present their ideas clearly and even when they are able to there is often an agenda. Take big data as an example; a storage vendor in this space has one perspective, traditional RDBMS companies another and Map Reduce occupies a third position.

Leaders need to take the time to educate themselves and guide their team to identify problems and map them to solutions. Vendors need to start helping with education and community events more to enable end-users to have a better understanding.

2) Experience

Expert technologists need to develop new skills, or hone their existing abilities, so that they are able to assist in the corporate decision making process. And conversely their leadership needs to have a better compass to help identify who they should trust and when to be skeptical.

Technologists need to also broaden their exposure, experiment and not be afraid to make mistakes. But all the while be realistic about the potential and potential pitfalls of a decision to go down a direction of A or B.

3) Business Value

Enterprises must learn to measure the benefits of their strategic choices to help improve.

Suppliers must start to measure the value of their solutions and not simply in a sales cycle but when also be prepared to work with their clients in the long-term when real results can be measured.

Is your product|service mature enough?

How much Enterprise software sits on a shelf unused?

Unused because it didn’t work as expected or perhaps it required a higher level of skill than perceived. Maybe it was bought by one team and ignored by the others?

In reality it is probably a mix of these with a few other challenges thrown in for good measure.

With open source and community-driven software – will this impact the value chain?

Heath Robinson

Let’s discuss.

Be under no illusions open source often has a commercial basis so what levels of support or frequency of release might you expect. This will vary dramatically across companies, product and geography and in many cases you will find the contributors are also active in the support communities responding to you before any commercial response.

Then consider the maturity, or perhaps better expressed as enterprise understanding, of the contributors. Do the people designing, writing or reviewing the code or features have a real background in the enterprise or an understanding of context. As someone who has spent two year at Chef I believe this is one of the more significant and, as yet, unresolved challenges. It is UNLIKELY that the community does have exposure or understanding!

Do not under-estimate the expectations of the community. Open source fosters an expert audience – expert but often lacking emotional connection or empathy. The author has observed contributors who no appreciation of the expertise available in a standard IT department and have never been exposed to IT service management tools or practices. This is not surprising but it is a significant consideration when you buy in to their ecosystem. Beware of features or processes that don’t or cannot fit with the way you run your business, examples include:
– inconsistent user management / directory integration capabilities
– ignorance of IT risk and mitigation
– poor documentation
– over-reliance or ignorance of tooling and process such as orchestration
– the ‘you can write that’ syndrome
– solutions that actually cause problems including false positives and ignorance of the need to use exception-based notifications when working at scale

DevOps engineers have existed since …..

DevOps engineers have existed since computing started….but they were called Engineers or sometimes Systems Engineers.

Engineers have not disappeared but they have changed.

Five things occurred which have had a serious impact on the ability of IT to deliver and they were mostly related to cost pressure and the limited skills available to support the enterprise. Each of the following have contributed:
1. the adoption of outsourcing is clearly one
2. increased IT compliance requirements and resulting regulation
3. the complexity that comes with increasingly complex products
4. off-shore development
5. workplace politics

Innovative people always have a response to these challenges, responses include automation, virtualisation and Cloud but they are not a silver bullet and you may notice that the contributors identified above are not technical but more closely linked to people and process.

In very few organisations are there sufficiently qualified, motivated and competent people to deliver working solutions. The system integrators operated in this field but their skills have been diluted by off-shoring.

Technical staff in the Enterprise have a huge wedge driven between operations and the business.

The most valuable resource any organisation has is its’ people. People who solve problems.

So perhaps the use of the term DevOps is helpful as it emphasises the capabilities of the real problem solvers in a business. Let’s just be careful because like too many other things in IT in particular everyone now seems to be a DevOps engineer.

The reinvention of Engineers who are focused on delivering fully functioning solutions is a positive thing; but did they disappear in the first place?

ps: a very smart boss of mine told me in 1996 that I was ‘build, implement and run’.
He used the term to help a failing project refocus; it was late, requirements and implementation were floundering and we were not being paid.

3 months later and after a lot of hard work with 3 people spending far too much time in one another company the project delivered and was hailed a success.

The phrase ‘build, implement and run’ sums up for me the whole DevOps movement. And the three adversaries in BIR are now my most trusted allies (a developer, DBA and system admin)

Autonomics?

I’ve been thinking about self-healing and self-scaling computers recently – all of this really is quite achievable with todays’ technology but lack of insights into the business and fear are preventing it from happening.

The ever increasing speed of processors and advances brought about by cloud computing, especially in rapidly provisioned environments, make it possible.

The problem? IT Operations fear the use of these environments?

Are you a Thought Leader?

How is it possible to describe oneself as a thought leader?

Surely that accolade needs to come from ones peers and actually be reinforced by a consensus from many different sources.

Admission – I am not a thought leader ……

I have some great ideas and am able to articulate very well. I have hopefully helped others along the way solve problems, implement solutions but also develop their skills.

I am just a professional who studies hard, works on difficult things, is diligent and empathetic. If people get value from me in any way I am happy.

Recommendations & Endorsements

I recognise that linkedin has many parallels with my resume – my profile is important to me.

I only want facts and content I can justify on my resume and wish to be able to explain achievements, context and identify the people who contributed to my experiences.

I value the network that has grown around me through many years of hard work and sometime soul searching while working in challenging environments. Some of my most valued customers, colleagues and partners have become important linkedin connections. I am lucky that people I know and value regularly request that we connect and really appreciate it when I am fortunate enough to receive a recommendation. I think most of my recommendations have come from people who have worked with me on hard projects or have seen how I perform in challenging situations; and this really matters.

I don’t ask for recommendations and don’t make them lightly.

I do not endorse someones skills without personal experience to show that they excel in that domain and I do not solicit endorsements.

I ask myself why do people ask me to recommend them but mostly I wonder why people who barely know me have endorsed my skills.

Let’s not devalue our currency – recommend the exceptional and endorse where warranted.