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.

Top-down approach

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.

Bottom-up 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.

This entry was posted in Cloud Computing and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Posted August 6, 2010 at 8:33 am | Permalink

    I think this opinion is completely wrong. A Private cloud should be able to support all applications that are expected to run at that physical location . If you follow this logic and design a cloud for an application (by sizing storage?) you would end up with several clouds, multiple SANs or switches? Not very cost or management efficient.

  2. Posted August 6, 2010 at 9:41 am | Permalink

    Hi Rick,

    I am glad you asked about efficiency. When I talked about top-down, it’s not about one application. It’s about all applications in your organization/company. The goal is to have one unified private cloud.


Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.