From the Canyon Edge -- :-Dustin

Tuesday, July 26, 2011

The Obligatory DevOps Blog Post

Any business with half a need for computing resources has traditionally employed or contracted a team of professionals -- usually of the species Systemus Administratus (SysAdmin in the lingua franca) -- to manage those resources.  SysAdmins are distinct from their computer resource hunting/gathering predecessors in their ability to use tools, construct new ones, and most importantly, cultivate farms of local servers.  SysAdmins have ruled the landscape of the IT industry for nearly 30 years.  But the extensive manual labor previously required to provision and maintain entire data centers is quite different now, with the industrial revolution of cloud technologies.  The dawn of the cloud computing age has yielded a demand for a different IT skill set.
More recently, we have witnessed the rapid emergence of a successful new species, Developus Operatus, or DevOps for short.  DevOps embody a different collection of technical skills, distinct from their SysAdmin counterparts, finely honed for cloud computing environments and Agile development methodologies.  DevOps excel at data center automation, develop for cloud scale applications, and utilize extensive configuration management to orchestrate massive systems deployments.  DevOps are not exactly pure developers, engineers, testers, or tech operators, but in fact incorporate skills from each of these expertise.  Some SysAdmins have consciously migrated toward DevOps professions, while some others have subconsciously transformed.

With the accelerating adoption of cloud platforms, DevOps professionals are perhaps the most influential individuals in the technology industry.  The cloud’s first colonists and earliest adopters, DevOps technologists are thought leaders and key innovators in this thriving market.  Expert DevOps collaboration is now essential in any Agile development shop, with DevOps stakeholders providing vital guidance to design discussions, platform adoption, and even procurement decisions.

Linux and UNIX server distributions with decades of tradition are hard wired directly into the DNA and collective memory of many SysAdmins.  For veterans who measure system uptime in decades, the Ubuntu Server is still quite a newcomer to this SysAdmin camp, and is often (and unfortunately) treated with inescapable skepticism.

On the other hand, the Ubuntu Server seems rather more attractive to the DevOps guild, as it presents interesting, advantageous opportunities as an ideal Linux platform.  DevOps demand dynamic, cloud-ready environments that older Linux/UNIX distributions do not yet deliver.  The Ubuntu Server is uniquely positioned to appeal to the hearts and minds of the DevOps discipline, who require a unique balance of stability, security, timely releases, yet also the latest and greatest features.  Ubuntu builds on the foundation of Debian’s Linux/UNIX tradition, but continuously integrates the latest application enhancements with high quality, releasing every six months.  On time.  Every...single...time.

I believe that Ubuntu is already appealing to the DevOps crowd as a comprehensive, complimentary platform, particularly in contrast to some of the other industry players.  Never complete, the Ubuntu platform continues to evolve with the likes of the DevOps confluence.

I know that we in Ubuntu are working to ensure that the Ubuntu Server is the ideal Linux platform for the greater DevOps community for many years to come.  Stay tuned to hear how Ubuntu's Orchestra and Ensemble projects are aiming to do just that...



  1. * Every single time except for Dapper but that was a long time ago.

  2. Hear hear,

    I thought DevOps is more a liaison thing between SysAdmins and Developers.

    A SysAdmin who builds automation systems, configuration management systems etc. is mostly a System Architects with a global view of the tools, infrastructure etc. of OPS.

    DevOps IMHO is more the connection between Developers who (mostly) don't know anything about the system they are developing for,and SysAdmins who (mostly) don't know what the developers are coding on.

    Software Architecture (Dev) and System Architecture (Ops) needs to go hand in hand.

    But I can be wrong :)



  3. Question,

    I'm looking over the existing contributed formulas in principia.

    Is there anything that would prevent writing and submitting formulas which work for rpm,conary or ebuild package management instead of apt?

    I understand that the principia collection and its policy is debian ecosystem focused at the moment. But my understanding is ensemble itself is agnostic in this sense, and its only the formulas which end up needed system specific information details like which package management commands to use. Do you guys have any plans to start archiving formulas to make it possible for devops to use ensemble across heterogeneous environments? I don't expect you to do the work making the formulas, but as of right now from my reading, submitting a conary formula would break the principia submission criteria and that seems a bit limiting for overall ensemble adoption as a technology and I'd hope to think that's just an oversight.

    Another question, a little more abstract. I'm not completely sure what ensemable is intended to provide that puppet does not. Not a gripe, I just don't have enough information to compare and constract the offerings. I'm not looking for a feature by feature blow by blow (we all know how dynamic featuresets can be over the span of multiple project releases) I mean from a design and objective pov.



Please do not use blog comments for support requests! Blog comments do not scale well to this effect.

Instead, please use Launchpad for Bugs and StackExchange for Questions.