Greedy algorithms can result in the right solution in the end, but rarely do

Don and I were having a discussion with our oldest son the other night about writing a chess program. There are myriad options for implementing the learning aspects of a chess program, but this is not a task for the timid. He ended up proposing a much simpler solution (this was just an exercise in ‘can I write it’, after all) that would have essentially used a very greedy algorithm; one that made a decision regarding the computer’s next move based on current state of the board and what move would give it the most benefit right now.

For those of you not familiar with the concept, here’s a good definition from Wikipedia:

A greedy algorithm is any algorithm that follows the problem solving meta-heuristic of making the locally optimal choice at each stage with the hope of finding the global optimum.

The relevant (for this discussion at least) part of the definition is “making the locally optimal choice at each stage with the hope of finding the global optimum.” Greedy algorithms, it turns out, are not just for programming and developers, and imitate real-life more closely than we might think.

See, IT often makes it decisions using greedy algorithms. Choices are made based on what is optimal right now with the hope that it will also be optimal in the long run. Greedy algorithms can turn out to be “the right choice” in the long run, but it’s often because of luck (karma, chance, whatever) and not because of any great strategic thinking on the part of the decision makers.

We often see the use of greedy algorithms to make decisions when there is a problem with application delivery: performance, security, reliability. Because there is a problem right now that needs to be solved, well, right now, IT uses a very greedy algorithm that chooses a solution that is optimal now, but is often not the right choice in the long run.

What generally happens is this: an application has reached capacity, but usage is still growing. IT immediately executes a greedy algorithm, the result of which is to purchase a load balancer and a second server. Problem solved. But as usage grows so do attacks, and suddenly there crops up another problem, this time one of application security. IT again executes a greedy algorithm and comes up with a web application firewall. An acquisition and a deployment later and voila! problem solved.

But relatively soon after that performance begins to be a problem. IT, falling back on what it knows best, executes yet another greedy algorithm and comes up with another locally optimal solution: application acceleration. Another point solution is purchased and deployed, with a little more difficulty due to the growing complexity in the network and application architecture, and voila! problem solved.

You can see that as this continues the number of point solutions employed to solve problems that crop up is going to continue to grow, which is going to increase the costs to manage and maintain the architecture while simultaneously making it more and more difficult to troubleshoot any issues that may crop up in the future.

Using a greedy algorithm to make decisions about IT’s “next move” does not guarantee the optimal long term solution; it merely means that the optimal solution right now has been chosen.

That’s tactical thinking, not strategic thinking. And to be successful at (IT) chess you have to fit those tactical moves – which are necessary - into a broader strategy.

IT, like a chess grandmaster, needs to think more strategically when addressing solutions regarding the delivery of applications. Rather than view the chess-board architecture of IT as a set of connected but disparate squares, it needs to be viewed as a holistic battlefield across which a strategy can be employed that results in long term success.

We know that deploying applications requires long term consideration for scalability, reliability, security, and performance. At some point one or all of these concerns will be a problem in need of a solution in the data center. Rather than look at architecture of the data center with a greedy eye, it is more efficient – financially, architecturally, and from a management point of view – to look at the architecture with an eye toward an optimal solution that affords an opportunity later on to “make the winning move” when other issues crop up.

Early on you may have a need only for scalability or reliability. A load balancer is certainly an answer to those needs, but it is not the globally optimum solution. You need to sacrifice the pawn now in order to take the king later: investing in a platform now rather than acquiring a solution lays the foundation for a successful strategy to winning the IT chess game in the long run. A unified platform that allows IT to deploy additional solutions when (and if) needed reduces overall costs in the long run, simplifies the architecture – making troubleshooting and management less resource intense – and improves performance of applications by eliminating extraneous devices in the infrastructure that can add latency and points of failure.

Greg Ness said it best in his recent guest post here on DevCentral: “As the cloud tears down silos, one trick pony solutions (including freeware) will have an uphill battle for relevancy, especially as enterprises tear down silos. [emphasis added]”

Chess grandmasters aren’t one trick ponies; they don’t use a single ‘trick’ to win, they employ a strategy. Greedy algorithms can’t compete with a grand strategy because they don’t look far enough ahead. They buy for the now, they don’t invest in the future.

IT needs to stop using greedy algorithms if they are to architect the next generation data center and start using a strategy that takes advantage of innovations and evolutionary network and application network infrastructure to construct a data center capable of implementing solutions that are globally optimal. While it is possible to win using greedy algorithms a sound, thoughtful strategy with an eye toward the future of the entire data center will almost always trump the immediate, locally optimal solution.

Related blogs & articles:

• Five Key Questions Developers Need to Ask before Starting the Troubleshooting Process
• Your load balancer wants to take a level of fighter and wizard
• It’s like load balancing. On steroids.
• The Revolution Continues: Let Them Eat Cloud
• Guest Post: The 3 Major Barriers to Cloud Computing

• VAR Rejects Higher Priced Deduplication One Trick Ponies