Follow me!

Connect

Uncategorized

From my experience in IT, mainly in what we call IT operations or more specifically platform Engineering, there’s an emphasis on some noble design principles such as reliability, resiliency, high availability, monitoring, MTTR, MTBF and so on, but something is missing.

None of them should be ignored, obviously, but the capacity for change is often overlooked. I’m convinced it should be a core design principle, re-evaluated for each change, especially for automation architecture.

Another common challenge with DSC, is how to compose DSC configurations.

People have seen the trick of having a Configuration, and the following code within:

This is a good way to get started and works well for small-ish configurations, but it gets out of hand pretty quickly, as it’s hard to read all the if statements and their content. Some variant of this are using Where clauses around the Node expression.

I really wanted to play with the Azure Stack, but as a Cloud automation consultant, I don’t have access to a lot of hardware. Most of what I deal with is already in the Cloud, so how do you run one? Moreover, the hardware requirements are high, because the technical preview is only installable on a single host, colocating all its components for now.

The idea behind this post has been started with a pertinent note from Steve Murawski during#DSCCamp, and ensuing discussions: The preference of an Iterative process against Incremental, and why the difference is important.

As LaoZi said, “a journey of a thousand miles begins with a single step“, whether it’s about knowledge, career, project, or this blog…