Design and main principals¶

Immutable server infrastructure for stateless applications¶

Stateless applications in aws should follow immutable infrastructure paradigm in which servers are never modified after they're deployed. If something needs to be updated, fixed, or modified in any way, new servers built from a common image with the appropriate changes are provisioned to replace the old ones. After they're validated, they're put into use and the old ones are decommissioned.

The benefits of an immutable infrastructure include more consistency and reliability in your infrastructure and a simpler, more predictable deployment process. It mitigates or entirely prevents issues that are common in mutable infrastructures, like configuration drift and snowflake servers. However, using it efficiently often includes comprehensive deployment automation, fast server provisioning in a cloud computing environment, and solutions for handling stateful or ephemeral data like logs.

For preparing AWS AMI images we are using Hashicorp packer tool. As a provisioner to install and configure needed software inside image we use chef configuration management tool.

In a classic way chef is used with chef server which propagates changes, described in chef code, to its clients, servers, online. This approach is good when you are working with a traditional mutable server infrastructure, servers are continually updated and modified in place. Good example for such infrastructure could be such stateful systems like mysql data bases, kafka clusters, Cassandra etc.

To make chef code suitable for immutable infrastructure we are combining it with packer as provisioner. Instead of chef server we use chef local mode or chef-zero. To maintain versions of chef code we use chef policyfiles.

Mutable cloud server infrastructure for stateful applications¶

TBD