It is very easy, when working in IT, to become focused on big, complex solutions.\u00a0 It seems that this is where the good solutions must lie – big solutions, lots of software, all the latest gadgets.\u00a0 What we do is exciting and it is very easy to get caught up in the momentum.\u00a0 It’s fun to do challenging, big projects.\u00a0 Hearing what other IT pros are doing, how other companies solve challenges and talking to vendors with large systems to sell to us all adds to the excitement and it is very easy to lose a sense of scope and goal and it is so common to see big, over the top solutions to simple problems that it seems like this must just be how IT is.<\/p>\n
But it need not be.\u00a0 Complexity is the enemy of both reliability and security.\u00a0 Unnecessarily complex solutions increase cost both in acquisition and in implementation as well as in maintenance while being generally slower, more fragile and possess a large attack surface that is harder to comprehend and protect. \u00a0Simple, or more appropriately, elegant solutions are the best approach. \u00a0This does not mean that all designs will be simple, not at all. \u00a0Complex designs are often required. \u00a0IT is hardly a field that has any lack of complexity. \u00a0In fact it is often believed that software development may be the most complex of all human endeavors, at least of those partaken of on any scale. \u00a0A typical IT installation includes millions of lines of codes, hundreds or thousands of protocols, large numbers of interconnected systems, layers of unique software configurations, more settings than any team could possibly know and only then do we add in the complexity of hundreds or thousands or hundreds of thousands of unpredictable, irrational humans trying to use these systems, each in a unique way. \u00a0IT is, without a doubt, complex.<\/p>\n
What is important is to recognize that IT is complex, that this cannot be avoided completely but to focus on designing and engineering solutions to be as simple, as graceful… as elegant as possible. \u00a0This design idea comes from, at least in my mind, software engineering where complex code is seen as a mistake and simple, beautiful code that is easy to read, easy to understand is considered successful. \u00a0One of the highest accolades that can be bestowed upon a software engineer is for her code to be deemed elegant. \u00a0How apropos that it is attributed to Blaise Pascal, after whom one of the most popular programming languages of the 1970s and 1980s was named is this famous quote (translated poorly from French):\u00a0“I am sorry I have had to write you such a long letter, but I did not have time to write you a short one.”<\/em><\/p>\n It is often far easier to design complex, convoluted solutions than it is to determine what simple approach would suffice. \u00a0Whether we are in a hurry or don’t know where to begin an investigation, elegance is always a challenge. The industry momentum is to promote the more difficult path. \u00a0It is in the interest of vendors to sell more gear not only to make the initial sale but they know that with more equipment comes more support dollars and if enough new, complex equipment is sold the support needs stop increasing linearly and begin to increase geometrically as additional support is needed not just for the equipment or software itself but also for the configuration and support of system interactions or additional\u00a0customization\u00a0 \u00a0The financial influences behind complexity are great, and they do not stop with vendors. \u00a0IT professionals gain much job security, or the illusion of it, by managing large sets of hardware and software that are difficult to seamlessly transition to another IT professional.<\/p>\n Often complexity is so assumed, so expected, that the process of selecting a solution begins with great complexity as a foregone conclusion without any consideration for the possibility that a less complex solution might suffice, or even be superior outside of the question of complexity and cost itself. \u00a0Complexity is sometimes even completely tied to certain concepts to a degree where I have actually faced incredulity at the notion that a simple solution might outperform in price, performance and reliability a complex one.<\/p>\n Rhetoric is easy, but what is a real world example? \u00a0The best examples that I see today are mostly related to virtualization whether vis a vis storage or a cloud management layer or software or just virtualization itself. \u00a0I see quite frequently that a conversation involving just virtualization for one person brings an instant connotation of requiring networked, shared block storage, expensive virtualization management software, many redundant virtualization nodes and complex high availability software – none of which are intrinsic to virtualization and most of which are rarely for the purpose of supporting or really, even in the interest of the business for whom they will be implemented. \u00a0Rather than working from business requirements, these concepts arise predominantly from technology preconceptions. \u00a0It is simple to point to complexity and appear to be solving a problem – complexity creates a sense of comfort. \u00a0Filter many\u00a0arguments\u00a0down and you’ll hear “How can it not work, it’s complex?” \u00a0Complexity provides an illusion of completeness, or having solved a problem, but this can commonly hide the fact that a solution may not actually be complete or even functional but the degree of complexity makes this difficult to see. \u00a0Our minds will then not accept easily a simpler approach being more complete and solving a problem when a complex one does not because it feels so\u00a0counter-intuitive.<\/p>\n A great example of this is that we resort to discussing redundancy rather than reliability. \u00a0Reliability is difficult to measure, redundancy is simple to quantify. \u00a0A brick is highly reliable, even when singular. \u00a0It does not take redundancy for a brick to be stable and robust. \u00a0Its design is simple. \u00a0You could make a supporting structure out of many redundant sticks that would not be nearly as\u00a0reliable\u00a0as a single brick. \u00a0If you talk in reliability – the chance that the structure will not fail – it is clear that the brick is a superior choice to several sticks. \u00a0But if you say “but there is no redundancy, the brick could fail and there is nothing to take its place” you sound silly. \u00a0But when talking about computers and computer systems we find systems that are so complex that rarely do people see when they have a brick or a stick and so, since they cannot determine\u00a0reliability\u00a0which matters, they focus on the easily to quantify redundancy, which doesn’t. \u00a0The entire system is too complex, but seeking the simple solution, the one that directly addresses the crux of the problem to solve can reduce complexity and provide us a far better answer in the end.<\/p>\n This can even be seen in RAID. \u00a0Mirrored RAID is simple, just one disk or set of disks being an exact copy of another set. \u00a0It’s so simple. \u00a0Parity RAID is complex with calculations on a variable stripe across many devices that must be encoded when written and decoded should a device fail. \u00a0Mirrored RAID lacks this complexity and solves the problem of disk reliability through simple, elegant copy operations that are highly reliable and very well understood. \u00a0Parity RAID is\u00a0unnecessarily\u00a0complex making it fragile. \u00a0Yet in doing so and by undermining its own ability to solve the problem for which it was designed it also, simultaneously, because seemingly more reliable based on no factor other than its own complexity. \u00a0The human mind immediately jumps to “it’s complex, therefore it is more advanced, therefore it is more reliable” but neither progression is a logical one. \u00a0Complexity does not suggest that it is more advanced and being advanced does not suggest that it is reliable, but the human mind itself is complex and easily mislead.<\/p>\n There is no simple answer for finding simplicity. \u00a0Knowing that complexity is bad by its nature but unavoidable at times teaches us to be mindful, however it does not teach us when to suspect over-complexity. \u00a0We must be vigilant, always seeking to determine if a more elegant answer exists and not accept complexity as the correct answer simply because it is complex. \u00a0We need to question proposed solutions and question ourselves. \u00a0“Is this solution really as simple as it should be?” \u00a0“Is this complexity necessary?” \u00a0“Does this require the complexity that I had assumed?”<\/p>\n In most system design recommendations that I give, the first technical determination step that I normally take, after the step of inquiring as to the business need needing to be solved, is to question complexity. \u00a0If complexity cannot be defended, it is probably unnecessary and actively defeating the purpose for which it was chosen.<\/p>\n “Is it really necessary to split those drives into many separate arrays? \u00a0If so, what is the technical\u00a0justification\u00a0for doing so?”<\/p>\n “Is shared storage really necessary for the task that you are proposing it for?”<\/p>\n “Does the business really justify the use of distributed high availability technologies?”<\/p>\n “Why are we replacing a simple system that was adequate yesterday with a dramatically more complex system tomorrow? \u00a0What has changed that makes a major improvement, while remaining simple, not more than enough but requires orders of magnitude more complexity and more spending that wasn’t justified previously?”<\/p>\n These are just common examples, complexity exists in every aspect of our industry. \u00a0Look for simplicity. \u00a0Strive for elegance. \u00a0Do not accept complexity without rigorously vetting it. \u00a0Put it through the proverbial ringer. \u00a0Do not allow complexity to creep in where it is not warranted. \u00a0Do not err on the side of complexity – when in doubt, fail simply. \u00a0Oversimplifying a solution typically results in a minor failure while making it overly complex allows for a far greater degree of failure. \u00a0The safer bet is with the simpler solution. \u00a0And if a simple solution is chosen and proven inadequate it is far easier to add complexity than it is to remove it.<\/p>\n","protected":false},"excerpt":{"rendered":" It is very easy, when working in IT, to become focused on big, complex solutions.\u00a0 It seems that this is where the good solutions must lie – big solutions, lots of software, all the latest gadgets.\u00a0 What we do is exciting and it is very easy to get caught up in the momentum.\u00a0 It’s fun … Continue reading Solution Elegance<\/span>