\u201cHybrid,\u201d is the answer.<\/p>\n
I\u2019m talking about \u201con-prem vs cloud,\u201d the bugaboo trick question that has plagued us for nearly a decade.<\/p>\n
What I mean by reframing the question like this is that \u2013 absent other details \u2013 the location<\/i> and ownership<\/i> of servers is much less important than the architecture of the solutions.<\/p>\n
So let\u2019s get on with it. This is more than just philosophy. We are engineers \u2013 we thrive on specifics:<\/p>\n
A colleague of mine likes to say, \u201cssh is cheating.\u201d What he means is that it is unacceptable, in 2017, to leave your system so incomplete that it requires a human to log in and perform manual configuration in the event of an update or (heavens forfend) a reboot. Ssh as a protocol is fine (most of the tools below run over that protocol), it\u2019s the manual intervention that constitutes cheating.<\/p>\n
System configurations should be defined in software. It doesn\u2019t really matter which domain specific language we pick, any of Puppet<\/a>, Chef<\/a>, or Ansible<\/a> will work fine. It is<\/i> important to pick one and get good at it, rather than trying to maintain a polyglot mashup.<\/p>\n Configuration scripts need to be under version control, just like any other software. Github<\/a> is the default code repository these days, though there are reasons to go with something slightly more pre-integrated like Bitbucket<\/a>.<\/p>\n Configuration changes should follow a structured process like Gitflow<\/a>. It is worth noting that this tool is only helpful if coupled with human<\/i> processes of communication and trust. Human beings need to check and validate each other\u2019s work, to avoid overwriting or colliding with each other\u2019s changes.<\/p>\n