Elements of the CloudShare Universe

After discussing the CloudShare’s development process, I wanted to delve into the subject of testing, and try and provide a glimpse of how testing is accomplished on the CloudShare development team. As I started writing the post, I stopped almost immediately – how could I explain how we’re testing, without first explaining what we’re testing? Do I really want to put the cart before the horse?

Nope. I want to explain how CloudShare works before explaining how we test things. So, without further ado…

How CloudShare Does its Thing

There are five main components that make CloudShare tick:

• The Frontend (we call it “UIBL” – weebill – for “UI and Business Logic”). This is the web app everybody uses to setup their environments and use them. It also handles all payment, licensing, and permission stuff.
• The Backend. This is the code that does everything behind the scenes – creates the environments, runs them, suspends them, publishes, and other stuff like configuring the networking.
• The VM Infrastructure. This is the software that runs the virtual machines themselves. This was not written by CloudShare – we use VMware for this purpose.
• The Hardware. These are servers that run the VMware software. Each server runs several virtual machines.

Let’s discuss each of them. But I’ll discuss each of them in a bottom-up fashion – I’ll start from the bottom and work my way up.

The Hardware

Since this is primarily a post about software, then from a simplistic point of view the following is good enough – we have lots and lots of servers, with lots and lots of CPU-s, and these servers have lots and lots of memory and are connected to lots and lots of disks with lots and lots of terabytes of space.

And what are we running on the hardware? VMware – our Virtual Machine infrastructure.

The VM Infrastructure

VMware is one of the leading VM software vendors. The software enables us to run multiple virtual machines on a server – with each one virtual machine unaware that it is running alongside the others. This allows us to share the our servers amongst multiple users (you didn’t really thing you get a real machine each time you create a machine in an environment, right?). VMware allows us to create such a machine, configure its CPU, Ram, Disk, and networking layer. Finally it allows us to run it, suspend it, reboot it, and connect to it via SSH, console, or RDP.

So if we have this wonderful software that can create and manage the virtual machines, why do we need the Backend?

The Backend

We need the backend because somebody has to tell VMware what to do. Somebody has to say – “oh, this user requested a Windows 7 Virtual Machine connected to a SharePoint Server? And it wants to run it from now for two hours?”. “Oh,” says the Backend, “OK. I’ll just tell copy our Windows 7 template hard drive and memory, and the SharePoint Server hard drive and memory. And after that is done, I’ll tell VMware about the copied machine, and ask it to run it.”

“Oh,” says the Backend, “I totally forgot! I need to figure out on which server to run the copied machines, and to configure the network so that they won’t see any other machine except these two.”

The Backend’s job is is not easy. Because we live in an imperfect world – all these operations, they sometimes fail. Just like that. So it needs to retry the operations. And it needs to check that a machine that should be (for example) running, is in fact still running, and if not – rerun it. We call this capability “self healing”. But that’s an incredibly interesting (and challenging!) topic, so I’ll leave it to another blog post.

The Backend is a very dynamic piece of code, so we use a very dynamic piece of technology – the Python Programming Language.

But who tells the backend what the user wants? Well, that’s the job of the user, through the Frontend.

The Frontend

The Frontend is the GUI. It’s a WebApp. Written in C#, and using ASP.NET MVC as its Web framework. It shows the GUI that you all know about – the GUI that allows you to create and run the virtual machines. And if you’re a CloudShare ProPlus user, it also handles your payments. In the end, it communicates your wants and desires to the Backend, telling it what the users want. How does it communicate that? Well, I’ll discuss it in a future post, but suffice to say that it uses a database for that.

That’s It

That’s it. This is how CloudShare does its thing. Now I can rest easy, and in the next post, I’ll discuss how we test all those lines of code in the Backend and in the FrontEnd.

(image by ralphbijker, under Creative Commons License)