Chef Automation vs Habitat

Habitat Help
#1

I apologize if this is the wrong area to ask, but what happens to Chef? Does Habitat handle those functions?

IE, we use Chef to add OS level automation (log rotations, splunk integrations, Nagios, Grafana). We still need to know when memory overruns, when kernels crash, ship logs, etc. Or in some cases install things like Cassandra in a raw VM or physical host. Are you abandoning the Chef infrastructure for this? Does this handle OS level automation? I don’t understand if this is an additional product or a replacement one?

#2

tl;dr: Chef and Habitat solve two different problems. Chef handles infrastructure complexity. Habitat runs apps smoothly on that infrastructure.

Chef is a proven automation framework for modeling infrastructure complexity. Chef shines in infrastructure automation use cases that require flexibility, scalability, and extensibility. Chef is good at solving the complex problems you face when developing in an infrastructure-first approach.

Habitat is different. Habitat aims to introduce a forward-thinking application-first approach that defers decisions about infrastructure complexity. “Application-first” means that Habitat enables an appdev model where infrastructure decisions can be made at runtime. But that underlying infrastructure still needs to be configured. Compliance on that infrastructure is still a real concern. We believe that Habitat enables a more delightful app dev experience than what other tools provide today. Chef is still useful for managing infrastructure as code. Inspec is still useful for managing compliance policy as code. Those tools continue to solve the problems for which they were created to solve. We encourage you to try Habitat for application management to see if its app-first approach is right for you.

5 Likes
#3

This quetion will be brought up over and over again by Chef users. Thank you for clarifying the approach Habitat is trying to take. It’s been two years since I’ve known of Habitat, Chef continues to push for it as a way to deploy applications. I can see use cases when it comes to Containers, but I can easily deploy applications using Chef also. Maybe not in the way Habitat is approaching the problem, but I’m yet to find an appication that couldn’t be deployed with Chef, ok, maybe Symantec DLP but Symantec as a whole is an exception.
Anyway. I see plenty of overlap and added complexity to bring Habitat to an environment already running Chef. The learning curve/training and shift in the mindset of how to deploy applications creates more uncertainty and Habitat has almost become a “hype” word in the world of Chef users, with some people just throwing the H word to sound smart of forward thinking, instead of asking themselves what problems are they trying to solve.
Anyway, just my two cents here.

#5

I think there’s a couple important (if not nuanced) distinctions to be made between these two tools though I do think that @metadave did an excellent job of covering the differences above. As a person who has used Chef for 6+ years and now (full transparency) works on the Habitat team I have a slightly different context to share. I also tend to ramble so hopefully the following is useful and not totally incomprehensible :slight_smile:

Can you deploy applications with Chef? Totally, most definitely and IF you’ve actually got a reasonable CI/CD system for your applications with Chef then that’s wonderful. You’ve got to use what works for you. Now, if you’re an individual who has had to build a system like that from scratch and maintain it long term, then you’ve very likely cut yourself more than once on the challenges and deficits of using Chef in this manner. The reason being: Chef wasn’t really designed as an application lifecycle management tool. From the ground up it was pretty much targeted and planned as configuration management and infrastructure automation. What we’ve learned over the years is that Chef can do a whole lot of things but really it doesn’t excel at the application side of things. In fact that’s where nearly all of its gnarly monsters are lying in wait!

WRT added complexity - I sort of agree but I also disagree. Compared to similar patterns and workflows I’ve used with Chef in the past - e.g. the immutable + service discovery pattern - It doesn’t add anywhere near the same amount of complexity. IMPO it doesn’t even add near the complexity or brittleness of a home-rolled CI/CD system that only leverages Chef + Chef Server. I’d take that statement one step further and say it sharply decreases complexity in application lifecycle management/automation as well as CI/CD systems by outright obviating a need for as many moving parts. Not to mention minimized complexity in the form of literally shrinking the raw lines of code or rube-goldberg systems required for a Chef cookbook to deploy/manage some applications in a sane way. Especially when we’re talking about things in the context of modern application programming paradigms like the microservices approach.

All of this in mind. Chef is still a great tool, and people should definitely continue to use it. Learning new tools can be really hard and adopting tools that are pre-1.0 can definitely be a risk. The real question at hand though is - “does Habitat add value to most Chef workflows and environments out there today”? To which I think the answer is a resounding - Yes. But, almost as importantly, we (and myself in this as a practitioner) believe it also adds value to environments that use Ansible, Puppet, and Kubernetes too! Hopefully this is helpful context. When it’s all said and done I am wholly in agreement with you on the necessity for people to understand their problems thoroughly so that they can choose the right tool for the job and in my own opinion separate from being a Chef engineer, I would choose Habitat to manage my applications over Chef 100% of the time.

4 Likes
#6

Thank you, I completely agree with your statements.

1 Like
#7

@eeyun, you hit a nail on why Habitat is great when you are starting to develop apps especially when there is no build ecosystem. I didn’t have to spend time building up a Jenkins cluster just so I could build my app and deploy it somewhere. I also didn’t have to spend time to code out a recipe/playbook for a custom linux host ensuring the dependencies would be there when I run my app.

80% of the time I was focused on making my application better and when I’m ready for production, I knew that Habitat would be there to get me to 100%.

If I wasn’t so focused on developing apps and more on just maintaining infrastructure, I would use Chef. But then again, there are more and more services that are getting habitatized…

1 Like