Stacks in all sizes and shapes

One of the initial hurdles in learning any new thing, is to get a grasp of the terminology - the specific language used in the specific context. Infrastructure as Code addresses a shortcoming of language as it is trying to define a "Stack". Having talked about how a Stack is a set of related infrastructure resources (say a Database, a Disk, a Network), it acknowledges that "Most stack management tools don't call themselves stack management tools. Each tools has its own terminology to describe the unit of infrastructure it manages." Future blog posts are likely to use the word Stack to describe a set of related infrastructure resources.

This post covers chapters 5-6 of the book (linked below) and is part of the Infrastructure as Code series.

When you make a change in a Stack, you want to Continuously Deploy it, as you want to make sure that the files you have on disk represents the state of your applications and you want to make sure that you can act on any failures by addressing as small of a change as possible.

For that reason, Monolithic/large stacks are not scalable. You don't want the associated risk of deploying a stack if the change you have made does not affect the entire landscape it is managing; say you changed a setting for App1 but the stack is managing App1...AppN. Seeing a service as the previously smallest deployable unit, the book talks about micro stacks which consists of the individual moving parts of a service, say its network or database. As you might want to scale these independently, you might want individual stack definitions for the parts, together with a stack definition of the services' full environment, where these parts are included.

Take the fictional monolithic stack above. It governs the environments for a number of applications. If we updated the Queue for Application 2, we'd update the environments of Application 1 and N as well. Also, if there were a syntax error in our update of the Queue and we needed to update the Function in Application N right away, our Queue update would effectively interrupt/disturb that update. Smaller is better.

You want to make sure you treat your stack code the same way you treat your high-valued application code. Apply code practices such as Single Responsibility Principle and Don't Repeat Yourself to avoid copy-pasting stack code around. Instead, use templating in some fashion.