▲圖片來源：infoworld

I restore and fix classic motorcycles in my hard-to-find spare time. Since I’m a better cloud architect than motorcycle mechanic, I focus more on the design patterns for each brand, model, and type of motorcycle than another person might. Or, better put, I look at how motorcycle brands and models do the same things differently, both complex and simple, to achieve the same objectives.

I notice when one of my bikes has front-wheel brakes with 20 moving parts and others only have 5. Both systems stop the bike, but the more complex solution is more likely to break and is harder to fix. It is overengineered. It achieves the same objectives but at different levels of cost and risk. Perhaps the same is occurring in the cloud computing design and deployment space.

Overengineering is the act of solving a problem in an elaborate or complicated manner compared to a simpler solution that can demonstrate the same efficiency and effectiveness as the more complicated design.

A recent Deloitte study uncovered some interesting facts about cloud computing budgets. You would think budgets would make a core difference in how businesses leverage cloud computing effectively, but they are not good indicators to predict success. Although this could indicate many things, I suspect that money is not correlated to value with cloud computing.

In many instances, this may be due to the design and deployment of overly complex cloud solutions when simpler and more cost-effective approaches would work better to get to the optimized value that most businesses seek.

If you ask the engineers why they designed the solution this way (whether overengineered or not), they will defend their approach around some reason or purpose that nobody understands but them. When you get down to a core cloud architecture—or any solution design for that matter—it comes down to opinion and bias. Moreover, many engineers would argue that as long as it works, who cares how it was designed?

If you’ve been reading my stuff, you already understand that I’m obsessed with fully optimized cloud architectures, which means finding the most cost-effective solution. Normally, that means choosing the simplest solution using the fewest components, one that is not overengineered or over-thunk. This is in contrast to many of the Rube Goldberg cloud architectures out there that barely work and cost three to four times more.

This is a systemic problem now, which has arisen because we have very few qualified cloud architects out there. Enterprises are settling for someone who may have passed a vendor’s architecture certification, which only makes them proficient in a very narrow grouping of technology and often doesn’t consider the big picture.

Too often, organizations hire the wrong cloud solutions architects who are pressured into moving fast and overengineer solutions by tossing technology at the problem just to get something working. Worse, they don’t ask critical questions and don’t peer review the solution to determine if there are less complex and less costly paths to the same objective.

Moreover, these folks often focus more on the speed to deployment and the daily scrum meetings rather than on getting a simple, optimized solution. This results in more complex cloud solutions that are difficult to operate and secure and that cost much more than they should to deploy and operate. I bet you’re thinking of one of these right now in your own company.

OK, now that we know of the problem, perhaps even agree that it is a problem, what do we do about it?

I’m not sure that speed should be the ultimate objective when designing a cloud computing solution. We should seek a solution that’s the most optimized, and we should move down the most efficient path to do so. I find that many companies put speed above everything. Certainly, this occurred frequently during the pandemic’s mad rush to the cloud.

The trouble again is that the overengineered solutions typically work and therefore are declared a success, even when a skilled architect would understand full well that the approach is four times the cost and will become a misunderstood burden on the business.

I urge you to ask the tough questions and challenge solutions that you believe are poorly designed. Too many of these will kill your business; I’ve seen that firsthand. If you don’t, you’ll find that just like my motorcycles, breakdowns are more frequent and require a great deal of time to fix.

轉貼自： infoworld.com

若喜歡本文，請關注我們的臉書 Please Like our Facebook Page： Big Data In Finance