You might think that Henry Ford, inventor of the Model T automobile, was also the inventor of the conveyor belt, given its importance within the manufacturing process for his cars. In fact, though Ford is credited with first implementing the conveyor belt/assembly line process in 1913, the invention of the actual modern belt system goes to Swedish company Sandvik, which came up with a steel conveyor belt in 1901.
The impact of the conveyor belt and the subsequent assembly-line manufacturing process that evolved from its use is felt in almost every thing produced today. The methodology extends beyond the assembly line. Product design is typically done in a serialized, straight-line fashion: subcomponents A1 through A11 are designed before building component A, and so on down the line. Product delivery also taps into the assembly-line ethos: goods are directly shipped in the same modular containers from factory to ship to train to truck to distribution center.
This methodology is often used for the software you're using now, too. Applications are designed in discrete phases, then coded, then tested, then packaged, then launched. Hopefully without flaws.
Launching software in a complex data center environment is a bit more complicated than burning an package onto a CD and shipping copies out to be loaded onto each machine. Real-time business practices must be adhered to, and data center environments are often shifted by the operations staff to meet the needs of those business practices, as well as the physical demands of the machines themselves.
So, developing in such an environment is much akin to pointing a gun at a target a mile away with only a notion of where the target will be by the time the bullet gets there. To compensate, development teams will either take up time to launch major point releases at a slower rate, creating more stable software that is perpetually behind the curve, or more recently will use a leaner iterative approach that overlaps the phases of development with launch early, launch often approach in the hopes of keeping up with the business and environment requirements with a series of small iterations to the code.
Enter the philosophy of agile development: a natural outgrowth of iterative development where traditional business requirements are actually de-emphasized (because often end-users don't know all the requirements) in favor of designing products with only some known requirements. End-users get involved in the design and coding process as much as possible so eventually only their true requirements are built into the software, as opposed to features they may not need.
Allowing the users to circle back to the beginning of the software design process instead of keeping them as passive recipients of the end product is a big part of what agile development is all about. While agile practices are present in proprietary software, anyone who's participated in an open source project will recognize many of the techniques.
The whole agile notion of getting users and developers is gaining traction within IT shops, and a growing application of the movement can be found in DevOps, where agile practices are applied to both the development and operations sides of the team.
DevOps, also referred to as agile systems administration, is a big part of how Kris Buytaert, a Senior Linux and Open Source Consultant with the Belgian firm Inuits, likes to create apps together for business. Buytaert describes himself as a developer who "then became an Op" and as such, began to see the challenges facing both sides of the application deployment process.
Operations staffers are usually invited to the application party too late to affect any real impact on the very applications they are expected to deploy and use. Developers were often oblivious to the load and memory usage demands of the environments to which they were sending their finished apps, which database systems were best to use, and so on.
"People think that operations work starts on deployment," Buytaert explained in a recent interview. But--especially with web app development--operations needs to to be involved with the platform and the application at a much earlier stage, he added.
By getting operations and development staff together on application creation sooner, non-functional requirements, like security, high-availability, and monitoring, can be discussed an properly Incorporated into the application at the design phase. As development proceeds, the DevOps method should allow for better version control, bug tracking, and deployment methods because developers will be more in tune with their target environment (testing or production).
While this all makes sense from an objective viewpoint, there are hurdles to getting DevOps practices going.
"The hardest issue is the human factor," Buytaert said, as operations and development teams have long held on to their own turfs not just from a sense of territorialism but also because their own performance is often only measured with metrics related to their own job responsibilities. If an operations staffer has certain metrics to meet in the server room, they may be reluctant to take time away now to work on application development that will affect them later.
Slowly but surely, though, both developers and admins are beginning to see that a little investment in time and expertise earlier in the application process could have big positive benefits later.
The assent of DevOps is being assisted by web application development, where systems and applications are more closely aligned than ever. Developers have found themselves dealing with more op issues, and admins are doing a lot of scripting on the fly to automate as much of their work as possible. With the merging of their responsibilities happening anyway, DevOps as a formal practice has become all the more attractive. The benefits of development/operations interaction for web deployment is most clearly illustrated in a presentation at last June's Velocity conference, where Flickr's John Allspaw and Paul Hammond highlighted how the photo sharing website can manage 10 or more deployments per day.
Buytaert is more than just a vocal advocate of DevOps, though he does that well. He is also involved with the organization of Devopdays, a conference that sprang from regional meetups happening in London and Belgium a couple of years ago. Other than these local events, and a set of meetings at FOSDEM, there was no centralized DevOps event, until the first Devopsday conference in Ghent, Belgium in October, 2009.
Now the conferences are growing. May 1-2 will see the next event, Devops Down Under, in Pyrmont, Australia, just outside Sydney. The following month, the US will play host to its first DevOp event, the DevOps Day USA conference, to take place on July 25 in Mountain View, CA. Both events are positioning themselves as continuations of the conversations started at the Ghent conference last year.
As the conversation continues, both sides are finding new opportunities to not only contribute ideas, but also automate their processes to further enhance the development-to-deployment process. These tools are starting to deliver full integration between source control, testing, and monitoring. With this new class of apps, the DevOps practice may become a measurable, quantified part of application development even sooner.
:
