4 ms·

Container Clusters on VMs

31 points by rey12rey 12y ago

akhilcacharya 12y ago
I feel like I'm entering buzzword land.
- contingencies 12y ago
  Similarly, I was just wondering how the nth virtualized infrastructure provider - regardless of their identity - can make their stuff sound like its novel in the slightest. You have to admit they're good at that, even though it's mostly bullshit. TLDR; Reducing Deployment Risk = distribute complete container images.[1] Modular App Components = run your services on a cluster you control[2] on our infrastructure Modular App Components = we don't trust container security either.[3] Shared Resources and Forecasting = cgroups[4] Conclusion = we wrapped containers. now you can pay us money.[5] Notes... [1] You are now distributing larger pieces. Sending the pieces to a new infrastructure provider just became significantly more difficult to impossible, since there is no container format standard between providers - ie. Google just achieved lockin. The pieces you distribute are processor architecture specific and no longer optimized for the deployment environment. [2] Why they can't offer the cluster functionality themselves between containers is beyond me. I can only assume they want to make more money by having people run more simultaneous instances on their infrastructure, and also achieve cognitive lockin to their platform from a marketing standpoint. [3] What? You mean Google doesn't guarantee isolation between containers running on their infrastructure? What does that mean? Are your containers co-hosted with other clients'? What does this mean from a security standpoint? [4] From the 'Teach a person to fish' department: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt [5] Maybe I want to run containers myself, on another provider? Maybe I want to do both? Or maybe I just want a tool that finally renders these 10,000 infrastructure providers a commodified industry and allows me actual freedom to move, without trusting in any single partner? Oh wait, that makes no commercial sense for these entities, who are just trying to get me to pay them money on a subscription basis...
  - sciurus 12y ago
    1. Google Container Engine runs Docker containers, the same as other providers like AWS EC2 Container Service and Joyent Compute Service. 2. I don't understand what you mean. 3. You run your containers on virtual machines dedicated to you, so you rely on the hypervisor for security. 4. Cgroups is one of the technologies that linux containers are built on. What is your point? 5. Google is building their container service on docker and kubernetes [0]. Both of these are open source, already adapted by multiple providers, and possible for you to run yourself. [0] http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html http://googlecloudplatform.blogspot.com/2015/01/everything-y...
    - contingencies 12y ago
      1. Yeah. Which is a tangent to the point that they spent a paragraph talking up the nominal benefits of distributing an entire container without facing either the reality that there is no standardized format (yes, really, look it up) or the necessary loss of binary portability. So yeah, marketing drivel .. all benefits, no frank discussion of drawbacks. 2. From the article, it seems like they are encouraging people to build their own cluster atop their platform rather than using a packaged cluster service. 3. OK. So allegedly two layers here. That's a lot better than one, though it makes you wonder how they schedule client slash client cgroup association across physical hardware (ie. VMs). 4. That's just a paragraph of fluff around cgroups, was my point. 5. The fact is you can't migrate easily between arbitrary providers because nothing offers you that level of abstraction.

31 points by rey12rey 12y ago

akhilcacharya 12y ago

I feel like I'm entering buzzword land.

contingencies 12y ago
Similarly, I was just wondering how the nth virtualized infrastructure provider - regardless of their identity - can make their stuff sound like its novel in the slightest. You have to admit they're good at that, even though it's mostly bullshit. TLDR; Reducing Deployment Risk = distribute complete container images.[1] Modular App Components = run your services on a cluster you control[2] on our infrastructure Modular App Components = we don't trust container security either.[3] Shared Resources and Forecasting = cgroups[4] Conclusion = we wrapped containers. now you can pay us money.[5] Notes... [1] You are now distributing larger pieces. Sending the pieces to a new infrastructure provider just became significantly more difficult to impossible, since there is no container format standard between providers - ie. Google just achieved lockin. The pieces you distribute are processor architecture specific and no longer optimized for the deployment environment. [2] Why they can't offer the cluster functionality themselves between containers is beyond me. I can only assume they want to make more money by having people run more simultaneous instances on their infrastructure, and also achieve cognitive lockin to their platform from a marketing standpoint. [3] What? You mean Google doesn't guarantee isolation between containers running on their infrastructure? What does that mean? Are your containers co-hosted with other clients'? What does this mean from a security standpoint? [4] From the 'Teach a person to fish' department: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt [5] Maybe I want to run containers myself, on another provider? Maybe I want to do both? Or maybe I just want a tool that finally renders these 10,000 infrastructure providers a commodified industry and allows me actual freedom to move, without trusting in any single partner? Oh wait, that makes no commercial sense for these entities, who are just trying to get me to pay them money on a subscription basis...
- sciurus 12y ago
  1. Google Container Engine runs Docker containers, the same as other providers like AWS EC2 Container Service and Joyent Compute Service. 2. I don't understand what you mean. 3. You run your containers on virtual machines dedicated to you, so you rely on the hypervisor for security. 4. Cgroups is one of the technologies that linux containers are built on. What is your point? 5. Google is building their container service on docker and kubernetes [0]. Both of these are open source, already adapted by multiple providers, and possible for you to run yourself. [0] http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html http://googlecloudplatform.blogspot.com/2015/01/everything-y...
  - contingencies 12y ago
    1. Yeah. Which is a tangent to the point that they spent a paragraph talking up the nominal benefits of distributing an entire container without facing either the reality that there is no standardized format (yes, really, look it up) or the necessary loss of binary portability. So yeah, marketing drivel .. all benefits, no frank discussion of drawbacks. 2. From the article, it seems like they are encouraging people to build their own cluster atop their platform rather than using a packaged cluster service. 3. OK. So allegedly two layers here. That's a lot better than one, though it makes you wonder how they schedule client slash client cgroup association across physical hardware (ie. VMs). 4. That's just a paragraph of fluff around cgroups, was my point. 5. The fact is you can't migrate easily between arbitrary providers because nothing offers you that level of abstraction.