We at our company were having a bit of a debate over the nature of immutable infrastructure.
On one side, we have a statement:
We use immutable infrastructure on Azure public, [Prisma] will either use ssh to do the remote install, which we are attempting to disable as part of firming up our immutable infrastructure, or use some azure remote installation method (VM extension).
[This] is a step backward[s] from an immutable infrastructure point of view.
But from the other side:
I disagree [with] some of those points. Immutable architecture does not mean VM extensions cannot be utilised.
Curious to know your thoughts on this?
Does having VM extensions in Azure go against immutable architecture?
For context, we are debating the best way to roll out prisma defender across the estate, and one consideration was to use Azure Policy / Azure Security Center with VM Extension installation.
As with many of these things there isn’t a widely accepted definition that answers such questions, so it is a matter of opinion and shaped by what works within the organisation/situation you are in.
At one extreme any form of change should result in a resource being replaced, but there are levels below that to allow limited forms of change without that happening. For example should you be allowed to apply OS updates to a VM, or should that only be done by creating a new machine image? Should SSH access be allowed for emergency changes? Should application updates be allowed on an existing VM? Should configuration changes to an application require a new resource to be created?
There are advantages & disadvantages with whatever level is chosen. Requiring a resource to be replaced has some overhead (both for building the replacement image, doing the replacement and recovering state [such as local in-memory caches that speed things up]). On the other hand allowing more changes without requiring a replacement can lead to drift, with an accumulation of unmanaged changes (quick fixes that weren’t added into the code or old files that weren’t correctly cleaned up after an upgrade) and the possibly result in issues that are harder to resolve or wouldn’t have happened if the resource had been replaced.