Pages

Sunday, 5 March 2017

In these days of DevOps, we have so many tools available to us.
From configuration management, to NoSQL databases to containers and
orchestration. And under open source, many are available at no cost. While the
tools work may solve predominately technical problems, I believe that a
significant proportion of the problem in making better systems solutions, are human.

A
common issue I've seen is not understanding enough about what problem
needs to be solved in the first place. But there seems to be a new tool
that Sometimes the problem can inadvertently become "How can we
implement technology X in our business?" rather than "How can the
implementation of X help this business?".

In
my team we've discussed whether we should migrate from Puppet to Ansible. Some people say Puppet is slow,
complicated and hard to make reliable. If the criticisms are true, then
we have the opportunity to be more productive by
migrating. If they are not true, then the migration will cost a lot of
time only to end up in a similar place. When faced with a problem that
looks like it might be solved by the implementation of a new tool, there
a few key questions we should be asking ourselves.

Is the problem with the current technology or it's implementation?

Consider
best practices, whether the design is appropriate for the problem faced,
whether extensions to the tech (plugins, libraries, hardware) would
solve the problem better.

Are the problems solved in a more recent version of the tool?

The
most common issues with a tool are often known by the organisation
behind it, sometimes a fix is in a more recent version or it may be on
the development roadmap.

How would the cost of migration be offset by the benefits of the new technology?

Costs include the training of staff, the development of new workflows (if required) and the time it takes to develop replacement solutions

Is the new tool weak in places where the old tool is strong?

While
the benefits of the successor are touted well, the things it does not
do as well may be harder to find. Often such problems are not evident
until the migration has started.

The
weighting given the questions will change depending on your
resources such as time, money, skills, and attitude but I believe they
are still valid in most cases. They are not reasons not to change, but appropriate
consideration will make it easier to plan for any change and ensure the benefits are realised.

There
are issues with every technology but I don't think shifting every time
something shiny comes along will make us better engineers. It is often
in overcoming challenges that we improve our skill in engineering. Our
creativity and understanding of technology are both developed when we
persevere with problems. Even if we ultimately fail to solve them the
way we like, we still gain by understanding more about what is required for the solution. This way, when we do need to take a technological step
forward, we can be confident we're heading in the right direction.