In theory. I still have to see a cross-cloud solution that just works.
(1) Availability (Something fails eventually), both in terms of monitoring (Find out) and failover (How to resolve when this happens?)
(2) Security (Who had access to which key when? Are they still at the company? Where's the audit trail? Third-party managed security credentials ... can you say side-channel?)
(3) Legal jurisdiction (Are we allowed to put x in y location? Do we want government x using law y to potentially perform action z?)
(4) Latency (Site x on provider y is experiencing a DDoS)
(5) Heterogeneous management (What happens if something auto-managed gets manually-managed for awhile? Do things break?)
(6) Resource lead time and failure impact (What happens when the hardware you just wanted to spin up from the endless cloud supply isn't available?)
(7) Actual performance characteristics (Usually every provider offers only a specific selection of environments and offers weak to no SLAs/guarantees on real world performance.)
... and so on. A lot of these are sort of cloud restatements of the RFC1925[1] fundamental truths of networking. Also, this is all docker-specific, so it hinges on people wanting to build their infrastructure on a self-described insecure and immature platform and tie their whole management paradigm to it.
FWIW, I am still working on an OS and virtualization platform agnostic alternative devops process management tool[2] and am trying to get my company to agree to open source it. It can easily wrap docker, having far broader scope, and was designed to be future-proofed... it is thus potentially useful for embedded dev, the BSDs, real hardware, clusters, etc. It takes a very different paradigm to docker, abstracting cloud providers, services and platforms separately, and allowing the former to figure out how to connect and manage the other two internally... with standardized interfaces for major operations and notifications.
[1] http://tools.ietf.org/rfc/rfc1925.txt
[2] cims ... read on from http://stani.sh/walter/pfcts/ via 'original post'
Me too! I call it "shell scripts". Been in production use since ~1970. Seems to handle most of my needs. I just wish it was written in JavaScript.
Now the much harder problem of orchestration is still an unsolved problem and I think that is what the author was referring to.
For the devops crowd, I think fail-closed or fail-safe shell scripts work really well for orchestration. Too many times i've seen a really complex chain of operations make it much harder to debug and fix a problem because the tool was trying to be smarter than it needed to be, or ignored failures. You get faster development time, simplicity, portability, extensibility, interoperability, etc for free. And really i'm sick of re-writing the same tool only to later fix it with a shell script because tackling the tool would be too complex or time-consuming.
I nearly choked. Perhaps in the 1980s when you could hire people with shell minutiae memorized, this was a good strategy. These days, I would be wrapping the executable for the job (purposefully in an unspecified language to facilitate broader use and survivability of the design) in a layer that makes its environment temporary and OS-level sandboxed (to stave off security challenges), and completely explicit (to nip the clasically vast number of undocumented dependencies in the bud). Ideally, versioning of such environments and their builds would be supported. That's exactly cims.
The second point is correct; it's deterministic in the sense that the ordering is always the same, and as much as Dockerfile are (they're also regularly described as deterministic). I should probably clarify that somewhere.
Obviously this limits you to unix first up, a fairly serious limitation.
Second, it's full hard to catch, security-related bugs, particularly if you attempt to make it portable across disparate unices.
Third, its significant and inexplicit dependencies to achieve pretty much anything (downloading and unpacking files, diffs, accurate snapshots, nontrivial analysis, whatever) remain technical debt and a pain in the ass both in the sense of achieving basic functionality and long term stability.
Finally, because the rest of the world has moved on from shell scripts for all nontrivial tasks for well known reasons (right tool for the job), you will find hiring anyone to manage that really hard.
However, yes, they have their place and your point is valid. For unix-like platforms cims goes one level higher than shell scripts and demands an executable that returns an appropriate exit value and emits issues to stderr when executed on the specific build platform, which may be a group of OSs ('unix'), a specific distro ('arch'), a specific version of a specific distro ('gentoo-my2015febbuild') or even a specific version of a specific distro with a specific config. You could therefore write in any language available within the environment, with the appropriate portability penalty. The environments are defined by: you guessed it, executable tests in the same spirit. This means that being as specific as required or felt appropriate ("optimistic portability" with shell scripts, for example) is allowed, while being completely repeatable once a functional platform version and service build process match is achieved (for services targeting inexplicit platforms like 'unix'). Capiche?