Android AWS & Google for Development/Testing

Navin Thadani, Sr. VP of Products at Ravello Systems, stopped by PubNub to share his thoughts on running Android full-speed without emulation on AWS or Google Compute Cloud, as well as sharing some use cases.

Android AWS/Google for Development and Testing

Background on Virtualization

On the left you’ll see what we used to do 15 years ago: an x86 server, and you run an OS on it. That OS runs one application, typically, and that’s it. That was the computing paradigm. Then VMWare came around and developed Hypervisor, which would run on the physical server or desktop, and run multiple virtual machines inside of it. That was the principle of virtualization, and there were lots of benefits in the datacenter. You’ve probably seen a lot of this; VirtualBox is an example of Hypervisor, as well as VMWare Workstation. Using Hypervisor you can run multiple OSes as “guests” on top of one physical system.

What We’ve Done

Amazon runs on Xen, a virtualization technology that was was open-sourced some time ago, they ran into a number of problems with it. We’ve developed a new Hypervisor, called HVX, which allows you to run any virtual machine on any cloud without making any changes at all. The idea is that if you break down the stack, you’ll see that from Amazon you can run Hypervisor on it and then run any Virtual Machine on top of it. At this point, you can run an Android VM on top of Amazon or Google Compute Cloud.

This isn’t Ravello’s core business. If you spin up an Android VM on Ravello there are some challenges; the screen and mouse don’t work that well, and most Android x86 images are built for VirtualBox; our Hypervisor actually exposes VMWare devices up to the VM (which is why the mouse and screen are a little bit off.) However, the core stuff runs at full speed. Depending on the market, we may add VirtualBox devices to our Hypervisor, which would allow us to expose different display sizes for your Android VMs.

Demo: Android AWS

As I mentioned, the nested hypervisor we developed has been productized as a service. If you go to our website, you can log in to this interface which is primarily designed for server devices. Generally this is for back-end developers to create entire copies of their entire production environment. Here’s one of our collaboration tools with a back-end server, app server, database and cache. We’ve connected to it two Android VMs, one is Ice Cream Sandwich and one is Kit Kat.

The way you would get your VM into here is to upload a VMWare instance. If I pick up this VM, you’ll see it’s now running in Amazon Virgina, and here is our public DNS name. Before I connect to that, let me open a console. You can see the actual Android VM running on Amazon. The interesting thing is that there is no emulation going on. The VM is running directly on Amazon’s servers. When I said the mouse was bad, you can see I wasn’t kidding, but you can get an idea of what it looks like.

Use Case: Social Networking

A nearby social-networking company wanted to build an end-user experience monitoring system for their service, which runs off a datacenter in the US on a standard back-end architecture with hundreds of micro-services. They wanted to see what their users around the world were experiencing. You could use Amazon, but of course you can’t run Android VMs on Amazon natively. We spun up servers in nine regions around the world, with a Ravello test VM that allows them to study the effect of latency and how the application performs all around the world.

Use Case: Continuous Integration

I stole this diagram from a pretty interesting blog that Etsy wrote about their continuous process which involves GitHub and Jenkins, where they test every commit on a farm of Mac Minis in their datacenter. What if you could eliminate a decent portion of that Mac Mini farm for integration testing? So the moment somebody checks in code, you can spin up 100 Android instances in the cloud. You could have as many versions as you wanted, and multiple instances. Obviously the downside of this is that if you don’t have access to your camera or gyroscope that can limit you, but from an operating system perspective, they generally don’t use those services. So this is one other idea that people are talking about, but isn’t totally implemented yet.

Use Case: Scale Testing

You could potentially spin up 50,000 instances of Android with a few tweaks on our end. Would that help in any way? What would having so many Android systems generated tell you about your app? There is potentially a lot to do here with lots of traffic. How would it be different from a standard Linux server generating load? I would love to get your input to help guide our product efforts.

If you have feedback, you can reach out to Navin over Twitter at @navinthadani.