dev2ops

What makes dev2ops so hard anyway?

1

Alex Honor / August 23rd, 2007

Migrating application changes from development to production was simpler when systems were centralized, target environments homogeneous, and the whole process needed little or no automation. But today’s business applications have evolved to run 24/7, use distributed architectures, are hosted in multiple environments and the process to change them has become increasingly more complicated and very hard to automate.

I have noticed several factors that add up to making dev2ops technically very challenging in both large and small organizations:

• Rate of change: Many businesses depend on driving change from development, through test environments and on to production operation, on a daily basis (sometimes even more!). Worse yet, some things need to change faster than others. For example, content and data need to change constantly while core technologies like platforms less frequently. No matter what, the business desires the ability to update any and all parts of the application when needed. Can this be done predictably and reliably?
• Nature of change: What comprises application change varies, too: data, code, configuration, content, platforms. Each kind of change, has a different impact on the overall stability of the application. Does the organization understand change is not created equally?
• Complexity: Applications supported by distributed architectures and multiple hosting environments do not present a simple interface to widespread nor pinpoint modification. Understanding how to make changes at each point and then figuring out a sane way of coordinating change across the board is tricky. Who knows what connects to what and the best way to change the application over time?
• Organizational boundaries: Who performs dev2ops? Developers, operations, both or other? The application development is carried out by developers so are they best suited to install it and set it up in a production environment? Operations understands how to maintain and scale infrastructure so should they take apart the application and deploy it the way they best see fit?

Reflecting on these challenges organizations face, it’s amazing that the dev2ops process works at all! In the end, its accomplishment usually falls on a few dedicated, knowledgable individuals, working long, intense hours at the worst times (ie, late nights and weekends).

 

Does dev2ops have to be an “all hands on deck” scenario or can best practice and better tools bring efficiencies and reliability?

dev2ops?

Alex Honor / August 22nd, 2007

As the name suggests, dev2ops is anything to do with driving application changes from the development world to the operations world in organizations that deliver software as a service. Depending on your place in the organization you might see dev2ops differently: release management, configuration management, software building, deployment, system provisioning, data base administration, etc.

It all depends on your role in the dev2ops process. The dev2ops process might be the sole concern of one person or might be undertaken by many hands. But, anyone involved with it knows that it is a difficult, slow, error prone and time intensive process that usually occurs at the worst times (late at night and on weekends). Today’s 24/7 always on service availability requirements make it all the more difficult.

Because the dev2ops work can be split across so many roles in the organization, there doesn’t seem to be a natural home for its discussion. That is the purpose of this forum. Here one can discuss emerging best practices and pitfalls, attempt to analyze and understand challenges or just vent and relay your tales from the trenches to other dev2ops folk!