Comment by contingencies | Hacker News Reader

Comment by contingencies | Hacker News Reader

Parent Full thread

Explicit infrastructure is that which is completely specified and instantiated and ahead of use. This would include resource allocation and security policy for computational, storage and networking infrastructure. Building infrastructure in the pre-cloud/pre-virt era generally necessitated this approach.

Implicit infrastructure is constructed reactively, over time, in response to evolving stimuli but also based upon dependencies or requirements specified or assumed. For instance, today this occurs in automated scale-out on some cloud systems. The author describes a conceptually similar (from the infrastructure specification and management standpoint) mode of operation here by suggesting the creation of new nodes in response to socket opens (networking events) on individual containers.

Ultimately, in the latter case you are giving up some degree of control and known state in favour of flexibility. This makes sense for some scenarios, but greatly complicates things in others. Both are valid but the viable domain of the latter is more limited.

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.

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.

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.

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.

I understand, that sounds very close to what I've been working on, a functionally reactive infrastructure that is configured with constraint based logic DSL that starts from QoS constraints. The QoS constraints allows one to specify goals, and allow infrastructure to be built up implicitly.

I've read some of the stuff on your website, it's very closely aligned to what I'm working on. We should talk in more detail.

Sure thing, send me an email.

Reply on news.ycombinator.com