anchor.diff:    - [Habitat and Provisioning Tools](#habitat-and-provisioning)
     - [Habitat and Containers](#habitat-and-containers)
     - [Habitat and Container Orchestration](#habitat-and-orchestration)
  -  - [Habitat and Continous Integration](#habitat-and-continuous-integration)
  +  - [Habitat and Continuous Integration](#habitat-and-continuous-integration)
     - [Habitat and Configuration Management](#habitat-and-configuration-management)
   
   ## <a name="habitat-and-provisioning" id="habitat-and-provisioning" data-magellan-target="habitat-and-provisioning">Habitat and Provisioning Tools</a>
  
positive.code: 
  Habitat builds more secure containers by exporting your application and any of its runtime dependencies directly into the container. When you build your application with Habitat, your application takes ownership of the entire toolchain of its runtime dependencies. As a result, you no longer have to rely on a large operating system and unnecessary system libraries. This enables you to include only the binaries your application uses inside your container, which can decrease your container size. By eliminating the need for a large operating system, you also avoid including binaries that an attacker could use, which further increases the security of your container. Visit the [Running Habitat Containers](https://www.habitat.sh/docs/best-practices/#running-habitat-linux-containers) section of the docs to find more details about how containers are built with Habitat. Finally, [Habitat's HTTP API](https://www.habitat.sh/docs/using-habitat/#monitor-services) allows all of your application's runtime dependencies to be audited at any time. If a brand new vulnerability is revealed, [Habitat's HTTP API](https://www.habitat.sh/docs/using-habitat/#monitor-services) makes it easy to programmatically inspect and audit the entire toolchain of your runtime environment without needing to worry about how your containers got built in the first place.
  
  If your situation requires it, Habitat makes it simple to switch from containerized to non-containerized workloads. This is because Habitat packages only have a requirement on the kernel version of your operating system. (Linux: kernel 2.6.32 or later, Windows: Windows Server 2008 R2 or later and Windows 7 or later). You can take the same .hart file you use to export to a docker container and run it on a virtual machine or bare metal. By only requiring the kernel, Habitat gives you the ability to switch container formats or to switch to non-containerized workloads without significant rework.
  
  ## <a name="habitat-and-orchestration" id="habitat-and-orchestration" data-magellan-target="habitat-and-orchestration">Habitat and Container Orchestration</a>
  #### Examples: [Kubernetes](https://kubernetes.io/)
  
negative.code: 
  Continuous integration allows you to build, test, and deploy your code by using CLI tools and plugins. Habitat includes the [Habitat Studio](https://www.habitat.sh/docs/developing-packages/#plan-builds) which allows you to do interactive builds on your developer workstation, or non-interactive builds with your continuous integration server. Your continuous integration server can also call the Habitat CLI to promote your Habitat packages to different channels, enabling your applications to update themselves. Habitat is not a continuous integration server and can make builds and promotion processes done by your continuous integration server easier.
  
  The [Habitat Studio](https://www.habitat.sh/docs/developing-packages/#plan-builds) provides a clean room build environment for your application build. In effect, builds that occur on a developer's workstation, or on a continuous integration server, will build in the same manner. Developers no longer need to worry about entire classes of "it works on my box" problems. Build engineers no longer need to create unique and difficult to maintain worker nodes for continuous integration servers. Instead, the Habitat plan.sh file contains all the information needed to build the entire application, from dependency management, runtime environment binaries, packaging, and application lifecycle hooks. When using the [Habitat Studio](https://www.habitat.sh/docs/developing-packages/#plan-builds), your continuous integration server can focus more on what it is good at doing, instead of worrying about managing custom plugins and their potential conflicts.
  
  Your continuous integration server can promote a Habitat package (a .hart file) to a channel by calling the [Habitat CLI](https://www.habitat.sh/docs/install-habitat/#install-habitat). This promotion method allows you to deploy a new version of your application in a pull-based manner by using the Habitat Supervisor. Because this promotion process can be invoked non-interactively through the [Habitat CLI](https://www.habitat.sh/docs/install-habitat/#install-habitat), you can manage your deployments using your existing tooling. If you choose, you can also do this promotion process manually. More complex application environments can also invoke the promotion process using a scheduling tool or provisioning tool to help manage infrastructure resources in addition to promoting Habitat packages.
  
  ## <a name="habitat-and-configuration-management" id="habitat-and-configuration-management" data-magellan-target="habitat-and-configuration-management">Habitat and Configuration Management</a>
  #### Examples: [Ansible](https://www.ansible.com/), [Chef](https://www.chef.io/chef/), [Puppet](https://puppet.com/), and [Salt](https://saltstack.com/)
  
  Configuration management tools allow you write configuration files, using a declarative language to manage a server. These tools focus on building working servers by installing and configurating system settings, system libraries, and application libraries before an application is installed on the server. Habitat focuses on the application first instead of the server. Habitat builds and packages your application's entire binary toolchain, including the system libraries, application libraries, and runtime dependencies necessary for your application to function. As a result, Habitat can replace many use-cases that configuration management tools perform related to installing system binaries, application dependent libraries, or templating configuration files. 
  
  Configuration management tools perform tasks at run time by converging resources. The value from configuration management tools comes from this converging process -- checking the existing state of a server, and fixing it if it does not match the intended state. Because converging modifies resources at runtime, it can result in surprising and complex runtime errors. In addition, since environments are often mutable and unique, maintaining server automation occurs out-of-band with application development, creating conflict between application developers and software reliability engineers. Habitat avoids these classes of errors entirely by shifting these processes to build time, and by creating an atomic package of an application's binaries, application lifecycle hooks, and configuration files. Habitat's approach to packaging automation with the application package allows application developers and software reliability engineers to work closer together.
  
  