Development Experience(s)

A stack is a set of infrastructure resources, e.g. an Virtual Machine, Network and Database ; or a Network Interface, A Virtual Harddrive and a Network Share . These are my reflections, lessons learned and brief summary of chapters 7 and 8 of Infrastructure as Code and is  part of the Infrastructure as Code series . When you configure a stack, keep parameters simple. If you find that you need an advanced set of parameters - or you find yourself introducing branching logic - make a new, more specialized, stack. When naming resources in your stack, consider using a combination of a static and dynamic name, like app-service- ENVIRONMENT . If you are working with resource managers where you can generate a unique ID, consider generating a unique ID for a root object and then use that ID as a suffix. See this article for more information . When transitioning into the world of stack configuration, keep non-secret configuration in source control (as opposed manually typing it in, or passing it

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 fail

This is a continuation in the bite-size summaries of Infrastructure as Code . Last post discussed Creating Disposable Things . Chapters 3 and 4 discussed Infrastructure Platforms  and the Core Practice: Define Everything as Code . We discussed how Cloud native applications easily get coupled to the infrastructure provided by an arbitrary cloud provider, in order to get the most benefit out of it. On the flip side, we discussed that attempts to build cloud agnostic applications risk you getting locked into specific tooling. There's clearly upfront faith-based decisions one need to make here: Are we content with being locked into, say Azure, to get productivity gains from the bindings its Functions platform provide? Or are we happy with the the consequences of adopting, say, OpenFaas ? The book emphasizes that we should strive for tooling that acts on plain text files, so that we can manage them in a source control system. Secrets management is undervalued. It's too easy to check

 A number of colleagues and I are currently reading Kief Morris’ excellent book on Infrastructure as Code (link below). Here’s a short summary of the first two chapters. Transitioning from “The Iron Age” of managing your hardware resources yourself, to “The Cloud Age” where you instead buy usage of virtualized resources as needed, Kief tries to frame our thinking in assuming that “systems are unreliable” why we need to “Make everything reproducible”, focus on creating “disposable things” that “Minimize variation” and that we can “repeat any action”. Kief claims that stability comes from making changes and that neither prioritizing speed over quality nor prioritizing quality over speed leads to happiness, but that we must prioritize them together. “If it’s worth documenting, it’s worth automating” is another claim, elaborated with: If you can script a task, script it. If it’s too hard to script, dig deeper. Maybe there’s a technique or tool that can help. As a side note, the author of