Comment by contingencies | Hacker News Reader

Comment by contingencies | Hacker News Reader

Parent Full thread

To expand on this comment, common issues may include...

(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'

> I am still working on an OS and virtualization platform agnostic alternative devops process management tool

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.

Shell scripts are pretty nice and it's unfortunate that the new crop of configuration management tools puts them on the sidelines instead of treating them as first class citizens in the configuration pipeline.

Now the much harder problem of orchestration is still an unsolved problem and I think that is what the author was referring to.

IMHO you can't make an orchestration product that a devops person will like. The only people i've met who appreciate pre-built, non-customized orchestration tools are people who can't program.

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.

Maybe you're right. I've fallen into the trap of re-inventing orchestration but the layer on top of shell scripts as always been tiny (200 or so lines of Ruby or Python). At some point you want some kind of self-healing and monitoring infrastructure and managing all that with shell scripts I'm sure is possible but I wouldn't want to be the one to do it.

fail-closed or fail-safe shell scripts

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.

I agree, which is why I wrote this :)

http://ianmiell.github.io/shutit/

This is docker-specific, obviously. Also, AFAICT it's not really 'deterministic builds' despite claims to the contrary since the network is allowed as input.

The first point is technically untrue - it works over ssh or plain bash also.

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.

This is one of several reasons why I wrote Overcast[1]. I don't want to learn a DSL, I'd rather simplify the process of running shell scripts on multiple machines.

[1] http://andrewchilds.github.io/overcast/

Cool project. Are you continuing to develop it?

Thanks, yes it's still in development, mostly just adding more providers and recipes at this point. I'd love to add Docker as a provider but I had questions around implementation (https://github.com/andrewchilds/overcast/issues/18), so maybe Docker Machine will be a better alternative, or something I can require as a dependency.

> shell scripts

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?

Reply on news.ycombinator.com