Cloud Architecture Design: Should it be Top-Down or Bottom-Up?
In my last blog, I discussed how to optimize workloads across the cloud. This is based on the assumption that you already have an existing infrastructure. What if you don’t have an existing cloud infrastructure but would like to design one from scratch? Here is what you should be thinking about to get the most from your new cloud.
But first let’s take a look at other types of infrastructures – say a road. When you design a new road, you have to collect data such as population densities around the area, people’s working schedules, what types of vehicles will run on the road, and so on. With that information, you can decide how many lanes you want, what kind of road surface is required, and so on. You don’t just make up the design specification from scratch, and lay down an eight-lane freeway everywhere.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
The same process applies in designing the cloud infrastructure as well. Unfortunately this is not what we see often today.
In my previous blog , I said infrastructure is a means and application is the end. We need to drive the design cloud architecture from the application perspective. This is what I call the top-down approach.
The benefit of top-down approach is the system efficiency you gain – you create just enough infrastructure for your applications to run without any waste. This gives you the best ROI from a business perspective.
The top-down approach works perfectly for enterprise private cloud. For service providers, however, it may or may not work. If the service provider provides specialized services such as online storage where the application workload pattern is known, then you should definitely follow the top-down approach.
For service providers who provide generic services, it’s hard, if impossible, to know customer workload patterns in advance. In these cases, you are best served by following a bottom-up approach. That means designing the cloud infrastructure based on typical applications.
When new applications come in, just mix them based on their workload patterns described in this blog. In so doing, you may still achieve good workload balancing and the best business ROI.
How to top-down?
When using top-down approach, you want to analyze the workload patterns and quantify them with numbers in CPU, memory, networking, storage and so on. If you cannot easily infer the numbers, just pick a similar system and measure it before adjusting your designed based on the scale ratio.
With the workload numbers, you can translate them into infrastructure level requirements. To play safe, you want to have some allowance for unusual cases. On the networking side, it’s not purely about bandwidth, it’s also about good topology design that can flow network traffic better.
Now, don’t forget another very important dimension of workload pattern – timing. If the same workloads and their peaks are evenly distributed over time, you should be fine. To best design a private cloud, you have to consider the element carefully. In fact, in many enterprises there are some pretty clear patterns with workload over the time. For example, the accounting system will peak at the close of each fiscal quarter.
Although cloud infrastructure design is mainly about computing infrastructure, we should drive the design from the applications that run on the infrastructure. This is what I call the top-down approach.
When the application workload patterns are unknown, you can go with bottom-up approach. Even so, you still want to balance the workload at runtime by mixing complementary applications together on the same physical resources.
For the private cloud and specialized public cloud, the top-down approach is preferred. For generic service providers, bottom-up is usually best.