The question of buy vs build is often a very difficult one. On the one hand, you get everything exactly as you want it, on the other, you have to compromise, but implementation cost and support is lower. This is the dilemma one of our clients was experiencing. They had a home-grown deployment and release tool that worked exactly as they needed when they built it, but it was starting to show some signs that it was in need of an overhaul. The current architecture wouldn’t support some of the newer features that were in industry-leading products, and they were spending a lot of time supporting and maintaining it instead of building new features to move them forward. In addition, their aging infrastructure was pushing them to evaluate if their solution would support cloud deployments. It was time to re-evaluate the situation and determine if it made sense to continue with their solution.


The existing platform was managing the build and deployment of their Platform as a Service (PaaS) to over 80,000 individual physical nodes, each one potentially having its own configuration. The configuration being unmanaged and uncontrolled made it nearly impossible to support and troubleshoot all of the possible issues. Our expert in DevOps looked at their problems, what they were trying to achieve, and created a proof of concept (POC) for them to try out. The POC involved using Azure to manage the build and deployment process that would span the cloud and on-premise nodes, but it would also allow them to build and deploy configurations. He created release process templates and run books to allow easier management of the process and provide a graphical representation of what was happening. The deployment tool would periodically audit the environments for compliance with the configuration templates and fix the problems it discovered without user intervention. If they wanted to change the configurations, they only needed to update the template and it would blast it out to all of the subscribed nodes nearly instantly.


The Azure deployment system would allow them to manage not just the potential cloud environment, but it would also allow them to better manage their existing infrastructure as they started the transition. They could immediately start building their standard configuration and deploy that to the entire environment, giving them a base with which to start for support. Configuration management was vastly simplified and compliance could be all but guaranteed. An as of yet untapped benefit is that this will enable them to migrate to a cloud environment that can be scaled based on actual need, not worst case scenario. They can now choose based on actual computing need rather than having to buy the biggest server they think they’ll need, leaving lots of unused potential untapped and driving up the cost of implementation.