Habitat — A new approach to automation

I'm not sure what I'm looking at. What is being "automated" here? The headline and home page don't give much context.

Found this elsewhere, interesting to note, Habitat looks to be built mostly with Rust

https://github.com/habitat-sh/habitat

I've been waiting for this announcement for a few weeks. Since the home page is quite lean on an actual explanation, let me give a rough summary of interesting points as i understand it. I apologize in advance if I have anything wrong.

1. It is a from-scratch source build system written in rust that borrows a huge amount from nix. This means repeatable software builds with isolated dependencies.

2. It attempts to move some configuration management primitives into the build pipeline so that the deployment config has enough flexibility for real-world use.

3. It intends to replace single host process supervision with a distributed model based on gossip.

This project is most definitely ambitious, and I'm not sure the whole goal is realizable but some aspects are particularly interesting.

1. The build process seems quite useful for building containers, especially if it gets some traction. The main drawback of nix is that no one knows how to use it. If this gets the backing of the hordes of chef-aware system administrators, we may have a good solution for isolated repeatable builds, especially if they focus on deterministic reproducible builds[1] as well.

2. Distributed systems are notoriously hard to configure in a general way. It seems like every company has their own magic combination of config management, monitoring, and scripting for keeping systems like zookeeper running. Its pretty clear that we don't have the right primitives for sharing this work. I don't think a container management system has the right primiteves for this either, because I don't think you can solve for all distributed systems in a generic way. You really need custom logic for the particular software you are trying to distribute. I'm not convinced that a gossip-based process-supervisor is the best approach for this, but it could give us a place to start collaborating on these primitives.

[1] https://wiki.debian.org/ReproducibleBuilds

Hmm, I very much like the concept but when I see the need for supervisors and a habitat service, it makes me wonder if this is really what is says it is.

If I need to pre-install all these services on my hosts before any of this will work, then how is that really different from uniformly deploying all my applications on an application server such as WebSphere? An EAR too contains all my configuration data, my bindings, my security settings etc. So...if you uniformly run WebSphere everywhere in your enterprise, it sort of accomplishers the same thing.

HOWEVER, if the habitat configuration is capable of talking to my F5 load balancer to create a resource pool, self register my app with my corporate DNS, create a DB schema and populate it with my tables, talk to my networking equipment and open all relevant firewall ports and do so when the application is deployed to a new environment, as well as undo all these actions if it's ever moved elsewhere, then you have piqued my interest...

Ah, another limiting abstraction layer to learn and to fight.

Bash is plenty good.