2013-09-25 Wednesday - Tooling to Support Continuous Deployment

This posting is a placeholder for resources links and notes about tooling that I find interesting to support DevOps in the challenges of Configuration Management and [Continuous?] Deployment.

For some somewhat agnostic overviews of tooling and processes that can support continuous deployment  in practice...these presentations may be of interest:

• http://www.slideshare.net/markstanislav/keeping-the-cloud-promise-infrastructure-agility-with-a-devops-toolchain
• http://www.slideshare.net/traylenator/cern-agile-infrastructure-road-to-production
• http://www.slideshare.net/jmcgarr/continuous-delivery-applied-agile-richmond
• http://www.slideshare.net/socializedsoftware/linuxfest-nw-2013-hitchikers-guide-to-open-source-cloud-computing

While many companies have stringent regulatory constraints that require more thoughtful and methodical approaches to deployment, I thought it worth noting how Etsy.com implemented a RADICAL (!) DevOps culture - as an inspiring example to challenge status quo thinking of "but-that's-not-the-way-we-do-things-here..."

http://www.slideshare.net/OReillyOSCON/put-a-button-on-it-removing-barriers-to-going-fast

A Wikipedia article - providing a sparse summary/survey of some open source solutions for automated deployment tooling...

http://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software

There is a great deal of fast-paced innovation in the tooling space for deployment & configuration management – here are some of the tools (slightly listed in order of what I find to be interesting and innovative)…

http://www.ansibleworks.com/

• http://www.slideshare.net/Codemotion/infrastructure-as-data-with-ansible-systems-and-cloud-deployment-and-management-for-the-lazy-developer-by-carlo-bonamico
• http://www.slideshare.net/lorinh/vagrant-ansible-and-openstack-on-your-laptop

http://puppetlabs.com/

• http://www.slideshare.net/PuppetLabs/deploying-datacenters-with-puppet-puppetcamp-europe-2010
• http://www.slideshare.net/PuppetLabs/scalable-systems-management-with-puppet
• http://www.slideshare.net/pk.habi/cloud-meetsfogpuppetrootconf

https://juju.ubuntu.com/

http://www.yadt-project.org/

• http://www.slideshare.net/schlomo/linux-tag-2013-data-center-automation-with-yadt?from_search=2

http://cfengine.com/

http://www.lcfg.org/

http://saltstack.com/community.html

http://www.opscode.com/chef/

• http://www.slideshare.net/jesserobbins/using-chef-for-automated-infrastructure-in-the-cloud
• http://www.slideshare.net/adamhjk/infrastructure-automation-with-chef

Microsoft System Center 2012

http://www.slideshare.net/kristiannese/nic-2013-configure-and-deploy-private-cloud?from_search=3

http://dploy.io/

http://wiki.smartfrog.org/display/sf/SmartFrog+Home

http://trac.mcs.anl.gov/projects/bcfg2/

http://sourceforge.net/apps/trac/etch/wiki

http://www.ocsinventory-ng.org/en

https://trac.lal.in2p3.fr/Quattor/wiki/Web?redirectedfrom=Web/Overview

Less sophisticated, but perhaps a good example of how some shops can still make improvements over manual processes...even if it is just by doing things with bare-bones scripting…for example, via Rex

http://www.slideshare.net/inovex/rex-lightning-talkyapceu2013?from_search=1

2013-09-17 Tuesday - ZeroMQ

Recently, while researching some distributed computing integration patterns, I happened to come across an interesting paper: Middleware Trends and Market Leaders 2011 - produced by researchers at the CERN facility in Switzerland - that cited ZeroMQ.org as a leader.

Ilya Grigorik posted a nice write-up on ZeroMQ back in September 2010
http://www.igvita.com/2010/09/03/zeromq-modern-fast-networking-stack/

2013-09-15 Sunday - Auto-Generating Documentation from DataPower Config Info?

I recently posed a question on the  IBM WebSphere DataPower SOA Appliance forum:

Auto-Generation of Documentation?

It seems that zip2html is the only option available - and it seems to be a fairly minimal / brute-force approach at that.

2013-09-15 Sunday - IBM Integration Bus

Today I'm doing some research on the relatively new IBM Integration Bus (v9.0)

IBM Integration Bus

IBM® Integration Bus formerly known as WebSphere® Message Broker is an enterprise service bus (ESB) providing connectivity and universal data transformation for service-oriented architecture (SOA) and non-SOA environments.

IBM Integration Bus Information Center v9.0

IBM Integration Bus v9.0 documentation

IBM Integration Bus introduction

What's new in IBM Integration Bus (v9.0) for WebSphere Enterprise Service Bus users?

Download IBM Integration Bus for Developers

Converting WebSphere ESB resources for use in IBM Integration Bus: Part 1

Converting WebSphere ESB resources for use in IBM Integration Bus: Part 2

Extended Structured Query Language(ESQL) is a programming language defined by IBM® Integration Bus to define and manipulate data within a message flow.

2013-09-03 Tuesday - Technical Debt Conjecture

Recent observations and reflections prompted me to ponder this thought:
A Technical Debt Conjecture: 

For a given non-trivial project,

Given [z] budgeted sprints,
for [m] developers,
Where for sufficiently large [m],
[n] items of technical debt (or defects) are introduced - as the total for all [commits | builds],
which will subsequently require [x] additional sprints to fix.

One wonders if there are lower limits for [z], [m], [n] that would allow for approximations of [x]?

One wonders what recurring ratios of m:n might occur with some predictable frequency across different organizations, and if those ratios might vary to a greater (or lesser) degree if further considered within the specific vertical context of a given industry?

One wonders if these values are the same for on-shore vs. off-shore vs. hybrid project teams?

One wonders if there is a predictable relationship between m:n and x?

One wonders how the duration [t] of a given project might affect the trend line and predictability of these factors - and if there might be clustering of values around certain frequencies of [t]?

One wonders, given the planned / budgeted value for [z] - at what sufficiently large size of [x] do most organizations kill a project?

One wonders, what ratio of z:x does a project qualify for the 'death march' designation?

One wonders what minimum ratio of m:n should be sufficient, as a monitored metric, to serve as an indicator to management that one or more of the following might apply?

• Requirements may not be [sufficiently | clearly] defined or finalized
• One or more developers may need to be removed from a project team