Best of Both Worlds

Back in February of 2015, I wrote a blog asking a very simple question: how many vendors does it take to implement DevOps? At the time I wrote the post, I felt the answer was one. Almost two years later, I believe that now more than ever. So why do companies insist on manually building a pipeline instead of using a unified solution?

Fear of Vendor Lock In

Despite the fact some vendors offer a complete solution, many still attempt to build DevOps pipelines using as many vendors as possible.

Historically, putting all your eggs in one basket has proved to be risky. Because the systems only provided an All or Nothing approach, users would lose the flexibility to adopt new technology as it was released. The customer was forced to wait for the solution provider to offer an equivalent feature or worse have to start over again with another solution. Customers started to avoid the benefits of a unified solution for flexibility.

This allowed the customer to adapt the hot new technology and be on the bleeding edge with their pipeline. They could evaluate each offering and select the best of breed in each area. On the surface this seemed like a great idea until they realized the products did not play well together. By this point, they had convinced themselves the cost of integration was unavoidable and just a cost of doing business.

This change in customer mindset had vendors focusing on having the best CI system or source control instead of an integrated system. With vendors only focusing on a part of the pipeline, there were great advances in each area. However, the effort to integrate continued to increase at an alarming rate. Eventually the cost of maintaining the pipeline became too great and actually started to have a noticeable impact on developer productivity.

Even when all the products play nice with each other, it can be difficult to enable good traceability from a code change all the way to production. This is the reason more and more vendors are starting to expand their offerings to reduce the cost and risk of integration.

Calculate True Cost of Ownership

When building your DevOps pipeline, you have to consider the true cost of ownership. The cost is much more than what you paid for the products. The cost includes the amount of time and effort to integrate and maintain them. Time spent on integration and maintenance is time not spent innovating on the software that makes your company money. To try and reduce the cost of ownership, vendors have begun to join forces (http://www.businesswire.com/news/home/20160914005298/en/DevOps-Leaders-Announce-DevOps-Express-Industry-Initiative). This should help mitigate the cost of building your own DevOps pipeline. Nevertheless, with each new tool and vendor, you incur a cost of integration. Someone on your team is now responsible for maintaining that pipeline. Making sure all products are upgraded and that the integration is still intact. This is time much better spent delivering value to your end users instead of maintaining your pipeline.

Adding vendors also complicates your billing, as you are paying multiple vendors instead of one. The opportunity for bundle or volume discounts is also reduced.

Best of Breed

I have meet many customers that claim they want the best of breed products. However, when I asked what made one product better than another, I often found that they did not even use that feature. They were complicating their pipeline out of vanity. Everyone else said this was the best so we wanted to be on the best. You need to find the best product for you which might not be the best of breed for that area. Just because Product A does not have all the bells and whistles as Product B does not mean Product B is the right one for you.

Best of Both Worlds

Today, customers want the ease of a unified solution with the ability to select best of breed. Solutions like Team Services offer you both. Even though Team Services offers everything you need to build a DevOps pipeline from source control and continuous integration to package management and continuous delivery, you are free to replace each piece with the product of your choice. If you already have an investment in a continuous integration system, you can continue to use it along with everything else Team Services has to offer. This can go a long way towards reducing the number of vendors in your pipeline.

We have taken a new approach with Team Services. It is an approach that tries to appeal to both types of customers: those that want a unified solution and those that want Best of Breed. We have teams dedicated to Agile planning, source control, continuous integration, package management, and continuous delivery. These teams work to make sure we stack up against all the offerings of each category. However, they never lose sight of the power of a unified system.

This approach reduces the complexity of building and maintaining your pipeline while retaining your flexibility to select products that are the best fit for your organization.