Build vs. Buy: The High Cost of DIY DevOps

| July 26, 2018 | 0 Comments

Large companies early in their DevOps journeys may either be unaware of existing Application Release Orchestration (ARO) solutions, or they may feel that a DIY approach is the best way to build a release orchestration platform. Often, it’s a functional group that is simply trying to maintain their control and influence within the broader organization. A closer look at existing software, specifically the XebiaLabs DevOps Platform, illustrates that enterprises can deploy a release orchestration solution unique to their needs at a fraction of the cost of building it themselves. In our experience, the groups that initially perceive our platform as a threat to their fiefdoms often become the heroes for rapidly deploying a commercially ready solution while saving their company money.

DIY DevOps

The Cost of DIY: Real-World Examples

A XebiaLabs customer, a large US telecom provider, first attempted to build a release orchestration platform with their in-house development team. Building this foundation in-house tool required a tiger team of 30 of their most technically skilled staff, primarily using open source tools. The resulting software could coordinate and even automate a release process, but only at a modest scale.

The team introduced their new tool to different development groups but quickly realized that each of those groups’ applications were unique, and each project had different use cases. They learned that each group’s process to deliver an application was a unicorn. They realized that if everyone built their own path to Production, it created risk for the organization.

The result of their DIY approach was eye-opening:

  • High cost – Building and maintaining their in-house software required 30 fulltime employees x $150k annually = $4.5 million.
  • Poor scalability – They found it nearly impossible to scale across different applications.
  • Lost productivity – Substantial development resources were dedicated to building and maintaining the in-house tool rather than building new, value-adding software.
  • Poor visibility – The in-house tool provided no reporting capabilities and zero visibility into the release pipeline.

The company was at a crossroads. They could either continue spending time (years) and money ($4.5 Million/year) trying to recreate their in-house tool for each unique project and environment, or they could leverage a purpose built, extendable technology that would scale across their organization and provide value to every team. And they needed to do this in four months! They had also underestimated the importance of and need for reports across the organization; building this necessary insight would add even more time and expense.

This company chose XebiaLabs and deployed an enterprise DevOps platform in months at a fraction of their DIY cost. Plus, they instantly addressed their software’s limitations and added critical features and functionality without high development costs.

Another XebiaLabs customer, an enterprise that deploys satellites to space, also pursued a DIY approach before partnering with XebiaLabs. They tasked their five best engineers with building a release orchestration tool. The company was undergoing a transformation from simply delivering satellites to building software that powered satellite deployments. Consequently, time to market became critical.

Software delivery could mean the difference between meeting and missing a launch date. Waiting for their in-house team to build a release orchestration platform was a huge opportunity cost – those resources would have been better spent building new and required
features and functions.

They calculated that the DIY approach would prove costly:

  • High cost – Building and maintaining their in-house software required 5 fulltime employees x $150k annually = $750,000.
  • Lagging functionality – The in-house team was unable to keep up with maintenance and evolving environments.
  • Opportunity cost – The company waited three years for a solution to be built. They missed opportunities to add new features and functionality during that time.
  • Poor scalability – The in-house solution couldn’t scale across their organization.

These are just two examples. From our experience at XebiaLabs, the following is a general estimate of what is needed to pursue a DIY approach:

  • For release orchestration, a company would need to dedicate five people to build version 1 minimally viable product (MVP)
  • For deployment automation, an additional 5 fulltime employees are required to build a version 1 MVP

Even with the v1 MVPs built for both release orchestration and deployment automation, the resulting software would be designed for a particular use case. The v1 product would not be scalable and would require further development for additional use cases and deployment to multiple infrastructures. Building a v1 MVP would be just the beginning:

  • Once the product was built, a minimum of 3 fulltime employees would be needed to maintain the software, offer support, and manage backups.
  • The above does not include building and maintaining the necessary reports that would definitely be a requirement of every IT group, business unit, and relevant compliance auditors.

XebiaLabs: From Development to Production in Less than 90 Days at a Fraction of the Cost

Each example mentioned above features a company that first tried to resolve their application delivery challenges by building their own ARO platform. In both cases, the principals concluded that the effort to build and maintain release orchestration came at a much higher cost, couldn’t scale, and lacked key requirements. Partnering with XebiaLabs provided them with everything they needed for orchestrating a release pipeline, automating application deployment, and providing visibility into their entire process. Each company was able to improve and standardize their release processes at enterprise scale within four months.

Related Resources:


George Hamilton

About the Author ()

George Hamilton is the Director of Sales Enablement at XebiaLabs.