- 1st November 2016
- Posted by: Stephen Downie
- Category: Code, DevOps
This week we’ll be looking at why we should reuse add to code that others have written when doing Devops. In the past Sys Admins have a reasonably lonely existence, deploying Windows or Unix environments, configuring LDAP servers for authentication, mail servers for communication and so on.
REASON 1 – QUICKER TIME TO DEPLOYMENT!
This one is pretty obvious, pulling code off the shelf or from a marketplace is going to make it much faster to get your platform up and running and software configured. Many of a Sys Admins tasks are repetitive, be it installing an operating system, configuring users etc, why not let code do it for you? And why write that code yourself?! Puppet has Puppetforge, Juju has the Charm Store and so on, programmers reuse libraries all the time, why not use the same ethos in Devops?
REASON 2 – PARTNER PROGRAMMING, MORE LIKELY TO SPOT MISTAKES AND SECURITY FLAWS.
In the programming world we make good use of ‘buddy programming’, ‘pair programming’ or whatever you want to call it. Each programmer can check and critique the other ones code, this ensures a level of code quality and stability, it should catch mistakes the other person has missed. Of course in the Devops world, if you’re reusing other people’s code you should probably check it, you don’t know who wrote it, their level of competence or what their requirements were, it is also very important to check from a security standpoint, you never know what’s inside the code without eyeballing it.
These days I can just about apt-get install Apache HTTPD without reading the manual, I’ve installed Nagios a bunch of times and everytime I have to read the manual, the same with Dovecot. Some tasks you do so often you could end up doing blindfolded but others like Dovecot installations I have to read up how to do it carefully and installations like this only take one small mis configuration to end up a mail relay without you noticing. Similarly, you configure Nagios incorrectly and you’re leaking confidential server data to prying eyes on the web.
By looking at the code, you’re saving time because you’re not writing it but you can also add value because you can fix kinks and niggles, or of course add whole new features that the original developer didn’t add because it didn’t fit their requirements…..
REASON 3 – BUILDING COMMUNITIES
Which brings me on nicely to building communities. Github is a great example of a platform that exploded because it did a great job at providing services and hosting communities and many communities have thrived being on Github. In the open source world, active communities are key, they provide roadmaps and direction, they provide support and bug reports, they are the people who use the code. There is no reason why Devops platforms need to be closed source and secretive, sure not everything you write is going to apply to everyone else, but it will apply to some people and that helps foster communities. Its leading by example, one person open sources their playbook, another person is sure to follow, by pooling this information it allows others quick access to the code and lets them push pull requests and more back up to the projects to enhance what already exists rather tha forking and going off it their own direction.
Of course there are many other reasons why we should look towards code reuse in Devops but these examples will hopefully provide some examples as to why code reuse is key to streamlining operations and getting everyone moving forward quicker.