4 ms·

Virtual Panel on Immutable Infrastructure

24 points by r4um 13y ago

ExpiredLink 13y ago
Immutability has jumped the shark, right?
deleted 13y ago
[deleted]
cordite 13y ago
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 13y ago
I think the discussion would have been more interesting if Chad and Mitchell had been given the opportunity to rebut Dr. Burgess.
- marcosdumay 13y ago
  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.
contingencies 13y ago
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.

24 points by r4um 13y ago

ExpiredLink 13y ago

Immutability has jumped the shark, right?

deleted 13y ago

[deleted]

cordite 13y ago

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 13y ago

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

marcosdumay 13y ago
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.

contingencies 13y ago

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.