Building the cloud is a complex task, and building a private cloud can bring about a number of network challenges. Networking professionals must understand these challenges in order to properly build a private cloud.
In this video, senior site editor Rivka Little sits down with Alistair Croll, founder of BitCurrent. Croll discusses how networking professionals should plan to address networking hurdles in building a private cloud, including capacity management. Croll also discusses how networking teams should address storage virtualization.
Read the full transcript from this video below:
Cloud computing: Building the private cloud
Michael Brandenburg: Hello. I am Michael Brandenburg, Technical Editor for SearchNetworking.com. Today I am here with Alistair Croll, founder of BitCurrent, to discuss cloud computing.
Alistair Croll: Hello, Michael.
Michael Brandenburg: Hello. What are the primary network challenges involved in building a private Cloud?
Alistair Croll: The interesting thing about a Cloud is that you are not just moving the data around anymore. You are moving the machines around because they are virtual machines. Every time you want to start or stop a machine, pause it and store it, which is one of the attributes of virtualization, you have to move the machine very quickly. You are not just copying information about what people are doing; you are copying the machines that are processing that information, and that changes the topography of your network significantly.
The second aspect is that the clouds are inherently useful because they connect to one another. Your cloud's service internally might want to get images from external sources or might want to do single sign on through an external system. That means that there are inherent network patterns where it is much more like a service-=oriented architecture or restful architecture. There is a lot of chattiness, and there is more stuff moving around, and that changes how the network and how the I/O has to happen inside the data center.
Michael Brandenburg: How do you address capacity management when building the private Cloud?
Alistair Croll: That is actually a really interesting question. For decades, the formula that IT used to use, if you really think about it, was the number of people you have using something divided by the resources they have, so if you have one person on 50 servers, awesome experience. If you have 50 people on one server, maybe not so good. That meant you had this equation where if you wanted the performance to get better, you could either add more machines or take away users. You could figure out the capacity your system could be because it was the number of users that a machine could handle. In the cloud, machines are infinite; I can scale up a 1,000 machines for two hours, so that equation is no longer fixed. The number we used to have, which was this big knob that IT could turn to add or remove machines, is now fluid. That means IT's job is now, 'how much performance can I afford?' I could burst up 1 million machines and give every one of my users a dedicated server, but it would cost me a lot. The equation we have had for 30 or 40 years about capacity planning has now changed because capacity is theoretically infinite in a cloud environment, a burstable environment, which means you need policies that tell you 'I am able to afford a two-second delay for this user experience'. You are going to get into metrics like cost-per-visitor second, which are things we have only started to think about, and frankly, things we have no tools to measure yet.
Michael Brandenburg: How does the network team address storage virtualization in building the private cloud?
Alistair Croll: One of the challenges with storage virtualization inside the private cloud is that people still think in terms of virtual machines. We are addicted to this metaphor of a virtual machine. We do not want a virtual machine; we want workloads. For example, if I think about virtual machines, I start thinking about where that virtual machine is. Is it in front of or behind the firewall? Because I am thinking about where that virtual machine is, I think the applications on those virtual machines behind the firewall are safe, and the other ones are not. What I should be saying is that this workload is safe and this one is not, or that workload has capacity and this one does not. When you think of virtual machines, you start thinking of connecting them to storage. What you really want is a workload that has access to storage, and that means the storage is going to be shared across many data centers. That storage is going to have to cooperate with the processing. In the old days, your database was probably faster than any one machine in your data center. Today, all of your servers can gang up on the database for one minute on a job. That means there has to be a very different architecture where multiple, very small databases live all over the place.
James Grey, who was a scientist at Microsoft, once said that the future of computing is hairy, smoking golf balls. What he meant by that was very small, very hot computers, bristling with wires is where the bottleneck is going to be. One of the reasons we move things to the cloud is that we want to centralize, compute near storage. That means that if you think of a room full of golf balls all trying to access a database, the database and the data has to be in there with the golf balls. They have to be intermingled -- storage and compute. You can no longer say, ‘Over here is the database and over there is the processor. Over here is the storage, there is the processor.’ You are going to have a co-mingling of storage and processing with shards of storage all over the place. That is actually really good for disaster recovery as well, because now you have shards of data moved near where they need to be. Now you do not have lots of copies of things; it is harder to compromise that data, and so on.
Michael Brandenburg: Excellent. Alistair, I want to thank you for your time, and I appreciate you coming.
Alistair Croll: Sure. Thank you.