4 ms·

FWIW I agree that reactive infrastructure is fairly limited in scope. The traditional model of infrastructure is everything running in a single server. If your

FWIW I agree that reactive infrastructure is fairly limited in scope. The traditional model of infrastructure is everything running in a single server. If your unit of deployment is a vm, then orchestration, service discovery, security policy must be done within the vm image or via a configuration management system. If your unit of deployment is a container, then these pieces can be done outside of the container system. A standard interface for the way the container communicates with the outside world allows these systems to be shared and reused and perhaps one day standardized.

contingencies 12y ago
I agree there's a move towards reuse. I disagree there's any fundamental difference between hypervisor-hosted VMs and containers as far as infrastructure, connectivity, configuration management, monitoring and all the rest goes. I also disagree this is a meaningful step forward for a general use case due to paradigm quirks, but I applaud the exploration.
- vishvananda 12y ago
  Vms and containers are roughly interchangable, yes, but I would argue that the tendency for vms to be treated as whole servers leads deployers to pack all of the solutions to the above problems into the vm building block. In the end there is a tightly-coupled virtual appliance and it is difficult to reuse the useful pieces. We missed the opportunity to separate these concerns and have meaningful and reusable pieces. Containers are giving us another opportunity to revisit these choices. I'm hoping we don't miss the opportunity again. I think this is a key point to bring to light, because most of the hype around using containers seems to focus on the fact that you can replace the hypervisor layer with a container manager (docker) and achieve a ton of benefit. For most use cases there isn't a significant enough difference to matter. Changing the paradigm for how applications are built and deployed is the key innovation that docker is offering us, but as you point out, there are still plenty of problems to solve in this area.
  - contingencies 12y ago
    I agree that people are lazier at embracing change when building with VMs... then again, they might be a different audience, too. I also agree with the rest of your post.

contingencies 12y ago

I agree there's a move towards reuse. I disagree there's any fundamental difference between hypervisor-hosted VMs and containers as far as infrastructure, connectivity, configuration management, monitoring and all the rest goes. I also disagree this is a meaningful step forward for a general use case due to paradigm quirks, but I applaud the exploration.

vishvananda 12y ago
Vms and containers are roughly interchangable, yes, but I would argue that the tendency for vms to be treated as whole servers leads deployers to pack all of the solutions to the above problems into the vm building block. In the end there is a tightly-coupled virtual appliance and it is difficult to reuse the useful pieces. We missed the opportunity to separate these concerns and have meaningful and reusable pieces. Containers are giving us another opportunity to revisit these choices. I'm hoping we don't miss the opportunity again. I think this is a key point to bring to light, because most of the hype around using containers seems to focus on the fact that you can replace the hypervisor layer with a container manager (docker) and achieve a ton of benefit. For most use cases there isn't a significant enough difference to matter. Changing the paradigm for how applications are built and deployed is the key innovation that docker is offering us, but as you point out, there are still plenty of problems to solve in this area.
- contingencies 12y ago
  I agree that people are lazier at embracing change when building with VMs... then again, they might be a different audience, too. I also agree with the rest of your post.