CloudBees sponsored this post.
As they work through the processes of implementing DevOps in the enterprise, companies wrestle with many issues that ultimately determine the success of their projects. One of the most critical decisions they’ll make is how to set up their toolchains. Should they embrace an end-to-end, “walled garden” approach? Or rely on best-of-breed tools?
While there are arguments for either side, the pendulum has shifted significantly toward best-of-breed — which offers more flexibility and a greater ability to customize implementations based on individual needs. End-to-end toolchains can provide more consistency and standardization. But, with enterprises under pressure to innovate and do it fast, they can’t afford to rip out entire toolsets and replace them if their platform approach isn’t working. It’s always challenging to find a one-size-fits-all for the software delivery process that satisfies all needs well. Enterprises need to embrace choice among teams, technologies and tools to unlock innovation safely and effectively.
In the July 2019 Gartner report, How to Architect Continuous Delivery Pipelines for Cloud Native Applications (Gartner subscription required), analyst Traverse Clayton states:
“Consider all the tools you select to be loosely coupled from one another so they can easily be composed to work with other toolchains. Choose best-of-breed tools and ensure that they integrate well with other best-of-breed tools.”
The Pros and Cons of a Walled Garden Approach
A one-stop-shop approach to the DevOps toolchain can help large organizations that are struggling to standardize processes and are dealing with a large number of unique applications. It can make it easier for operations engineers to jump in and out of projects, without knowing the intricacies of specific applications.
The best argument for a walled garden approach today is the Apple ecosystem. Steve Jobs’ vision for integrated iPhones, iPads, HomePods, MacBooks and a host of Apple-only services (including payments, music, and streaming TV) presents an enviable user experience. But this is difficult to pull off, and all-in-one approaches rarely end up delivering on their promise. It inevitably involves compromising somewhere.
Anybody who’s assembled a DevOps toolchain knows how many moving parts have to work together to create a high quality, coordinated process. Tools help to move applications across a long and complicated pipeline — performing functions ranging from version control, continuous integration, artifact management, test automation, environment automation and configuration, release management, log aggregation and search, metrics tracking, team communications, and reporting.
Given how quickly software delivery is changing — as are the tools in use to accelerate and automate it — it’s important to choose best-of-breed tools that are purpose-built for the job at hand. They also must easily integrate into your environment. That way, when a new technology or capability comes along, you’ll be able to add it to your pipeline process with minimal disruption; it will truly be a value add for your software delivery process. Being stuck with a single, lightweight toolset that does only some things well and cannot enable you to take full advantage of new tools or technologies, can cause a significant amount of pain for organizations trying to adopt and evolve their DevOps environments.
A best-of-breed approach offers the following advantages.
Avoid Vendor Lock-In
Picking multiple vendors for different toolsets complicates the procurement process, but it’s worth it to take advantage of new technologies when they get introduced. The whole point is to be able to adopt best-of-breed tools continuously, not just up front. There’s always a better way to do it tomorrow, and if you’ve bought into one vendor, you’re beholden to what that vendor comes out with. The cost of adoption may be low, but if the vendor has a captive audience it won’t face the competitive pressure to improve that product. If that platform a year from now looks the same as it does today, you’re stuck with the same set of tools.
Choose Tools That Don’t Restrict Use of Other Tools
Using a single platform solution, if you want to upgrade to a new release you often have to upgrade a significant number of other tools and/or custom integrations to the platform, to ensure that the platform remains functional for you. This is how people get stuck with a toolchain that can’t evolve. It becomes technical debt. It becomes harder each day to make a switch — and harder each day to accelerate software delivery.
Choose Level of Functionality at Each Spot Along Chain
It’s perfectly OK for your toolchain to include a few stellar performers with deep functionality and others that are slightly more pedestrian. Best-of-breed doesn’t always have to equate to the most expensive or advanced solution. The best solution for you might be one that includes fewer bells and whistles, but is better suited for a particular application. You get to be in control of that decision. When you’re buying into a walled garden, the vendor makes the decision about which functionality is “best in class” rather than letting you determine which tools are optimal to get the job done.
Avoid a Lengthy and Disruptive Integration
Whenever you scrap one set of tools for another, you have to make sure the outcome justifies it. That’s because the cost of switching is not just the price to install the new toolset, it’s the price of disrupting your people. If you take away two tools from a team, for example, you’re going to disrupt their productivity. Then, if you swap out the whole set of 10 best-of-breed tools for a single platform solution, you have to retrain — and reorient — the whole staff. It’s harder to train 800 people to swap out 10 tools than 50 people to swap out two. You’re better off being able to switch a single tool out or adopt a new tool, in small batches, team-by-team. Upgrade the tools you need to upgrade today or integrate a new set next year — at your pace. With a single platform solution, it’s all or nothing. You may have to jettison all the tools in use and switch over all 800 developers at once. That is a major disruption to the software.
It Allows You to Scale your DevOps Implementation
One could argue that buying a “DevOps in a box” gives an immature organization the ability to launch a DevOps effort quickly and seamlessly. But this approach drastically oversimplifies what organizations should try to do with DevOps. It’s not about getting a bunch of tools in place as quickly as possible. DevOps is about understanding your process and what you’re trying to achieve; understanding where your weaknesses are culturally, process-wise and tools-wise; and making a plan to create a future state where you’re much more productive and much more able to meet the needs of the business. Making all these decisions at once is like creating an outmoded “waterfall” delivery system: You do it and you’re done with it. The fact is, you’re never done. Toolsets should be set up to evolve, incorporating technologies from today, tomorrow and the day after tomorrow.
Today’s business environment is moving rapidly. Enterprises are adopting new technologies and new processes to keep pace, and creating systems to deliver mission-critical, revenue-generating applications across legacy, traditional and modern applications. Having a flexible, functional DevOps toolchain is critical to their mission. Best-of-breed technologies that integrate with each other and respond to future requirements give enterprises the best chance to meet their evolving business needs.
Feature image from Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: email@example.com.
The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.