System Administration is a funny thing.<\/p>\n\n\n\n
Many people think that it\u2019s just adding users, performing requests, and working with project groups to get their \u201cnext big thing\u201d out the door.<\/p>\n\n\n\n
Certainly, much of your work involves those very things, but what younger admins never quite realize until they\u2019ve built a beast that cannot be fed is that everything is about frameworks that tie everything together. From a system load framework to an authentication framework to an asset management framework, if built correctly a framework can save each and every admin countless hours of administration time. How?<\/p>\n\n\n\n
Automation<\/strong><\/p>\n\n\n\n Take distribution. You can push files around considerably more easily when you\u2019ve built a framework to do so rather than every admin having an individual way to do it. In fact, when properly implemented, distribution of a file to \u201cgobs\u201d of similar hosts (that\u2019s a technical term there :)) can be as simple as:<\/p>\n\n\n\n distrib\u00a0<\/p>\n\n\n\n Now, many will say that rsync or scp will do much of this for you, and that is correct. \u00a0However, in the context of your individual site, having symbolic abstractions such as \u201cclass of host\u201d goes a long way. \u00a0Perhaps a certain file needs to be distributed to only your web servers. \u00a0Or maybe, only web servers running RedHat 5.3. \u00a0If you correctly build a framework for file shove and management, suddenly heavy lifting becomes a light chore. \u00a0After all, the more pulleys in the works, the lighter the load becomes.<\/p>\n\n\n\n Authentication<\/strong><\/p>\n\n\n\n As has been covered on this site in the past, LDAP is a wonderful authentication framework that can be tied to positively everything in your environment as well. \u00a0From Apache authentication against the store to UNIX authentication, to various types of applications understanding LDAP as a target for authentication sources, much pain of user administration can be solved by having a centralized authentication mechanism.<\/p>\n\n\n\n Frameworks as Philosophy<\/strong><\/p>\n\n\n\n Rather than continue with examples on a case-by-case basis, consider the entire concept of frameworks and unifying ties across systems and networks. \u00a0Many places I\u2019ve worked, organic growth brought about massive numbers of machines that were \u201csiloed\u201d one from another either by project boundaries, function boundaries, or other superimposed logical delineations we as users imposed on them.<\/p>\n\n\n\n Logical Differentiation and Service-Orientation<\/strong><\/p>\n\n\n\n The clear winner over the \u201cas needed\u201d or \u201cfor a purpose\u201d way of doing things is the \u201ctiered\u201d or \u201cservices-oriented\u201d model of work. \u00a0Rather than many groups of things that form a farm of servers, you have the farm of servers that service many different things. \u00a0This, I know, sounds something like technological double-speak, but let me explain what I mean.<\/p>\n\n\n\n In a normal environment, we would have a somewhat typical scenario with front-end servers, back-end infrastructure, management, and organization. \u00a0The problem we have with this is that if \u201cNew Whiz-Bang project #7\u201d comes along, new hardware will need to be procured for each piece of the puzzle. \u00a0New app servers, new web servers, new database components, maybe management and authentication considerations\u2026 Each project, every time, capital outlay, budgetary justifications, etc.<\/p>\n\n\n\n If, instead, you think in terms of frameworks, your job becomes one of determining total resources needed across an environment rather than resources needed for an individual project, and thus individual project growth concerns, individual project funding concerns, personnel, etc. \u00a0“Siloed” growth and expansion may not bite you today or tomorrow, but as I said early on, will become a beast that cannot be fed.<\/p>\n\n\n\n Consider instead, the following example:<\/p>\n\n\n\n Instead of \u201ctheses web servers versus those web servers\u201d, you instead have \u201cthe web layer\u201d. \u00a0Any and all requests to your company come through \u201cthe web layer\u201d. \u00a0It is scaled as an entity and not as individual projects. \u00a0When scaling happens, all environments benefit.<\/p>\n\n\n\n Instead of \u201cthese application servers\u201d versus \u201cthose application servers\u201d, you have \u201cThe App Layer\u201d. \u00a0 A single applications framework that serves all application server requests back out the front-end web layer by leveraging container and web server features to do the \u201ceffing magic \u2122\u201d on the backend to provide a unified front-facing experience to the user.<\/p>\n\n\n\n Extrapolate these ideas\u2026 Instead of the app layer, let\u2019s say the app cluster. \u00a0Now the power behind this idea becomes clear. \u00a0Unlimited scalability with unlimited potential. \u00a0How about \u201cthe database cluster\u201d? \u00a0Regardless of the solution you use, if there is a single database resource (cluster, replication ladder, whatever) that serves back queries you throw at it, how much better is that than \u201cdatabases for this\u201d and \u201cdatabases for that\u201d?<\/p>\n\n\n\n Take it a step further.. make an XML services layer that serves out \u201cyour data\u201d in a clearly defined API sort of way, and all you do is make XML requests to a services infrastructure rather than directly at your databases. \u00a0Or, your cluster is comprised of \u201cwrite databases\u201d versus \u201cread databases\u201d and you\u2019re segmenting the\u00a0type\u00a0of traffic you\u2019re serving to reading versus writing, making the read operations light-years faster.<\/p>\n\n\n\n Authentication layers, web layers, XML layers, app layers, database layers\u2026 All frameworks that grow as an organism rather than series of unrelated growths.<\/p>\n\n\n\n When going through your next design adjustment or your next expansion or data center rollout, consider thinking differently about growth and planning. \u00a0I believe that if you think in terms of large organisms with several related parts rather than several growths unrelated except in their location, you\u2019ll build into your infrastructure a power and a scalability that will serve you well for many years (and growths!) to come.<\/p>\n","protected":false},"excerpt":{"rendered":" System Administration is a funny thing. Many people think that it\u2019s just adding users, performing requests, and working with project groups to get their \u201cnext big thing\u201d out the door. Certainly, much of your work involves those very things, but what younger admins never quite realize until they\u2019ve built a beast that cannot be fed […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[2,4,3],"tags":[],"class_list":["post-301","post","type-post","status-publish","format-standard","hentry","category-puppet-administration","category-puppet-education","category-puppet-news"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/301","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/comments?post=301"}],"version-history":[{"count":1,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/301\/revisions"}],"predecessor-version":[{"id":302,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/301\/revisions\/302"}],"wp:attachment":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/media?parent=301"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/categories?post=301"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/tags?post=301"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}