[LRUG] Idempotency vs the cloud

[Gareth Rushgrove]

I feel the need to throw something else into the debate, specifically auditing.

Running puppet/chef/whatever every x minutes doesn't just have the
ability to change things to be how you described them, it has the
ability to tell you that something in the world is different to how
you think it should be.

Off course given a perfect world nothing would ever be different
obviously. But hey, people log in and change things by hand on one
server (by accident or on purpose, maybe maliciously, maybe not), you
had a bug in your provisioning system, your box has been compromised
and someone is executing code via SQLi, etc. You can avoid or mitigate
these in different ways, but then you're still left with the
cataloguing problem (ie. I want an up-to-date list of all the software
running everywhere)

Lots of large organisations actually use Puppet (and I'd guess Chef)
just for this singular auditing role, only running them to change
things manually and infrequently or not at all.

Some of this is ignored by small companies because it's probably not
the thing that's going to kill you. But at least some of the tools, or
the companies behind them, will optimise for this case (where the
status quo is manual audits and a spreadsheet) because that's where
the money is.

Gareth

On 17 July 2013 15:12, Tom Taylor <tom at tomtaylor.co.uk> wrote:
> On 17 Jul 2013, at 12:13, Tom Stuart <tom at codon.com> wrote:
>
>> If things begin to move more in that direction, can we stop caring about idempotent configuration management, and can it therefore become drastically simpler?
>
> There's a lot to like about this approach, but for most applications, that need to maintain state in memory and on disk, it feels like you'd be moving more of the individual machine state into the global state, and that feels like a more complex beast to manage, with more unknown unknowns.
>
> As Paul mentioned, moving storage around has a lot of friction, but there's also things cached in RAM that need rebuilding, and so on.
>
> I've always found that a good design rule in engineering is to reduce the number of things that move. For many services a single well specced dedicated server will result in better reliability over a number of years than a distributed system spread across a number of VMs (at the trade off of flexibility).
>
> That said, these are good problems to overcome, and solving them is attractive, not least because as you approach the scale of Google, Amazon and friends you're pretty much forced to. But they also feel sufficiently complex that I'd rather avoid them for as long as possible.
>
> I think there's definitely room for a Sinatra to Chef/Puppet's Rails, but as most of us know, it doesn't take much to wish we'd just started the project in Rails.
>
> t.
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org



-- 
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com