Infrastructure Design

Think Reusability

Blueprint Reuse

You should think of Blueprints as building blocks. Always think, "what changes can I make to this to make it more reusable?". It may make sense to variabilize some object definitions, but where this is not possible, it may make more sense to just break the blueprint in to several smaller blueprints. At least some components are then reusable.

A blueprint can be used in multiple environments. If the blueprint has decision points expressed as variables, the way each environment uses a blueprint could be quite different:

Potential Infrastructure for HungryCorp (not real, but the food is!)

HungryCorp might have started out just selling pizza. They may have acquired a Mac and Cheese company. These sites grew up separate, and they have different requirements. You can express the commonalities and differences in blueprints and pull them into environments to provision real working infrastructure for both.

At some point in the future you want to start aligning them to one common infrastructure. Over a long game of Rock, Paper, Scissors, Lizard, Spock, it is decided that the newer MacAndCheese architecture is better. You can set up a development environment that allows myPizzaService to transition over to the MacAndCheese backend:

Development Environment for Consolidation

In this development environment, there is an independent mongodb, redis, and application servers. Variables would control the scale of the development deployment so that is was not as expensive as the production site. Developers would be able to consolidate. This is obviously a vastly simplified example of the amount of effort it would require to transform an existing application, however the tools are there to allow you to rapidly generate self-contained environments that enable this work.

Empowering Development Teams

You may choose to empower your development team with their own clones of the production environment:

Accurate Development Use Case

When development teams use the same infrastructure as the production environment, you reduce the number of surprises that may occur in deployment. In these cases variables are often used to allow the development deployments to be smaller and cost less than production, and use different certificates and secrets.