// Module included in the following assemblies:
//
// * applications/deployments/what-deployments-are.adoc

:_mod-docs-content-type: CONCEPT
[id="deployments-comparing-deploymentconfigs_{context}"]
= Comparing Deployment and DeploymentConfig objects

Both Kubernetes `Deployment` objects and {product-title}-provided `DeploymentConfig` objects are supported in {product-title}; however, it is recommended to use `Deployment` objects unless you need a specific feature or behavior provided by `DeploymentConfig` objects.

The following sections go into more detail on the differences between the two object types to further help you decide which type to use.

include::snippets/deployment-config-deprecated.adoc[]

[id="deployments-design_{context}"]
== Design

One important difference between `Deployment` and `DeploymentConfig` objects is the properties of the link:https://en.wikipedia.org/wiki/CAP_theorem[CAP theorem] that each design has chosen for the rollout process. `DeploymentConfig` objects  prefer consistency, whereas `Deployments` objects take availability over consistency.

For `DeploymentConfig` objects, if a node running a deployer pod goes down, it will not get replaced. The process waits until the node comes back online or is manually deleted. Manually deleting the node also deletes the corresponding pod. This means that you can not delete the pod to unstick the rollout, as the kubelet is responsible for deleting the associated pod.

However, deployment rollouts are driven from a controller manager. The controller manager runs in high availability mode on masters and uses leader election algorithms to value availability over consistency. During a failure it is possible for other masters to act on the same deployment at the same time, but this issue will be reconciled shortly after the failure occurs.
