‘Biometrics in a box’ – migrating Windows apps to the Amazon cloud
At my company, we hold regular “hacking and pizza” nights to explore research areas and improve our expertise in emerging technologies. Recently, over the course of several hours (and several pizzas), we began experiments to migrate our existing Windows-based biometric applications to the Amazon Elastic Compute Cloud (EC2).
Eventually we were able to successfully have multiple clients access the matching engine that was hosted “in the cloud,” send it fingerprint and iris matching jobs and receive the results. For defense and homeland security missions, matching against massive numbers of biometrics in near-real time can be the difference between apprehending a suspect and letting him slip through your defenses.
Are your apps ready for the public cloud?
Spinning up virtual machines in the Amazon cloud involves setting up an account (credit card required), selecting the parameters of your desired operating system’s “image” and then launching the image. Sizing and capacity planning are key exercises to get this right, since the more robust a virtual machine you want, the higher the price per hour.
To make these hacker nights fun, we often introduce some competition into the mix and split into two groups (yes, my group won!). Sizing the operating system image tripped up the other group. They chose the cheapest image, which gave them significantly less memory and disk space than we had and made configuration harder and slower.
We selected 8G of RAM, Windows Server 2008 R2 (with SQL Server pre-installed) and plenty of disk space. After we launched the virtual machine, we set up public and private encryption keys to create a secure connection. Finally, we used the standard Windows “Remote Desktop” client to log in to the virtual machine, upload files, install and configure our software.
Before the last slice of pizza was eaten, we had a biometrics system running in the cloud. That updated image, with our server software installed, can be saved as a custom image and launched at any time. Thus, we had “biometric-matching-in-a-box” ready to launch on thousands of Amazon servers in an instant!
I hope you see the power in migrating an application like this to the cloud. However, it should be noted that the biometric server in question was designed to use Web services so, in essence, it was already “cloud ready.” Furthermore, this same capability could be launched just as easily on a private cloud as long it supported the OS version and capacity parameters we required. Our next step is to explore the Amazon Web Services that enable you to launch images programmatically so we can launch auto-scaling mechanisms that would spin up new virtual machines once a capacity threshold was surpassed.
Now what are the ramifications of this type of cloud implementation? Why choose an Infrastructure-as-a-Service (IAAS) cloud and not a Platform-As-A-Service (PAAS) cloud?
The answer is that we had a scalable, Web-services based matching engine that could leverage IAAS scalability without rewriting the application. I cannot stress enough that Web-service investments will pay dividends for your eventual cloud migration. Another important ramification is whether your application can afford “coarse-grained” scalability or whether your data or processing needs require a “fine-grained” scalability and access provided by a PAAS solution.
Understanding this issue of granularity in cloud implementations is critical to developing your cloud migration roadmap. By coarse-grained scalability, I mean it is acceptable to incur the “OS-overhead” and file-based model of a virtual server-to-server scalability solution. Such scalability at the server (or node) level is what IAAS offers and what IAAS vendors are making even more attractive with low pricing, queuing and caching services. So take care in sizing your virtual machines and consider these tradeoffs in your cloud migration strategy.