Welcome to the Web Admin Blog!  This blog is written by a loose confederation of Web Admins – the original core of the group was the Web Admin team at National Instruments in Austin, Texas.  But as people have moved on and our social network has spread, there’s an array of people welcome to post here.  Heck, if you’re a Web Admin and have something to say, email me – at a minimum we can link you; we’re inviting other posters too but usually we’ve at least met you at some convention or something and like you 🙂

What is a Web Admin?

A Web Admin, also known as a Web Systems Engineer or similar title, is a person responsible for the systems which lie behind your favorite Web sites.  Designers make the pretty pictures and CSS, programmers churn out the Java/PHP/Ruby/whatnot (or .NET if you’re a poor benighted bastard).  Admins make it all run.  Like Scotty from Star Trek, although usually working to keep the ecommerce revenue/viral videos/porn flowing rather than dilithium crystal-produced warp energy.

Uptime!  Performance!  Security!  Efficiency!  Agility!  If they’re “everyone’s job” then they’re no ones’ job.

Want to be a Web Admin?  Web Admins have a system administration skillset,  but are not system administrators.  They have programming knowledge, but are not traditional Web developers.  They need to understand their business model, but aren’t suits.  Their job is to focus on the systems and technologies that fall into the gaps between these worlds. In smaller shops it’s a part time job, but once you get to any real size it’s a whole team.

Back in the earliest days of the Web, one person could do anything.  You’d load up UNIX, install the NCSA http daemon, write some HTML by hand and make some gifs, and then write some CGI scripts, then view them in Mosaic.  (Yes, I’m that old.)  Ta da, you were a “Webmaster.”  But the Web has grown by leaps and bounds over the last 15 years.  Just “writing the HTML” is an entire field of endeavor if you are good at it, with stylesheets, JavaScript, client technology, etc.  Programming has fragmented even more – front end specialists, people who write services, people who write database queries, and all in different flavors for different languages or technology stacks (mainly LAMP+, Java, and Microsoft, although insane people use about every language ever invented in the history of computers on the Web).

People who don’t know anything about the field still sometimes say, “What are these Web Admins for anyway?  Aren’t they just operations monkeys who, you know, reboot the site when it needs it?  And move files around because developers aren’t supposed to due to lame compliance requirements?”  And it can be that, for slow, weak security, poor quality Web sites. Or, “Why should it be a separate role – why not just have a programmer, a UNIX sysadmin, and a DBA get together and figure it out?”  One, because there’s a wide variety of software, tools, and technologies that the Web uses that some of those people could learn, but are certainly not part of their usual skill set.  And two, and pardon my manager-ness coming out here, but ITIL has something when they talk about service management and reorganizing your IT along the lines of services, not technologies.  If you get those three aforementioned people together and the Web site goes down, whose problem is it?  Unless the problem is something obvious, everyone is sure “it’s not my code/the database/the network.”  And if reactive work is that fragmented, proactive work just doesn’t get done.

A Web administration team takes responsibility for the site reactively.  It also takes responsibility for it proactively, and is an advocate for the engineering aspects of its design – reliability, performance, maintainability, security, etc.

Here’s what Web Admins do.

  • Select, install, configure, and administer core Web site software (Web servers, FTP servers, media servers, load balancers, DNS, etc.)
  • Select, install, configure, and administer tools and services (monitoring, log management, performance management, security scanning, deployment management, config management, disaster recovery, traffic analysis) and write programs for automation where needed
  • Themselves or, in larger environments, work with other technical specialty teams (DBA, UNIX, Windows, network, storage, etc.) to provision system, network, and database assets for the site
  • Participate in the selection of major site “engines” – content management, search, Web service architectures, etc. – to advocate for well-engineered solutions, as they will be the ones installing and administering them
  • Same deal with SaaS suppliers, to make sure they operate as a seamless whole with the rest of the Web property(ies)
  • Consulting on programming projects, to help developers design well engineered applications that work within the systems environment
  • Provision, install, and administer development/test environments in addition to the live production environment

In our team at NI, we have specialty practices in application performance management and Web security in addition to all of this.   Specific services will vary based on the unique mix of skill sin programmer and sysadmin groups (as well as business needs) of your given organization, but they often look like that.

It’s still an emerging discipline.  There’s actually a new conference O’Reilly puts on, Velocity, which is dedicated to Web Admin concerns.  (Annoyingly, even O’Reilly hasn’t figured out a book category for us.  Web Admin books like Steve Souders’ excellent High Performance Web Sites and Cal Henderson’s Building Scalable Web Sites, and even the Web Site Cookbook, are scattered around under “Programming,” “Networks & Sys Admin, and random subtopics in “The Web.”)

And that’s what we mean by “Web Admin!”  Probably more than you wanted to know 🙂  Anyway, we hope you find something here that you find helpful!