tag:blogger.com,1999:blog-5710523491883009086.post3900578665203837290..comments2019-11-13T12:39:58.429-08:00Comments on abusedbits.com: Declarative IT and Design for OperationsMichael Nelsonhttp://www.blogger.com/profile/06520972820024673718noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-5710523491883009086.post-55854577038124383692018-12-07T02:50:30.039-08:002018-12-07T02:50:30.039-08:00I used to spend some time talking about declarativ...I used to spend some time talking about declarative configuration management (vs imperative) in the infrastructure as code boot camps (before everything was migrated to Katacoda).<br /><br />I like the idea of declarative, but the practicalities are problematic, and you very quickly hit something resembling the halting problem. Too many possible ways of doing things leads to too many corner cases leads to an exploding test matrix of doom.<br /><br />We can be declarative, but only in a clearly bounded context. So the first conversation needs to be about those boundaries. This turns out to be one of the neat things about cloud services, as the service provider sets the boundaries, and the customers are forced to work within them; thus we have a clearly bounded context that declarative stands a chance of working within. Where we need to be careful is on our own side of the line in the shared responsibility model, as there lies the opportunity to introduce too much variability, and destroy the boundaries of the provider curated bounded context. Serverless is a good example of how constraints are actually helpful, as the boundary definitions are much clearer than they are with (say) a VM (where I have the opportunity to mess things up with an endless choice of operating systems, middleware, languages and frameworks).Chris Swanhttps://www.blogger.com/profile/13335529788016855957noreply@blogger.com