4 ms·

Deploying across multiple clouds. This abstracts away virtually all of the details. All you have to worry about is that your containers run on Docker, and as l

Deploying across multiple clouds. This abstracts away virtually all of the details. All you have to worry about is that your containers run on Docker, and as long as your provider is supported by Machine, nothing else matters, and your code isn't polluted by anything provider-specific.

dkarapetyan 12y ago
In theory. I still have to see a cross-cloud solution that just works.
- contingencies 12y ago
  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 http://tools.ietf.org/rfc/rfc1925.txt [2] cims ... read on from http://stani.sh/walter/pfcts/ http://stani.sh/walter/pfcts/ via 'original post'
  - peterwwillis 12y ago
    > 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.
    - dkarapetyan 12y ago
      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.
      - zwischenzug 12y ago
        I agree, which is why I wrote this :) http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/
        contingencies 12y ago
        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.
        zwischenzug 12y ago
        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.
      - peterwwillis 12y ago
        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.
- ehazlett 12y ago
  Here's a quick screencast showing the multi-cloud swarm. https://asciinema.org/a/17067 https://asciinema.org/a/17067
  - contingencies 12y ago
    Where its grandparent post said "This abstracts away virtually all of the details" the screencast says otherwise.

dkarapetyan 12y ago

In theory. I still have to see a cross-cloud solution that just works.

contingencies 12y ago
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 http://tools.ietf.org/rfc/rfc1925.txt [2] cims ... read on from http://stani.sh/walter/pfcts/ http://stani.sh/walter/pfcts/ via 'original post'
- peterwwillis 12y ago
  > 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.
  - dkarapetyan 12y ago
    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.
    - zwischenzug 12y ago
      I agree, which is why I wrote this :) http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/
      - contingencies 12y ago
        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.
        zwischenzug 12y ago
        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.
    - peterwwillis 12y ago
      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.
ehazlett 12y ago
Here's a quick screencast showing the multi-cloud swarm. https://asciinema.org/a/17067 https://asciinema.org/a/17067
- contingencies 12y ago
  Where its grandparent post said "This abstracts away virtually all of the details" the screencast says otherwise.