My brother (yes, it does run in the family) has a degree in computer science which, by most definitions, makes him a developer. That’s the focus of most computer science focused degree programs, much to the chagrin of the myriad other IT-focused specialties like networking, security, and operations.

Interestingly enough, he worked his way through college as a sysadmin and his first job out of college was as a sysadmin. And now he’s doing a little of both. That’s not unlike my own experience in which I often did “dual duty” as both sysadmin and developer, depending on where I was and what the organization needed.

Listening to my brother and drawing on my own experience, it sure seems There are a lot of similarities between the two seemingly disparate roles of administrator and developer; perhaps a lot more than we are usually willing to admit. After all, if you’re a developer then they just don’t understand what you do. If you’re an administrator, then they don’t understand you or the complexity involved in just getting through the day. Organizational silos cause a lot more “us”and “them” than is actually found in reality.

But let’s take a closer look at the definition of a "developer.” Notice it concerns itself primarily around the creation of programs:

A person or organization that designs software and writes the programs. Software development includes the design of the user interface and the program architecture as well as programming the source code.

But anyone who has been a network or system administrator for more than 0.5 minutes knows that this definition applies just as easily to folks who would not traditionally be considered a “developer.”

SCRIPT, SCRIPT, SCRIPT TO MY LOU

There have always been scripting languages. There is Ruby and PHP and ASP and JSP. Command-line focused scripting languages, too, abound from bash to PowerShell to TCL to PERL and Python. The biggest difference between most scripting languages and other development languages like C/C++ and Java is that there is rarely an explicit “entry point” into a script. There’s no “main” function that kicks things off because the entry point is implicit; it starts at the top of the script (excluding functions, of course) and starts executing.

But there are many similarities, too. Whether it’s the ability to define functions or the use of conditional statements (if…then, for, while) or handling of variables (pass by reference? pass by value) the similarities between the scripting languages utilized on a daily basis by system administrators and those used by developers far outweigh the number of differences. Scripting, no matter what the language, like programming in compiled languages requires an understanding of syntax, functions, variables, structure, and order of operations. The skills needed are very similar and the result is, if you ignore the focus on operational versus business, very much the same.

And network and system administrators make extensive use of scripting languages to automate tasks, perform specific functions “on-demand”, and even create reports with eye-candy for management on a daily or weekly basis. The difference between the development done by a  network or system administrator and that done by an application developer is truthfully only distinguished by the intended end-user and the focus. The network and system administrator’s goal is to create an application that codifies an operational task, the application developer focuses on creating an application that codifies some business process.

They both must design the solution and write the “program”, e.g. script. They design a user-interface – even though it is almost always command line – and they “program the source code”. Network and system administrators do just about everything an application developer does. The admin is just lucky enough to be both end-user and developer; they don’t generally have to deal with business analysts or actual customers.

And while application developers may need to understand and be able to manipulate system configurations in order to develop and test their applications, they generally don’t deal with the network or myriad systems that make up a production infrastructure. They leave that chore to the administrators. But the introduction of Infrastructure 2.0 with its requirement for collaboration not just between infrastructure systems but with applications, too, may blur the line between developer and admin even further.

THE EFFECT OF NETWORK as a SERVICE ON THE DIVIDE BETWEEN OPS AND DEVELOPMENT

The net effect of the “network as a service” has been and will continue to be the evolution of the developer side of the system and network administrator. The availability of service-enabled APIs and script-enabled APIs through which network and application network infrastructure can be controlled, configured, and managed is pushing system and network administrators into increasingly application-oriented, business process type scripting (applications).

It does not seem such a leap to assume that administrators, used to scripting complex tasks in a variety of languages and environments, could be expected to implement more integrated, collaborative “applications”. Nor does it seem a leap to assume that developers will need to better understand and collaborate with the network and systems required to deliver their applications in a dynamic infrastructure. The feedback from applications are critical to the success of a dynamic infrastructure (a.k.a. an internal cloud architecture) as is the intricate dance required of network and application network infrastructure to keep those applications available and performing as expected by the business. To achieve that may require administrators to fire up an IDE (Integrated Development Environment) and take up the tools of traditional “developers” in order to leverage Infrastructure 2.0 enabled systems. The ever extensible and flexible Eclipse environment has been used for programming languages, management consoles, graphing environments – you name it and it’s probably been implemented as an Eclipse plug-in. And admins have probably used it; probably have it installed on their desktops. That means it’s easy enough for them to adapt to the environment when it’s used for development tasks.

While those tasks could, ostensibly, be handed over to the application developers, it doesn’t make a whole lot of sense to place yet another task on their plate when network and system administrators are likely as capable and already have a firm grasp of “programming” and how the infrastructure needs to collaborate in order to provide the kind of dynamism necessary to achieve a more efficient, flexible data center.

Administrators already are developers in their own right, they just aren’t necessarily application developers. Infrastructure 2.0 and the drive toward internal cloud architectures will almost certainly bring this heretofore secret skills of admins to the fore and take them one step closer to being recognized as the developers they already are.

Related blogs & articles:

• Infrastructure 2.0: The Feedback Loop Must Include Applications

• v.10 Introduction to the tmsh Command Shell

• iRules (TCL-based F5 scripting language) Documentation

• iControl (service-enabled management API for BIG-IP) Documentation

• Infrastructure 2.0: As a matter of fact that isn't what it means

Read the original blog entry...