IaaS or PaaS? It's all Code.

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 credentials into source control.

Changes are much more easily audited (why did this happen, who made the decision), if they are stored as code in a source control system, than an arbitrary UI.

Chapter 4 ends with a section on Code as Documentation, pointing out that "... infrastructure code is more useful than written documentation [as it is] ... always an accurate and updated record of your system". I like the idea of generating documentation from a system. It's tedious to write documentation, but it's handy to have an overview at hand. Spending the time to set up generation, seems worthwhile to me. :) 


Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints