TLDR: Virtualization meets continuous delivery in the now, versus conventional systems administration in the way-back-when.<p><i>In practice, "immutability" (again poor terminology) means disposability.</i><p><i>15 years ago, if I wanted to update a software component on a UNIX system, I upgraded the software package and its dependencies. Now I tend to view running server instances as components. If you need to upgrade the OS or some package on the system, just replace the server with one that's updated. If you need to upgrade your own application code, create new server instances with the new code and replace the old servers with it.</i><p>Also features gems like:<p>(1) <i>rolling back with immutable infrastructure to a recently previous version is cheap and easy: you just replace the new servers with servers launched from a previous image.</i>
What's wrong with this picture? Nothing should touch production that isn't a known quantity.<p>(2) <i>The way to get infrastructure right is to have a continuous knowledge relationship with system specifications (what I call promises in CFEngine language)</i>
Silver bullet scenario without clear definition.<p>(3) <i>Disposability emerges often in a society when resources seem plentiful. Eventually resources become less plentiful, and the need to handle the waste returns.</i>
Isn't that why older, full-hardware era PFCTs like CFEngine/Puppet area losing ground to LXC and snapshot-capable filesystems?<p>(4) <i>Mission critical servers running monolithic applications cannot generally be managed in this disposable manner.</i>
Actually they can, just not by these immature tools. That's because both (a) the overly simplistic deployment methodology of older, full-hardware era PFCTs like CFEngine/Puppet provides no integrated tools for storage management; and (b) deployment speeds and therefore feedback loops are again far too slow; moreover the old-school immature "try it and see" approach is allowed, encouraged and favoured over any formalistic SOA service interoperability testing model resulting in known inter-service compatibilities that can be used to inform and rationally restrict changes to production infrastructure.
They mention over and over that "immutable" is a misnomer, the biggest reason why is because services should consider other services as disposable and able to go missing at any moment.<p>I think the title would be better as "Immuatable / Disposable Architecture"