This message was deleted.
# general
s
This message was deleted.
s
@early-napkin-64960 What would you do if the bucket had a terrabyte of content in it?
e
@stocky-spoon-28903 so does that mean the philosophy is “immutable except when it is too hard/big/has state”? 🙂 I get that repushing a terabyte every time you changed/deployed something is not desirable. I’m trying to understand at a more fundamental level what qualifies as “immutable infrastructure” and how the underlying engine behind Pulumi relates to that. Does that make sense?
s
My personal opinion (can’t speak for the actual Pulumi team here) is that “immutable” generally applies more to servers than the resources around them.
So it’s not quite as cut and dry as the name makes it sound
e
That certainly seems like a pragmatic approach to me. The documentation seems to suggest that the Pulumi approach takes that sort of common sense approach and makes rolling out updates minimally disruptive wherever possible.
s
I’d say that is a fair assessment. It was also the aim of Terraform, the providers of which underpin some of the Pulumi providers.
e
I’m just trying to internalise these right attitudes for myself so I can better build stuff out.
s
I’m sure some others in here will have differing or more nuanced opinions here also that might help!
e
I come from primarily an Azure/ARM Template world and so far Pulumi is inline with what I expect from that perspective.
I do really appreciate the dialogue @stocky-spoon-28903 Thank you!
s
Ah yes - I think it’s fair to say that cfengine is the common ancestor of most of these systems (although likely CloudFormation was the first one targeted at external APIs rather than a particular host).
Pulumi is the first I’ve seen that doesn’t look somewhat like cfengine from the perspective of a user, though