Why DevOps Is Different for Big Firms

As cloud computing matures, we hear more and more about DevOps. DevOps is a new term — not a new idea. It’s the effort to be sure that Development and Operations work together. Ensuring that the Dev and Ops work as a team has always made sense, and it especially makes sense today moving from Waterfall to Agile software development.

Here’s why: imagine you work for a large retailer (traditional, not a startup). You want to respond to new consumer demands, so that means creating a website. It also means integrating your traditional selling systems into the website through ecommerce. Now let’s say you want to add a customer loyalty key fob that ties in-store purchases to the website.

Not only do you need to deliver quickly, but you need to deliver all of your solutions at web-speed. Web-speed means Agile Pods must drop code (or want to drop code) every two or three days.

Herein lies the problem and opportunity: Dev wants to drop code every two or three days, but Ops needs seven days to approve a change and up to eighteen weeks to provision a new infrastructure. See the issue? From the Dev point of view, Ops is perhaps the single greatest issue to delivering the value promised by Agile and PaaS.

DevOps in large firms is an effort to optimize the software release process (including the underlying infrastructure). Since Ops is the slower of the two, Ops is the area we need to examine. Of course, any solution requires a change in both Dev and Ops.

Ops has certain needs:

  • What changes: Companies of all sizes must meet significant regulatory requirements: HIPPA, PCI, SOX, GLBA just to name a few common ones. Change Management, usually in Ops, is normally charged with keeping the records that show the changes to production systems. Change Management is also typically the team that schedules release windows.
  • Provisioning: Services, storage, middleware, operating systems, and networking all play a part in creating the infrastructure the new application will integrate into. Coordinating these requirements through automation is critical to DevOps.
  • Feature information: Someone has to respond to customers using the new software. That is Ops’ primary job. Ops needs to know how the new software is supposed to work as well as how it works with the existing systems. Pushing new features into product should include positive feedback from Ops.
  • Features not working as expected and workarounds: All software has bugs. A list of bugs and workarounds can save the business a lot of money. Ops can resolve customer issues faster if they know what doesn’t work in advance, so before a new release goes into production, Dev needs to inform Ops of any known errors so they can respond accordingly.
  • Systems dependencies: Ops needs to know how the updated app might affect the infrastructure. For example, will it create significant additional load on the local area network (common for internal apps) or perhaps tax the mainframe? Did engineering help Dev? Hopefully they know this before the new software takes entire selling systems down.

Most of these are information requirements that are easily satisfied if the Agile team develops them during the sprint. If the requirements are put off until the end, company can wind up with outages and lost revenue.

Related Posts
Cloud Computing Training
DevOps Training

In this article

Join the Conversation


  1. Alan Nance Reply

    This is an excellent, simple piece that explains the issue perfectly.

  2. Global Knowledge Training Blog » Making Change Management Your Cloud Computing and DevOps On-Ramp Reply

    […] Posts DevOps: It’s Different for Big Firms PaaS for Application […]