Immutable Infrastructure

Development and Production Workstation & Servers

Immutable infrastructure is an approach to managing services and software deployments on IT resources wherein components are replaced rather than changed. An application or services is effectively redeployed each time any change occurs.

Security Features:

Immutable Linux Operating System(s)

Read-Only systems. Tamper-resistant and hardened against corruption.

Atomic upgrades.

Live Migration & Snapshots.

Critical Application(s) Sandboxing.

In a traditional software deployment, an application or service update requires that a component is changed in production, while the complete service or application remains operational. Immutable infrastructure instead relies on instancing, where components are assembled on computing resources to form the service or application. Once the service or application is iterated, its components are set -- thus, the service or application is immutable, unable to change. When a change is made to one or more components of a service or application, a new iteration is assembled, tested, validated and made available for use. Then the old iteration is discontinued to free the computing resources within the environment for other tasks.

Immutability restricts the potential for configuration drift, reducing the IT infrastructure's vulnerability to attack. Uptime is improved in unexpected events, because instances are redeployed instead of restored from multiple unique configurations and versions.

A deployment iteration typically results in the build of a common image that can be tested and proven. Cloud computing environments provide the automation required to construct and deploy images for immutable operations.

Immutable infrastructure benefits include lower IT complexity and failures, improved security and easier troubleshooting than on mutable infrastructure. It eliminates server patching and configuration changes, because each update to the service or application workload initiates a new, tested and up-to-date instance. There is no need to track changes. If the new instance does not meet expectations, it is simple to roll back to the prior known-good instance. Since you’re not working with individual components within the environment, there are far fewer chances for unpredictable behaviors or unintended consequences of code changes.