Hi,
With the renaming of Chef to Chef Infra, which I assume is a push to move all application deployment to Habitat, I'm being asked to reassess Chef's usage within our organisation.
For our scope its currently being used on Windows Server to template configs, deploy complex vendor application and ensure correct configuration management each run. We use core application cookbooks with wrapper environmental settings and Jenkins to orchestrate.
Essentially most DevOps tooling guides or diagrams now only show Chef in the Infra-as-code section (now reinforced with the naming to Chef Infra). What are other people's view on using Chef long term for this type of requirement, as a lot of effort has gone into coding our releases, but as technology progresses I also don't want to stick with our status-quo if its no longer best practice?
Thanks
1 Like
Its more of just a marketing thing since they are selling all their products as a complete automation stack and have always billed habitat as application automation they just renamed chef to chef infra for marketing purposes. They wouldn't remove any functionality you currently use for installing applications because its core functionality to chef infra. They just wanted to have a way to label the different parts of their stack I wouldn't worry about it.
Dave,
The change in naming convention for our Chef products is to clarify what we feel is the best use for each of our core products. Chef Infra for infrastructure-as-code, Chef InSpec for compliance-as-code, and Chef Habitat for application automation. LarryC is right that marketing is part of the reason, as you pointed out Chef has been viewed and only placed in the infrastructure-as-code section of most tooling diagrams. It is our intent to align public perception with our assertion that is that Chef Habitat is the best method of packaging, deploying, and maintaining applications. That doesn't mean that you can't use Chef Infra to deploy and configure an application; it just means that we have a better tool that focuses on packaging the application code with its dependencies into an immutable artifact that allows you the power to deploy it to almost anywhere. Add to that the ability to automatically manage dependencies and transitive dependencies and you have a very useful framework for modernizing applications and their lifecycle.
I understand that you have complex applications that are deployed and configured with Chef cookbooks. I think that if you dig deeper into the pattern of using cookbooks to define the underlying infra and Habitat to package and deploy the app, you will find it is less painful than using cookbooks for everything. I hope you will find Habitat's use of app lifecycle hooks and ability to orchestrate a real advantage over the traditional Chef way to manage apps.
If you are considering Habitat, I would encourage you to take advantage of our recorded Webinars and the free learning content at https://Learn.Chef.io and get your hands on the keyboard and explore the possibilities provided by Habitat.
Thanks for your use of Chef and I hope that this helps you understand our new direction a little better.