Tools Consolidation – Too Much of a Good Thing?

Over the last few years I’ve spent a fair bit of my time leading Empowered’s Monitoring Tools Assessment practice. In this role, I work with customers to help them understand what capabilities they have, how those compare to the operational requirements they are trying to meet, and provide recommendations on how to close the gap.

There are many reasons that organizations engage me for these assessments but one that shows up consistently is a stated need for tools consolidation. Most often this is described as a desire to simplify the tool set providing their operational capabilities with an aim to reduce the amount of resources and expenses being applied to the maintenance of the tools.

When Tools Consolidation Makes Sense

For some use cases this makes a lot of sense. Take Application Performance Management (APM) for example. There are a number of Gartner top right Magic Quadrant players to choose from, all of which provide very compelling solutions to the instrumentation, analysis, and visualization of applications. In fact, until you start moving into some pretty specific edge cases, it can be difficult to make a compelling reason to choose one over the other. 

Getting to these edge cases requires a certain level of maturity. It’s not uncommon to see organizations that, given where they sit on the maturity scale, never approach the edge cases at all. In these situations, success or failure of an APM tool’s implementation is tied more to the ability of the customer to execute than a technical limitation imposed by the APM vendor. As a result, the decision on tool choice is driven by which vendor offers the most compelling commercial terms rather than technical fit, because they all fit.

Under these circumstances, if we see multiple instances of different APM solutions in play at the same customer, tools consolidation makes a lot of sense. Streamlining the resources and costs associated with implementing, running, and training for multiple APM tools down to one offers some clear consolidation wins.

If Some Is Good, Then More Must Be Better

Like so many other things in life though, too much of a good thing can be a problem. A laser focus on consolidation to the minimal tool set possible can lead to a situation where everything is considered only in terms of the competitive overlap it has with other tools in the environment rather than looking for opportunities to create positive complementary interactions. Essentially you are optimizing along a single dimension measured by the ratio of tools to the capabilities provided.

In the real world, it’s hard to optimize for one dimension without having impacts, often negative, on other dimensions. True optimization turns out to be a balancing act between all the factors that have impact on the organization. Ignoring this need for balance, you end up with the “everything looks like a nail” situation. Problem is, if you “optimize” down to a single tool, a hammer, then everything better be a nail. Sometimes it’s worth taking a step back to see whether there is value in being a bit more granular in your capability definition.

A Concrete Example

Let’s use Load balancing as an example. Traditional load balancers have become a staple in IT environments because they provide a solution for access and resilience while running applications at scale. This is true for both stateless conditions as well as situations where state needs to be maintained between the client and the application served by a pool of components.

The ability to handle these more complex cases (session state, etc.) drives the need for a certain amount of additional functionality. The end result is a single platform that provides a solution for all types of load balancing from simple through to complex in a single tool. Seems like a great opportunity to consolidate on a single tool to provide all load balancing needs.

Unfortunately, the ability to handle complex load balancing scenarios generally mandates that the load balancer be more complex and, therefore, more costly both in equipment as well as its administration. Manufacturers are forced to pass these additional costs onto the customer in order to make their own business viable. You can’t expect to get something for nothing. 

Making Capability Requirements More Granular

The reality is that for a significant portion of load balancing, the requirements are much simpler. For instance, a stateless connection model just needs a traffic router to direct client requests to a pool of health validated servers. By splitting the load balancing capability into simple and complex, it now makes more sense to take a service like DNS, that already acts in the capacity of a router, and extend it to add pool health checks and use it to route traffic from the client. We see such an offering in Infoblox DNS Traffic Control (DTC). By leveraging the existing DNS service that functions at the traffic control layer, there are no requirements for additional devices in the data path. This translates to implementation at a much lower cost. 

Clearly, something like Infoblox DTC is not intended to displace traditional load balancing completely. There are plenty of situations in which a traditional load balancer not only makes sense but is a requirement based on its broader set of capabilities. But that’s not the point I’m trying to make anyway. The point is that, from an overall optimization point of view, the inclusion of two products with the similar core capabilities (traditional load balancer and DTC) makes more sense than using only one or the other. One is optimized for complex use cases, but with an associated higher cost, while the other is optimized for simpler use cases, but can be much less expensive. A naïve approach to tools consolidation that over-optimized the set of tools down to a bare minimum of one tool for load balancing wouldn’t allow for this and would miss out on the significant cost savings.

Summing Up

As is often the case, there are no simple answers. As you move through your next consolidation to simplify your tools landscape, make sure that you don’t focus too much on eliminating any and all capability overlap to the detriment of other dimensions (such as cost). Balance is important – it is possible to have too much of a good thing!