Articles by Lee

We all know the value of distributing an application across multiple data centers. The same philosophy applies to the cloud. As we put our applications into the cloud we need to watch where in the cloud they are located. How geographically and network topologically distributed our applications are is just as important as with normal data centers.

While Amazon AWS won’t tell you specifically where your application is running, they do give you enough information to make diversification decisions. Interpreting and understanding this information, and using it to your advantage, requires an understanding of how AWS is architected.

In part 1 of this article, we talked about the AWS Architecture of regions and availability zones. In part 2, we will go into more detail about how availability zones are structured, and how we can utilize this information.

Join me at Cloud Expo 2016 at the Javits Center in New York, NY on June 7-9, 2016, where I will be speaking on keeping high availability in the Cloud.

Take a look at the article Microservice Architectures: What They Are and Why You Should Use Them, written by me and published by New Relic. This is an update and extension to the article “Why Use Microservices?

An updated copy of my book, Architecting for Scale, published by O’Reilly Media, is available for download.

This is the second version under the early release program. The full book is scheduled to be released in May.

One of the most important topics in architecting for scalable systems is availability. While there are some companies and some services where a certain amount of downtime is reasonable and expected, most businesses cannot have any downtime at all without it impacting their customer’s satisfaction, and ultimately their company’s bottom line.

How do you keep your customers happily using your service and keep your company’s revenue coming in? You keep your service operational as much as possible. There is a direct and meaningful correlation between system availability, and customer satisfaction.

Traditionally, software companies created large, monolithic applications. The single monolith encompasses all business activities for a single application. As the company grew, so did the monolith. In this model, implementing an improved piece of business functionality requires developers to make changes within the single application, often with many other developers attempting to make changes to the same single application.