3 cloud architecture mistakes we all make, but shouldn’t


The only time I had an issue with someone I worked for was when they wanted me to punish a junior IT architect on my staff for making a pretty big mistake. One of the databases was not compatible with a middleware layer already in existence. 

Obviously, this error cost us time and money. But these kinds of mistakes are almost unavoidable when configuring IT systems, cloud computing included. I view them as necessary in the innovation process. If you don’t try new things—and find out some of them don’t work—then you’re not improving anything. I encouraged my boss to find a new line of work, and eventually, he did.

So, if mistakes are a natural byproduct of creating a good and innovative new architecture, then it’s time to look at the mistakes that are made most often. For cloud architectures, those mistakes should be understood by now and avoided. Here are three that come to mind:

Overdistribution. Just because we can decouple application and data components and run them all over the place via network-connected systems does not mean we should. Cloud architectures are especially susceptible to this mistake, considering the ease in provisioning all sorts of platforms on different clouds and having an easy path to connect them. The results are well known: namely, poor latency and reliability.

Many of the rules of good architecture still apply. Specifically, locate processing and data storage for the same applications and data stores as close as possible. This typically means intracloud, but it could also mean intraplatform on the same cloud. 

Security as the last step. Security was once something we bolted on at the end of the process. If you do that with a cloud project, you will create a security system for an application and/or data store that is suboptimal at best and hugely insecure at worst.

Copyright © 2021 IDG Communications, Inc.



Source link