It’s Time to Add Centralized Compilation to Enterprise IT Self-Service
With the ongoing evolution of self-service IT, along with the maturity of the infrastructure supporting it, we’re seeing more and more companies taking the next step. These are companies leveraging the self-service IT paradigm to add another mission-critical resource to the self-service portfolio: compilation.
Self-service IT is not a new concept. For years, it’s been helping IT and dev teams (not to mention other departments) strike the right balance between agility and control. Self-service environments enable dev teams to access a pre-approved catalog of services like storage, computing, networking or multi-tier app stacks – from wherever they are and whenever they want.
This model is win-win: it eliminates bottlenecks for dev teams while maintaining a level of control that IT can live with – securing resources with usage quotas, cost controls, role-based access controls and permissions, implementing compliance measures, and setting up the approval workflows that are so crucial for visibility and effective management.
With the ongoing evolution of self-service IT, along with the maturity of the infrastructure supporting it, we’re seeing more and more companies taking the next step. These are companies leveraging the self-service IT paradigm to add another mission-critical resource to the self-service portfolio: compilation. The reason? Long build times are reported as the number one impediment to productivity by enterprise developers. Here’s how this looks in action:
The Challenge: Time-to-Market on a Global Scale
Adobe, one the world’s best-known names in video, design, photo, and UI/UX software, is a unique enterprise in the sheer scope and scale of its worldwide development operations.
A by-product of the company’s monolithic product portfolio and globally distributed development team was a consistently sluggish compilation pace. Version rollouts and iterations were slowed as dev teams waited hours for builds to run on server farms – sometimes even resorting to compiling on local machines. This impacted productivity, of course, but also degraded developer morale and innovation.
Seeking a solution to mitigate slow build times, Adobe decided to centralize their build environment – offering distributed compilation on a self-service basis to dev teams to avoid investment in additional hardware, while still markedly growing speed and flexibility.
On another continent, a large German financial services integrator called DATEV reached the same conclusion. That company’s centralized coding team supported some 800 developers working on a tightly-coupled portfolio of around 150 products. But their build times were such that releases were limited to twice a year – rather than a weekly or monthly release schedule. DATEV, too, decided to move to a centralized build model to achieve faster revenue growth, higher operating margins, and faster innovation.
Making it Happen
The choice for both companies was clear – give dev teams what they need, while keeping IT firmly in control – ensuring ironclad security and keeping costs and SLA/uptime in check.
The DATEV team implemented Incredibuild to facilitate a distributed centralized compilation self-service model – seamlessly allocating idle cores across their network or the cloud to maximize build performance and reduce costs. And it worked. DATEV dev teams could now build with much greater frequency and accuracy – reducing build times through distributed processing, and enjoying quicker iterations. What’s more, teams could quickly discover “who broke the build” earlier in the dev cycle – leading to faster issue resolution, better overall quality and lower expenses.
At Adobe, the Platform Infrastructure team architected multiple clusters of build nodes, then offered Incredibuild as part of their centralized self-service IT portfolio. They called the new model HPC – High Performance Compiling – and this is exactly what dev teams anywhere in the world received, on-demand. Incredibuild’s distributed computing model enabled Adobe to more effectively exploit existing computing resources – turning each host into a supercomputer by harnessing thousands of idle cores already available in the network or in public cloud spot instances.
At both companies, build times shrank dramatically. At Adobe, the drop was from 7.5 hours to 15 minutes. At DATEV, the full 150-product portfolio build dropped some 60% – from 8-9 hours to just 4-5 hours.
And the savings from this sea change weren’t limited to developer time and satisfaction, or time to market. Incredibuild also paid off in terms of hardware CapEx and OpEx – helping defer the costs associated with farms of multi-core servers by more effectively sharing computing resources globally. These were resources that the companies already owned, but couldn’t harvest to accelerate CPU-intensive jobs due to a lack of distributed computing capabilities.
What’s more, the move to a self-service distributed compilation model represented a tectonic shift in company culture for both DATEV and Adobe. Despite their vastly different scale, both organizations were looking for the same thing: to move faster and more flexibly to meet customer and market demands, and to do so while growing and empowering teams to be nimble enough to innovate, launch new products, and try new processes. Creating a centralized self-service compilation paradigm was a key step toward reducing bureaucracy, breaking down organizational silos, and ensuring long-term competitiveness.
The Bottom Line
The concept of centralized IT is to offer specialized services to well-defined internal audiences with lower technical overhead and expense. In today’s enterprise ecosystem – where even traditional organizations are to some extent software development companies – more and more IT stakeholders are realizing that providing centralized compilation on a self-service basis is both cost-effective and productivity-enabling. Moving compilation to a dedicated, centralized platform lowers the backend burden on dev teams, speeds compilation time using distribution to shorten build duration, and shifts the technical nuts-and-bolts back to IT, where they belong.