I need tools, lots of DevOps tools
Today we have DevOps tools, lots of DevOps tools. Which ones are the right ones, and which are not so good? Is there a good or bad tool, or is it simply opinion?
DevOps itself is a coined term (a bit like Agile - in fact it is very closely tied), although I find it useful to describe a not a person, skill or tool, but rather as a culture - a way of working. DevOps talks about collaboration and communication between the people who build software stuff and everybody else, then whilst addressing that, make it all automated, reliable and rapid.
Not all tools attempt to address the same challenges nor are they equal in the way the address the ones they do focus on. They tend to be grouped into categories (according to Gartner) which flow together as a logical process of how you would build and operate software solutions:
- Code - IDEs;
- Build - Source control, Continuous Integration;
- Test - Unit and integration testing;
- Package - Artifact repositories;
- Release - Change management, release orchestration;
- Configure - Configuration management, service discovery;
- Monitor - Logging, alerting.
I like thinking of DevOps tools in this way, each organisation and/or team would pick their own tooling in those categories. In those categories you can see there is no mention of Design, Platforms, etc. I guess you have to balance the term DevOps somewhere.
Although I do think Gartner missed out a key category - Communicate. How do teams keep each other up to date and manage work?
Which ones do I prefer? Well all I can tell you is what I currently use, so this is very much personal and team choice:
- Code - IntelliJ;
- Build - GitHub, Maven, SBT, Circle CI;
- Test - Whatever works best with the application technology;
- Package - Docker images;
- Release - Ansible, Circle CI;
- Configure - Ansible;
- Monitor - CloudWatch;
- Communicate - Slack, Asana, Realtimeboard.
It makes sense to standardise on stuff that requires inter-team working, e.g. communication tools, source control. But hopefully most other stuff can take the defacto route on a per-team basis. I want consistency within the team, but that team doesn’t need to be consistent with other teams in areas that won’t affect each other. For example, who cares if the Hadoop engineers use a different orchastration tool to the Mobile App engineers, the two teams are unlikely to ever share tasks.
So my recommendation is that each team should pro-actively standardise on stuff that matters to them, and each department/organisation should standardise on stuff that is used to share and communicate across teams or when there is a large benefit to the team to standardise. It also makes sense to lean towards some consistency on bigger technology stuff, where everybody can benefit from things like commercial support. But don’t standardise on stuff for the sake of it though, for example who cares what IDE somebody uses, your build systems should be agnostic.
Also, don’t standardise on stuff like this at an organisational level, it creates needless bureaucracy for very little benefit and a whole heap of negatives. Instead employ talented engineers, create a culture of freedom and responsibility, then allow them to make the choices on the tools they want to use.