Updates…

It’s been quiet here for a while, but be things have been happening behind the scenes. In case your wondering the site (and surroundings) have been seeing a number of updates which eventually may make it into separate posts.

  • I’m running on a Digital Ocean droplet. It was provisioned as an Ubuntu 12.04 LTS, which is dead by now (as in no more updates including security updates). The server has now been roll up to an Ubuntu 16.04 LTS in place.
  • As I was messing around with the server, I’ve added IPv6 support.
  • The DNS has been updated to have full support for DNSSEC.
  • My Let’s Encrypt Certificates now has automated certificate renewals and I’ve upgraded to CAA support.
  • The Webserver has been switched from Apache to NGINX.
  • The PHP has been switched from PHP 5.6 series to a modern 7.0.
  • I’m adopting full Git-backed backup of all server setup and configuration using BitBucket.org. It’s not complete but most config files have been added and managed using GitHub.

These was the majority of changes on the site and server the past few months. With these updates in place, I might get back to producing content for the site.

Devops: You build it; you run it… sort of

DevOps seems to be sweeping through IT departments these years and for most developers it seems to be sen as a way of getting those pesky gatekeepers from Operations away and ship code whenever any developers feels like it.

The problem is however, that in the eagerness to be a modern DevOps operation, the focus is often solely on the benefits of faster releases (on the short term) the “DevOps” provide over “Dev to Ops”, and many developers do seem to forget the virtues Operations (should) bring to the party.

From my observations here are the top three fails when adopting DevOps:

  1. Too must focus on features, less on foundation. Often Operations is making sure that operating system, libraries and other components utilized by the system is updated for security and end of life. As these tasks does seem to provide “obvious value” for the users of the system prioritizing them seems to be a challenge (unless the developers find new cool features in the new version of a framework they want to use, naturally).
  2. Lack of monitoring tools. Making sure you don’t run out of system resources – be that disk space, memory or CPU – is boring. The same goes for customer support tools, diagnostic tools and other tools which forecast operational issues. As those tool belong to Operations, sure they can’t be important in DevOps and are often skipped or haphazard at best.
  3. No plan for handling incidents. As developers tend to move forwards and rarely lack confidence and thus the plan for handling incidents and operational issues is usually made ad-hoc when the issues occur. During daytime, when everyone is available this may not be a significant issue, but during nights, weekends and holidays, finding the right developer who can help often causes the incident to last longer and in some cases even worse if eager developers make changes in a part of the code they aren’t familiar with.

I do firmly believe that DevOps is the right way to build and manage IT systems, but I also find, that too many teams forget the Ops part and doesn’t incorporate the skills brought to IT from Operations minded people, and the potential to build better systems through an DevOps setup is thus often not fully realized.

(This post originally appeared on Linked)