
Virtual Panel on Immutable Infrastructure - r4um
http://www.infoq.com/articles/virtual-panel-immutable-infrastructure
======
contingencies
TLDR: Virtualization meets continuous delivery in the now, versus conventional
systems administration in the way-back-when.

 _In practice, "immutability" (again poor terminology) means disposability._

 _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._

Also features gems like:

(1) _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._ What's wrong with this picture? Nothing should touch
production that isn't a known quantity.

(2) _The way to get infrastructure right is to have a continuous knowledge
relationship with system specifications (what I call promises in CFEngine
language)_ Silver bullet scenario without clear definition.

(3) _Disposability emerges often in a society when resources seem plentiful.
Eventually resources become less plentiful, and the need to handle the waste
returns._ Isn't that why older, full-hardware era PFCTs like CFEngine/Puppet
area losing ground to LXC and snapshot-capable filesystems?

(4) _Mission critical servers running monolithic applications cannot generally
be managed in this disposable manner._ 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.

------
cordite
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.

I think the title would be better as "Immuatable / Disposable Architecture"

------
mwcampbell
I think the discussion would have been more interesting if Chad and Mitchell
had been given the opportunity to rebut Dr. Burgess.

~~~
marcosdumay
He seems to be talking about some completely unrelated concept. There's
nothing to rebut, he should just use a different word, and talk at different
events.

------
ExpiredLink
Immutability has jumped the shark, right?

