DevOps and Application Readiness

By Steve Schmidt

DevOps has
become an increasingly hot topic. It was covered in the Microsoft
Management Summit (MMS) 2013
keynote as well as in a variety of sessions at that event,
and has been in the news with recent acquisitions made by IBM and CA, and
earlier acquisitions by BMC.

DevOps is a
general concept, defined as:

DevOps is a
software development method that stresses communication, collaboration and
integration between software developers and information technology (IT)
professionals. DevOps is a response to the interdependence of software
development and IT operations. It aims to help an organization rapidly produce
software products and services.
http://en.wikipedia.org/wiki/DevOps 

At MMS,
DevOps was described as an approach intended to solve the problems caused by
some developers and operations people having different focus areas, and “a
clear conflict of interests on many occasions”, as seen below…

DevOps

Source: Microsoft MMS 2013

One example
of a DevOps solution, demonstrated by Microsoft, was the ability for errors in
deployed applications to be isolated by IT administrators and for tasks to be
automatically assigned to developers upstream, right inside the Visual Studio
interface.

Another
example of DevOps solutions can be seen in the Application Release Automation
market, where products are designed to enable web/cloud app developers to
define new server app and middleware configurations for deployments. In this
instance, operations personnel can review and edit these configurations, and
the updates can be automatically deployed and tracked by both groups as part of
a workflow.

Returning
to the broader definition, the DevOps concepts are highly relevant to system
administrators who are assessing and repackaging applications for deployment,
whether they are server or client-based. They need to clearly see application
components, dependencies, limitations, and configurable options, and be able to
make required changes to create the best fit within their environment. They can
be assisted in this by having the information delivered in a useful way by the
developer of the applications, even if they never interact directly with the developers. 

According
to Gartner, DevOps principles include:

  • Separate code from configuration
    (recognize that both are equally important artifacts)
  • Instrument pervasively (be able to
    detect trends as quickly as possible)

Solutions
should enable both application developers and operations/system admins to
create this type of configuration and instrumentation data, access it and
update it. This should span all the formats that the application takes, whether
traditional or virtualized. Using technology and formats that are common across
the developer and operations/system administrator groups will aid in this
effort.    

A final thought…most of the discussion around
DevOps today refers to internally developed apps, where both the developers and
operations personnel are in the same company. They are in the best position to
communicate and work more collaboratively. The same concepts can apply, though,
when one of the two parties is an outsourced organization. The organizational
boundaries may add some challenges, but a similar set of DevOps benefits exist.
The concepts can even be applied in the vendor to customer relationship, with
the potential to impact the whole software market.

 

 

email

Written by , Posted .