Architecting for the Cloud, Part 1: Best Practices

Cloud-based software is fast and flexible, and offers tremendous opportunity to innovate. But how do you ensure that you’re doing it well? Here’s a general overview of best practices for cloud-based architecture.

The core principle to stay focused on is building a resilient system. Think in terms of “what if?” and prepare for foreseeable contingencies. This is not to say that you should run around like Chicken Little waiting for the cloud to fall out of the sky! But be proactive now so that you can be confident later.

There are several key ways to implement this sort of disaster preparedness. Two of them, elasticity and scalability, require a moment of clarification. These terms are sometimes used interchangeably, but in fact they’re quite different, and you may need both. Here’s why:

Scalability refers to planned increases to your infrastructure, so that you can support increased demand over time. As an example, if you were running a subscription-based service, such as Netflix, and you predicted a 10% increase in subscribers over a three month period, you’d want to lay the groundwork to support that increase ahead of time.

Elasticity, on the other hand, means that your architecture anticipates the unexpected. Consider social media outlets such as facebook and twitter. They have a known number of members; they have valid
usage predictions based on average volume. But a news event, such as the death of a celebrity, can result in a tremendous spike in activity. An elastic system can bring unused resources online to handle that demand within minutes, then “shrink” back to its normal usage level afterward. If you’re building an in-house system that won’t see serious usage fluctuations, you won’t need to worry as much about elasticity. But if you’re planning to grow your company, scalability should be an ongoing consideration.

Another basic operating principle when architecting cloud-based software is known as loose coupling.When architectural components are tightly coupled, they depend upon each other.Changing a component can be like untangling a knot: you pick at the part you’re focusing on, only to impact another in a way you didn’t intend. When components are loosely coupled, they exist and carry out tasks independently and even asynchronously of one another. Because of this, you can update one without having to update them all, and if one component fails, the others continue undisturbed. How closely you couple your components can depend on project requirements, but your mindset affects how you approach architecture, too. Think of loose coupling as a discipline, and practice it whenever possible.

Just as you should think of components in terms of whether they can operate independently, when you’re designing a cloud-based system, focus on individual services. Make sure each one functions as it should, then connect them into a workable whole. Fixating on the user interface can actually hinder the fluidity of individual functions. These separate considerations form a holistic mindset that should form your cloud-based architecture projects. This will ensure that you fully benefit from all that the cloud has to offer.