Application delivery

What Does DevOps Mean for Application Delivery?

Application deliveryIn the IT industry almost all of the enthusiasm (a.k.a., hype) is usually reserved for new technologies or new ways of implementing technology.  So why is there so much interest in DevOps which is a process, not a technology?  More importantly, how will the DevOps movement impact your ability to ensure acceptable application delivery?

The phrase DevOps is a result of bringing together two phrases: Development and Operations. That’s appropriate because the point of adopting DevOps is to establish tight collaboration between a number of the phases of the application development lifecycle, including application development, testing, implementation, and ongoing operations.  According to a recent Information Week Report, sixty-eight percent of IT professionals are aware of DevOps, and of those, twenty-one percent have currently embraced it.  That report also stated that eighty-two percent of the IT organizations that implemented DevOps saw at least some improvement in infrastructure stability, and eighty-three percent saw at least some improvement in the speed of application development.

There is no single correct way to implement DevOps.  Research that I did just over a year ago indicated that, of the companies at that time who had implemented DevOps, roughly half had established formal DevOps teams, while the other half had not, but had established goals and processes to link application development and operations.

One of the companies that has been very visible in discussing the benefits of DevOps is Netflix.  Netflix often discusses how DevOps reduces the amount of time it takes to get a new application or a new version of an application into production.   With that goal in mind, some of the key characteristics that are usually associated with DevOps are that the applications development team writes primarily small, incremental pieces of code that are tested on an architecture that reflects the production architecture.  Ideally, the network on which the software is tested will reflect not just the architecture but also the same characteristics (i.e., delay, packet loss) as the production network.

While reducing the amount of time it takes to get an application into production is a key goal of DevOps, it is not the only goal.  For example, assume for the sake of example that as part of the testing and modeling that is inherent in DevOps, that it is determined that the application that is under development is very chatty, frequently sends extremely large files and will perform very poorly if it is put into production without any changes being made.  As part of the development and testing process, the DevOps team would analyze alternative solutions.  One possible solution is that the application development team would modify the software to reduce its chattiness, and it could also decide to provide compression as part of the application.  Another possible solution is that the IT organization could decide to implement WAN Optimization Controllers (WOCs) to mitigate the performance bottlenecks.  Independent of which option the IT organization takes, performance bottlenecks were identified during the development and testing stages, an analysis of alternative remedies was performed and the bottlenecks were eliminated before the application went into production.

There are a number of factors that are impacting application delivery.  Some of those factors, such as the ongoing virtualization of WOCs, are technical in nature.  Some factors, such as the burgeoning interest in DevOps, are focused on IT processes.  The bottom line is that the IT environment in 2014 is very different than it was just a few years ago and as a result IT organizations need to take a fresh look at the technologies and processes they use to ensure acceptable application delivery.

About the author
Jim Metzler

Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.