Build a Cloud in Three Easy Steps

Occasionally I get a question about some totally impossible implementation detail (example: can we use OpenStack OVS plugin on VMware to avoid buying NSX?). These questions are often coming from people who painted themselves into a corner and are now desperately looking for MacGyver’s shoelaces to pull themselves out.

It’s easy to blame the engineer who tries to do the obviously impossible, but it’s often not his fault – these days a lot of technical people get pulled into the game of Build a Cloud in Three Easy Steps.

DIY aficionados who overextend themselves because “they can build the cloud” (even though they never did that before) are an obvious exception – their organization deserves the cloud they get because they let them loose.

Instead of trying to figure out whether to use overlay virtual network with GRE or VXLAN encapsulation, try to grasp the big picture first:

  • What services will our cloud offer?
  • Who is the customer?
  • How many customers will we have?
  • What is the expected workload size?
  • What is the expected growth?
  • Will we have multiple tenants (or applications-as-tenants)?

Based on the answers to these questions, you’ll be able to figure out how big a network you need, and you might figure out that you don’t more than two ToR switches, in which case you don’t really have a problem anymore.

Need more?

Start with this video to get into the proper mindset, then watch the Building a Private Cloud Infrastructure webinar and other cloud computing and networking webinars.


  1. Damn you Ivan!! I came here to learn how to build a cloud in 3 easy steps.

    Valid points though. Requirements drive the solution, not the other way around.
  2. Techies need to learn that Excel is their friend. Create a model, it can't and doesn't have to be 100% true or real. Find the rules of thumb capacity engineering rules, code them into the spreadsheet. The next time your star salesperson or CEO come to you with this great opportunity you have something to temper their enthusiasm. I came into a situation where nobody could figure out what the impact of selling a service to the end customer. I created a model that calculates bandwidth, packets per second, concurrent sessions and number of servers, storage and switch ports. I have no idea if it's right or wrong but it is consistent and when I back tested it, it gave me number close to reality. Took me 6 months but the confidence you get when the big boys realize you have a handle on the numbers is priceless.
  3. Replace "Seven Red Lines" with cloud:
  4. My opinion, if you cannot answer the question, "how much does it cost to run my network and how much will I charge for infrastructure and services?", you really shouldn't be building a cloud. Yes, you can build one successfully without this info, but it won't be aligned and you will afterwards be playing catch up trying to determine SLAs, Chargeback, Accounting, and Capacity Management.

    Someone will wind up with a budget hit and project resources with no way to tie any of the expenses to the benefits you should be realizing from the cloud strategy. Ask me how I know...

Add comment