Skip to content

Instantly share code, notes, and snippets.

@brainsik
Last active March 5, 2021 22:14
Show Gist options
  • Save brainsik/c405908c4714e582ed42e897c42678c9 to your computer and use it in GitHub Desktop.
Save brainsik/c405908c4714e582ed42e897c42678c9 to your computer and use it in GitHub Desktop.
Minimalist Infrastructure

Minimalism

Minimalist infrastructure is the practice of building only what you need with the fewest number of resources. This is a philosophy, not a religion, you shouldn't build bad infrastructure to achieve a minimalist design. A minimalist design should lead to good infrastructure by reducing the amount of resources under management and the complexity of the design.

Avoid state

When designing your system, avoid storing additional state. Often the data you want to store is already available in the system. Using the system as the source of truth can avoid the difficult business of ensuring data consistency.

As an example, let's say you want to be able to rollback a Fargate deploy if the new task definition results in a service that won't become healthy. One option would be store the working task definition in something like DynamoDB (or git or any number of bad choices). However, your ECS service already has this information: the previous, healthy service is still running. Instead of managing a DynamoDB resource as well as writing code for maintaining that state record, query the ECS service itself to get what you want. This avoids managing the DynamoDB resource as well as the unfortunate scenario where the data stored is wrong.

Use managed services

Manage only what you must. There are lot of services out there that solve infrastructure problems for us. For example, AWS Fargate makes it so you don't have to manage EC2 instances running your containers. This is good. Make managing infrastructure someone else's problem (you've got plenty). Build and maintain the least amount possible.

Examples:

  • Parameter Store instead of Hashicorp Vault
  • Fargate instead of EC2
  • Managed versus self-hosted

Use modules

Codify entire stacks into a single module (calling into other modules). Keep the number of parameterizations (inputs) small so the infrastructure doesn't vary wildly and the module's actions remain clear. This makes it easy to spin up the same infrastructure in multiple environments and reduces the proliferation of code unique to each environment.

@brainsik
Copy link
Author

brainsik commented Mar 5, 2021

There is now a full philosophy piece here:
https://github.com/trussworks/good-infra/blob/master/philosophy.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment