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.

In the world of cloud computing, security can’t be an afterthought. Although it adds complexity and cost to the system design and building processes, effective security is systemic to the application, the data stores, the platform, and the hosting cloud. Security must be considered at every step.

Not architecting to accommodate change. Twenty years ago we did not build applications with change in mind. Now we’re paying the price as those applications need to be refactored to move to the public cloud or be augmented in other ways. 

SOA (service-oriented architecture) taught us that designing for change pays huge dividends down the road. This means placing things that change into domains, such as microservices that may often change, but not necessarily forcing systemic changes on the entire application. Other tools include distributed objects, containers, machine learning, and logic servers, to name just a few ways to “change without pain.” 

You’re going to make mistakes. Let’s just try not to repeat them.