[ale] [EXTERNAL] Re: Time for this Grey Beard to stir up some stuff

[Chris Fowler]

________________________________
From: Ale <ale-bounces at ale.org> on behalf of Jerald Sheets via Ale <ale at ale.org>

At my most gracious during the pre-coffee hours, I have to address this.  The statement is misinformed " in tyrannical situation. where the abstraction enforces your hosts to conform in some way to what it wishes to work with”

Not all abstractions forces you to conform.   One thing I hate about Tomcat, Java and possibly GO (I've just started toying with it), is that they abstract their whole world in a directory.  It is not easy to pick them apart and places those pieces in a FHS hierarchy.

Just like any of the automation we’ve all worked with, whether it be Puppet/Chef/Ansible/SALT or whether it be host lists and “for loops”, it is what you make of it, and you need to be expert in both the platform and its design patterns before you start making assumptions.

Take my east coast fleet @ about 300k nodes.

I have a large majority that are rather identical, not the least of which because they’re all auto scaling group members and all need to look identical.  I have another percentage over that which require some special sauce of some sort that add a layer of abstraction upon the base abstraction.  I have different layers of abstraction across the fleet that are added and layered in ways that provide the maximum of flexibility right down to $special_snowflake machines that have independent one-off configurations, but all applied via abstractions and layering.

All told, I’d say I’ve got nearly a dozen abstractions, but the combinations and potential configurations magnifies to many hundreds of potential configurations.  Then, with parameterization and layering, two machines that are precisely the same can be configured entirely differently based simply on differences because their IPs are different.

An abstraction that allows you to handle the one-offs via a "plug-in" system is a good thing.  For the system I code and support I started enforcing rules.  Later, I added a system of handling "anything".  This has pros and cons.  The pro is that "you can do anything."  The con is that "you have to know what you're doing to do anything outside the norm."

I personify all my automation.  I'll find out what the admin does and then I start with questions we may ask about things.  As ins "Is host X up?"  I then define the questions we must ask management devices to get the answer like "how do you know?" In the end, the admin is confident that 'up' is the same as their user's version of it.  Automation is difficult to explain to those who don't do it so I use personification and storytelling to spin a tale of what is actually being done.   Many times, I'll spin that tale first and then convert the story into code.   I'm replicating the things they do and automating the tests they do in their head and with their eyes staring at a screen.

I'm have no bias towards or against Ansible or any other platform.  I see them simply as abstractions that one day could be the pre-requisite for new admins starting in the field of administration.  EVERY advancement of technology is simply an abstraction of the previous advancement.   That's the basis of my original response to this thread.   I would agree with OP that the previous technology may not be good enough or stable enough for it to be forgotten and 100% focus on Ansible be required.  Technology marches forward and thigs will be abstracted over and over down to where admins simply know clicks on a web page and submit buttons.  The non-admins will be maintaining everything behind the curtain.
"Admins and systems are co-workers.  As a programmer, the system is my bi*ch."    The mentality that programmers only know syntax seems to be only true when the language is seen as a vocation.  I'm thinking about Java here....




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20210601/2878132a/attachment-0002.htm>