📄️ Infrastructure Layering
In general, we've found the following practice of managing infrastructure in layers to work quite well. Many of our initial approaches to infrastructure management involved placing the entire configuration in a single layer, so that the network, data, and application were all deployed together. While it was convenient to have a single entrypoint for the entire application deployment (such as a single terraform apply), this approach exhibited a number of drawbacks, including:
📄️ Configuration and Code
In general, we should prefer to store our environment configurations and application deployment definitions separately from our application source code. The following is a discussion of some of the (anti-)patterns that you might consider, and their pros and cons. It is important to note that these are not one size fits all solutions, and that you may select a different methodology if it suits your application.
📄️ Managed Services
use managed services whenever possible, prefer services that use standard formats as inputs, like docker images, and open source components like database engines to avoid lock-in.
📄️ Cloud project organization
Separation of environments
📄️ Terraform Modules
Basic Philosophy