Although we’re currently engaged in a more radical agile infrastructure implementation, I thought I’d share our previous evolutionary DevOps implementation here (way before the term was coined, but in retrospect I think it hits a lot of the same notes) and what we learned along the way.
Here at NI we did what I’ll call a larval DevOps implementation starting about seven years ago when I came and took over our Web Systems team, essentially an applications administration/operations team for our Web site and other Web-related technologies. There was zero automation and the model was very much “some developers show up with code and we had to put it in production and somehow deal with the many crashes per day resulting from it.” We would get 100-200 on-call pages a week from things going wrong in production. We had especially entertaining weeks where Belgian hackers would replace pages on our site with French translations of the Hacker’s Manifesto. You know, standard Wild West stuff. You’ve been there.
Step One: Partner With The Business
First thing I did (remember this is 2002), I partnered with the business leaders to get a “seat at the table” along with the development managers. It turned out that our director of Web marketing was very open to the message of performance, availability, and security and gave us a lot of support.
This is an area where I think we’re still ahead of even a lot of the DevOps message. Agile development carries a huge tenet about developers partnering side-by-side with “the business” (end users, domain experts, and whatnot). DevOps is now talking about Ops partnering with developers, but in reality that’s a stab at the overall more successful model of “biz, dev, and ops all working together at once.” Continue reading
the agile admin 