This post is from the XebiaLabs blog and has not been updated since the original publish date.
Build vs. Buy: The High Cost of DIY DevOps
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.
The Cost of DIY: Real-World ExamplesA 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.
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.
- 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
- 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.