Why teams create DevOps platforms to match projects
Prebuilt platforms offer a wealth of capabilities without the hassle to integrate everything. But cherry-picking for exact needs yields tighter resource management.
The iterative DevOps cycle through plan, build, integrate, test, deploy, operations and feedback is virtually universal. However, DevOps is all about process, and there is no single universal means to complete each step in the cycle.
An array of tools exists for everything from development to testing to deployment and monitoring, which means many ways to create a DevOps pipeline exists. The sheer variety of tools available for every step of a DevOps cycle is a blessing and a curse. Companies can tailor a DevOps platform for each project, based on team, business or technology requirements.
There even can be multiple DevOps platforms in one organization. For example, XYZ Company uses the Microsoft Visual Studio integrated development environment (IDE) for code creation and initial debugging. It automates the DevOps process flow with the Jenkins continuous integration server. However, teams tailor the DevOps platform to suit their needs. In the consumer cloud app team, Git provides version control; a build repository, tests builds come from Selenium; Puppet configures infrastructure for deployment. The orders management app team chooses Subversion for its code/build repository, Water for testing and Chef for configuration management. Both teams deploy to Microsoft Hyper-V VMs, which helps standardize IT management and maintenance in production.
Custom DevOps platforms must remain modular and flexible in the face of change. Organizations can implement a new combination of tools when business requirements change. Re-evaluate tools' capabilities periodically and replace tools when a better option appears. When a vendor updates or changes a tool, evaluate the new version and how it will affect the existing DevOps workflow. Don't upgrade unless it is a good fit.
When IT teams acquire DevOps tools in prefabricated combinations, they must accept vendor lock-in, as well as unilateral changes to the individual tools in the platform.
How to select DevOps tools
The biggest obstacle to construct a custom DevOps platform is the mix of tools.
A team might choose specific DevOps tools for the platform because they prove easier and faster to integrate than competitive offerings, or because they have the most extensive or desirable feature sets. In enterprise IT shops in particular, vendor support is a major consideration.
DevOps organizations also put together a software delivery and deployment platform based on the application project's coding language, particularly if that language is uncommon. For example, a team can opt for a stock software IDE that supports common languages such as C++, .NET and Java. But a relatively new programming language such as Go typically prompts a team to use the build, test, run and related tools included in the Go distribution. Similarly, a development team working on a Windows mobile application might prefer a testing tool such as Visual Studio Ultimate or Ranorex over a more common automated testing tool such as Selenium, because Selenium does not support testing for Windows mobile applications.
The biggest obstacle to construct a custom DevOps platform is the mix of tools. In many cases, the platform comes together as the result of evolution, starting with various components that are already well-understood and proven. From there, the team can vet and add on the minimum number of other tools needed to complete the DevOps workflow cycle.
Disadvantages of rolling your own platform
Although custom DevOps platforms provide noteworthy benefits, they also require work. Each tool selected for a DevOps platform must operate with other tools along the workflow, and all tools must be compatible with the IT environment, such as host OSes in use.
Complexity, such as compatibility and integration challenges, often gets overlooked until it is too late. For example, Chef is a configuration management tool that uses agents for normal operation. A company that does not allow agents on production systems might prefer Ansible in the DevOps platform. However, Ansible must run on a Linux host, so a predominantly Windows-based IT team will have to evaluate the additional work required to deploy Ansible in-house. Additional tools, such as the integration platform VersionOne Continuum, facilitate the workflow through disparate DevOps tools.
It's no small feat to deploy and support a diverse array of DevOps tools in multiple platforms, especially with the likelihood that some or all of them will use open source tools that lack enterprise-level support. Organizations could require separate IT staff to properly deploy, integrate, support and maintain these DevOps tools. Consider paid licensing with real-time support options in lieu of constant platform maintenance in-house.
While a custom DevOps platform meets the exact needs of one DevOps team or project, the same tool set won't always suit another team or project within the division or enterprise. It's expensive and time-consuming to build and maintain custom DevOps platforms for each application or type of application. Organizations should evaluate whether customization gives an application a worthwhile advantage.
A growing number of vendors and consulting firms preselect and preintegrate tools for DevOps teams, products that are sometimes called DevOps as a service. AWS CodeStar, for example, is a software project toolchain hosted on AWS infrastructure. Vendors that offer integrated tool sets also have a single support and maintenance umbrella over the entire DevOps platform. For example, IT can contact AWS CodeStar support to help with moving builds from the AWS CodeCommit repository to an Amazon Elastic Compute Cloud instance through AWS CodeDeploy. By contrast, it is a more cumbersome exercise to isolate and correct a problem moving builds from Subversion through Chef to a Hyper-V VM. Organizations should evaluate prebuilt DevOps platforms from various providers against their needs, the demands of an important project, skills in-house and the budget.
It's not a mutually exclusive choice between prebuilt, standardized and customized DevOps platforms: One organization might permit a highly tailored setup for a crucial customer-facing application while mandating a particular set of tools for all other projects, to simplify maintenance.
Dig Deeper on Systems automation and orchestration
