To build or to buy? That is the DevOps toolchain question
An organization should assess its strengths and weaknesses before choosing a DevOps toolchain. A pre-made pipeline is simpler than individually collected tools, but it sacrifices flexibility.
IT would be so much easier if you could simply buy DevOps.
There's no promise of instant gratification with DevOps. It's a mindset and approach to software development and release processes, not a product category or specific certification. Yet, the pressing question for many adopters is how to build -- or buy -- the right DevOps pipeline.
Although organizations across industries and IT practices adhere to DevOps principles and best practices, details of DevOps toolchains and processes are often idiosyncratic. There's more than one way to implement and automate application development, release and support, with a good deal of simple preference for one tool or another leading the way.
DevOps is a tool-centric philosophy, according to Gartner. Since DevOps is ideally entwined with other software development and IT processes, it's inherently resistant to cookie-cutter tool set standardization. A vibrant ecosystem of mostly open source DevOps products is available to automate and streamline aspects of the software delivery pipeline. Some companies sell end-to-end DevOps toolchains. What's that again about not being able to buy DevOps?
A prefab DevOps toolchain is appealing because it eliminates the work to integrate discrete tools, particularly open source projects that require DIY customization. Some IT organizations, particularly those new to DevOps, Agile development and continuous delivery, prefer to adapt to an opinionated workflow defined by a particular product. The vendor manages the toolchain integration, for a price. Even if cost isn't a deterrent, this approach should be aggressively vetted by any organization that already has a set process flow and application lifecycle management tactics in place.
An enterprise DevOps pipeline incorporates continuous integration and delivery.
Cloud-managed DevOps tool sets
An IT organization that develops applications on a predesigned platform or infrastructure-as-a-service stack will likely be comfortable adapting to a process designed for that platform as a service (PaaS) or IaaS setup. Cloud Foundry, Microsoft Azure App Service and Amazon Web Services (AWS) are among the options for businesses that want cloud-managed services to supplement or circumvent a lot of IT admin resources.
AWS is one example with several services that target various segments of the development lifecycle and DevOps toolchain. AWS CodeStar is a cloud service intended to simplify DevOps pipeline configuration. Users develop, build and deploy applications via a set of project templates for core AWS services, such as Elastic Compute Cloud (EC2), Elastic Beanstalk and Lambda. There are five supported languages and various integrated development environments (IDEs) to choose from.
CodeStar provides a software project management umbrella with a single interface to AWS tools. Via CodeStar templates, a user automates application infrastructure provisioning -- for example, on EC2 -- and provisioning of other AWS developer services. It pulls together a range of services:
the Git code repository CodeCommit;
CodeBuild for build and test automation;
CodePipeline for continuous integration and continuous delivery (CI/CD); and
CodeDeploy and CloudFormation for code and infrastructure deployment.
CodeStar also enforces roles and security policies via AWS Identity and Access Management, so team members can join a project without major interventions.
CodeStar is only appropriate for projects targeting AWS, and this is the key buy vs. build choice that faces any DevOps toolchain implementation: Well-integrated products typically work on only a particular platform or development methodology. AWS customers that prefer to build their own DevOps pipelines on the cloud product can eschew the service.
What's that again about not being able to buy DevOps?
CodeStar is just one example of an opinionated DevOps process. Another comes from the Cloud Foundry PaaS stack, which sees use in some of the largest enterprises. Cloud Foundry's PaaS comes with the BOSH infrastructure management utility for software release engineering, deployment and lifecycle management, including monitoring, failure recovery and code updates. Microsoft cloud customers can turn to Azure App Service to set up a CI/CD pipeline on the Visual Studio Team Services (VSTS) suite of code, package, release and project management tools that are already integrated with the vendor's IDE and cloud services.
Degrees of openness in a custom DevOps toolchain
Packaged DevOps pipelines are not completely exclusive and have ways to integrate a select group of supported developer tools, usually Git, and IDEs, such as Eclipse. For example, AWS CodePipeline and CodeBuild can use GitHub to trigger code compilation, tests and deployment packaging. Similarly, CodeStar gives developers their choice of editing environments with connections to Eclipse and Microsoft Visual Studio, ensuring that code changes automatically feed into a CodeStar project. Similarly, VSTS' open interface relies on representational state transfer APIs and HTML, JavaScript and CSS to connect with third-party software. This extensibility has spawned a VSTS marketplace of compatible development products.
When an IT organization creates its DevOps pipeline from scratch, it typically turns to a CI tool -- Jenkins, Travis CI and CircleCI are popular -- for the integration hub. To splice open source software into the CI/CD pipeline, users must work with the CI tool's method to connect the code repository with the build pipeline. For example, Jenkins relies on plug-ins, while Travis CI uses a YAML configuration file. Many organizations also want code changes and builds to automatically trigger notifications on a social communications channel, such as Slack or Atlassian Hipchat. The connection to outside tools often originates on the CI platform, making it a fundamental choice for the rest of the DevOps pipeline.
Organizations that don't want to use an opinionated PaaS stack and its pre-defined toolchain, yet don't have the time or expertise to stitch together and manage a myriad of DevOps point products, have another option: managed services. CloudHesive, iTMethods and TriNimbus are just a few of the DevOps managed service providers (MSPs) working with enterprise IT shops. MSPs can provide customizable DevOps environments and software support.
As with any make vs. buy decision, the choice of a packaged or custom-built DevOps toolchain comes down to several factors: an organization's expertise and comfort with open source software deployments, its willingness to adapt to opinionated processes versus a need for maximal freedom in tool selection and integration and its use of PaaS stacks that favor a given methodology.
