Re: Does that word mean what you think it means?
I might have chewed through a birthday recently, and might have spent far too many years in IT of various ilk, but I believe in the 'growing up, growing old, and growing have nothing to do with one another' axiom.
I've QB'ed linux on to the DC floor for my employer, from 2 to over 4K installations. From 'data appliance' to 'blades' to servers, to vms, clusters, storage farms, server farms and DB workhorses, webservers, application servers, integration and file servers.
"Containers" change a few things. Mostly, however I think the single largest issue with containers is that the expectation of what containers *are* and *can do for us* has a huge amount of variance, from the Dev's who seem to think that it will allow them to shorten development cycles, to operations who think it will remove the need to make sure things work to platform folks who think it will make it possible to keep hardware at 80% to management who are convinced that 90% of the systems could be collapsed on to two DL580s running containers to beancounters who see the Open Source tag and decide that it will be free.
sadly the entire lot of them are utterly wrong on all fronts. I will point out that, *if* the devs sat down together and decided to work together and work on some common ground the development cycles would get shorter. The Ops folks should sit down and decide what amounts to an acceptable set of limits of performance on the critical apps (Tx/s perhaps? *something fcs* or my continual question - what is too slow?) The platform folks need to decide what level of risk they are willing to assume, and how much of the app performance are they willing to sacrifice to a failure of hardware, and management and the beancounters need to sit down and decide what they are willing to pay for application performance.
I see a difference in development style between 'dedicated application environment' and 'containers' - i.e. scale up vs scale out - and I see a substantial change in application design between the two.
The major advantage in my books, is, once you've made the mental, logical and process shifts that would be required to go containers, you *should* have a single pane of glass somewhere that has all your relevant metrics, displayed clearly so that one can see where your business flow is broken. The "change" to containers is not something that will happen across an entire business overnight, but it *may* have a substantial impact on overall business functionality very quickly once started.
Biting the hand that feeds IT
