4 ms·
> This essay is excellent, and to me it clearly highlights the difference between an experienced architect that has been there, done that, and got the battle-sc
by inferiorhuman 9y ago
> This essay is excellent, and to me it clearly highlights the difference between an experienced architect that has been there, done that, and got the battle-scars, and those that have not. The attitudes and behaviours Lawrence describes are depressingly common in the industry - where the bandwagon is the most common form of transport - to the detriment of us all.
As someone who doesn't like docker (the software) or particularly trust Docker (the company) to be good stewards of docker: I disagree. To me, the author sounds like someone with a severe case of NIH.
Sure, you can write ad hoc scripts to manage deployment and testing (which is what docker essentially started as — ad hoc sugar on top of lxc). Ad hoc does not scale. At Megacorp we had apps written in Java, Scala, .NET, Ruby, Python, JavaScript, and things targeting those VMs like Clojure/CLJS. At some point the value of providing a standardized interface (docker or not) for both the developers and the operations folks outweighs whatever NIH might be kicking around. Operations for each app might be the responsibility of one or two people. If someone got sick or went on vacation all hell would invariably break loose. Being able to share a standard interface means it's much easier to distribute the work. Having a standardized interface means that once a problem is figured out in a staging environment, the fix can be rolled out with far more confidence elsewhere. I've seen the logical conclusion of doing everything ad hoc. And trust me, when you have dozens of products across at least four environments, with decades old legacy cruft in various places along the way, it ain't a pretty sight.
In fact my experience has led me to the ideal of: every environment should be identical aside from its scale. I'm well aware that docker doesn't accomplish this unless everyone's running Linux. However, the argument of just slap together some ad hoc scripts for the dev environment and then again some new scripts for the production environment makes my skin crawl (and it was a bit of an ongoing battle with ops folks at Megacorp outside of their docker shenanigans). Having the same interface for a dev environment that I do in production means that I can practice and test things well before they hit customers. Change requests become less scary. And, of course, my ubergoal: ad hoc environments become possible.