There is a confluence of multiple different technology changes that are heavily influencing how enterprise IT must work. Virtualisation, cloud, software-defined everything, big data, everything as a service -- are all forcing IT to change and look at a new beast called DevOps.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The majority of changes to the IT landscape are aimed at speed -- speed of response of applications for users; speed in the ability to change functions, applications and processes to better respond to the organisation's needs.
The old ways of doing IT are forced to change. A traditional IT project plan follows a long timescale -- developing solid project management criteria with user definition documents, project plans, reviews, change management processes and so on and is planned over an 18-month timescale.
The problem here is that solving a problem 18 months out is not solving the real issue, which may well have disappeared by then and been replaced by half a dozen new ones.
To the rescue rides DevOps -- essentially, bringing the development and operational teams closer together through automation to support the speed of change the business requires.
DevOps is an IT practice of merging the tasks performed by a company's application development and those performed by the systems operations teams. Software-defined infrastructure and cloud computing call for enterprises to tear down the silos between the development and operation teams.
Historically, the development team has tended to work as a self-contained unit, working away on its projects against the various definition documents until they have created what they see as a completed application. It then goes through a test phase -- generally still under the nominal auspices of development -- after which the operations team takes control of the application and rolls it out to the masses.
If, as often happened, the new application had a few teething troubles, development would get a list of these from the help desk, would put them through a fairly rudimentary prioritisation -- "Does this look interesting?" -- and make the changes it thought necessary within its walled environment, submitting the next iteration of the application for testing and roll out as and when.
If, however, there were more than "teething troubles", all hell would break out. Applications that had major troubles in the operations environment would need to be rolled back and the underlying data re-synchronised to the old application so that employees, partners and customers could work again. The development team would be presented with what the problems were and would be scratching their heads as it had all worked in their environment.
Working in isolation leads to frustration and inefficiencies, as each team does not understand the limitations or challenges of the other. But more crucially, IT and the business are both badly affected.
Technology focused companies such as Facebook, Yahoo, Yammer, Amazon, Google and VMware have all embraced DevOps.
How DevOps solves the silo issue
Development staff have to be more closely involved with operations staff -- and with the entire operations environment. Development should be able to be carried out against real data sets wherever possible, so that any issues can be found at the earliest possible time.
The key to DevOps is in automating as much as possible -- both in how the process of moving a development project through testing into run time occurs, and also in how any operational problems are dealt with.
Projects have to be broken down into smaller chunks -- required functionality has to be strictly prioritised and the development team has to work to get a functional system out into the operations environment rapidly to meet the highest priority issues. "Rapidly" should be measured in weeks -- a rule of thumb should be that first roll out must be within 12-18 weeks.
This drives the need to move from monolithic applications to composite ones built by pulling together functions from various sources. Existing functionality from within the datacentre should be combined with cloud apps and services, so that the wheel is not continually re-invented, using domain expertise and data sets that add value to the overall composite app where applicable.
Testing should be carried out either as a parallel implementation in the run-time environment, so that more performance issues can be picked up at the earliest possible stage, or in a pseudo-live environment with a set of "tame" testers from the actual users.
For the parallel example, this should be relatively easy through the use of virtualisation. Copies of existing databases can be spun up against virtual machines running the DevOps code. Testing can then be carried out against the existing network loads so that performance is evaluated at the same time as the efficacy of the code.
Ensure that exceptions can be rapidly and effectively handled. The testing phase is where people power really counts -- they can perceive patterns of usage and problems in how people are using the application far more effectively than computers can. Throw a lot of people at the testing phase -- monitor and measure everything that you can.
Once the testing phase is done, it should then be a case of just switching the application over to the live database and the users over to the new code.
Remember that DevOps is, by its very nature, an iterative process. Getting a 60%, 70% or 80% solution out means that a further 40%, 30% or 20% is still required. The aim should always be to solve a prioritised proportion of what is left, plus whatever else has come up as new requirements since the last code was rolled out.
How to make your DevOps strategy fruitful
As much as possible needs to be automated -- as code elements are completed by the development team, integrated and fully audited capabilities to move these elements through from development to test and then to the run-time environment will help ensure that incremental changes and improvements can be made.
Roll-back can also be automated -- although a well-run DevOps programme should not require roll-back to be carried out, it should always be available as a Plan B. Being able to get back to a known position -- comparable to a backup and restore recovery time and recovery point objective (RTO/RPO) -- should be part of any DevOps setup.
Feedback also needs to be automated. There is no point in waiting for the help desk to aggregate comments and feedback and report that through to the DevOps team. Capture feedback as part of the application; ask for feedback as part of the process. Act on the feedback according to how much it is impacting the business -- not how interesting the problem sounds from a technical level.
Overall, DevOps is an excellent approach to speeding up how an IT department can ensure that it is meeting the needs of the business. However, a badly implemented DevOps approach will lead to more errors and users being unhappy with the experience they receive.
It requires deep cultural and organisational change and that involves changing behaviour -- a lot. It means throwing out decades of embedded explicit and implicit practices. It involves telling the veterans accustomed to running things that much of what they know and do every day is obsolete, and that is hard.
Just putting development and operations team together in one room will not lead to a successful DevOps strategy -- each team must understand and appreciate the importance of working together in the cloud and software-defined era.
Automating, incentivising development and operations team to work together, allocating time for training employees, developing new enterprise architecture standards around build-to-operate principles and aligning IT with business objectives are all steps to ensure a DevOps strategy is not undermined.
Ensuring that a few simple areas are covered off will help to make DevOps work well.
Learn the steps that make DevOps work