Most articles on cloud computing discuss security, policies, economies of scale, or other high level topics. For a more pragmatic approach, we decided to simply port an existing application to the cloud and report on what the experience taught us.
Selecting the Application
Finding an existing, simple application that would benefit from the power of the cloud architecture was the first step. Fortunately, an associate nearby was using a spreadsheet application to perform Monte Carlo simulations for physics-based modeling and analysis. The application was reaching its limit in the number of simulations that could feasibly be run given the time required to complete them. The simulations, being run over a weekend, were producing results on a set of 30,000 simulations and seemed to limit out at that number.
The application being used was Microsoft Excel, with Visual Basic for Applications (VBA) code used to execute the algorithms in the scientific model and to randomize the variables used in the Monte Carlo simulations. It was very compute-intensive, not I/O bound, and thus an excellent candidate for migration to the cloud.
Choosing the Cloud Platform
Using a spreadsheet for the Monte Carlo simulation had been proven somewhat difficult. It was not very configurable, the dataset was embedded, the variables and formulas were scattered on one worksheet, the results returned on other sheets, and sorting was a separate, user-initiated action. Even if it were possible to push the existing spreadsheet up to the cloud and have it execute via a virtual machine environment, and then access it via a user interface, it was not an ideal solution. A standalone application migrated to a platform-as-a-service (PaaS) would likely be a much more logical and robust approach. An application where the user interface, data sets, and domain logic were separated and loosely coupled would be a superior approach. This approach would give the most flexibility to adapt to further iterations of the project. If the model changed, or the need for separate models with different algorithms and business logic arose, it would be simple to respond by adding a new module. The decision, then, was made to rewrite the spreadsheet as a standalone Microsoft Windows application and port this to the PaaS cloud.
Selecting the Vendor
This step and the rewriting of the Excel spreadsheet to a standalone application went hand in hand. Driving factors that were immediately apparent:
- The existing algorithms were written in VBA. Customer projects can vary greatly and the complex math and science underlying them can be daunting. For this and future projects, it was important to be able to port the existing formulas as-is, without rewriting them, and in such a way that would not require expert-level understanding of the theory behind them.
- The Monte Carlo simulation randomize functions were also written in VBA
- The precision and format of the results should exactly match the existing spreadsheet to prove the results from the cloud application were correct.
The above factors suggested a port to VB.net as the most prudent solution. Excel and VB.Net, both being Microsoft products, led to the decision to use the Microsoft cloud product, Windows Azure. Also, Windows Azure offers a free demo capability which allowed us to test this with minimal cost. A free cloud trial, including Tools and an SDK, made sense for this project, as it would for other organizations venturing into the cloud for the first time.
A quick tour of the Windows Azure web site confirmed that their platform did support Visual Basic.net along with C#, C++, PHP, Ruby, Python and Java. At this point, due to the factors listed above, the Windows Azure platform and PaaS as the type of cloud platform were clearly the best choices.
Throughout the process more research was performed and knowledge gained about Windows Azure as well as other cloud vendors and platforms. Several helpful books for this project included The Cloud at Your Service (Rosenberg & Mateos, 2010), The Cloud Computing Bible (Sosinsky, 2011), Azure In Action (Hay & Prince, 2010) and Programming Windows Azure (Krishnam, 2010). This reading proved invaluable in helping gain additional insight and knowledge that couldn’t be gathered simply by browsing vendor web sites.
Figure 1: Major Application Migration Development Phases
Figure 1 depicts the overall process that was taken to migrate the application.
Rewrite the Application for the Cloud
The first step in migrating the application, was to create a standalone VB.net application that would duplicate the main functionality of the existing Microsoft Excel spreadsheet. Since VB.net was chosen as the language, Microsoft’s Integrated Development Environment (IDE) was needed to develop the application.
The logical components of the Excel spreadsheet were divided into building blocks that would need to be created. They were:
- A Graphical User Interface, including:
- Input parameters for the model
- Browse controls for input/output data files
- Function list box
- Status box to display intermediate and final results
- Progress bar
- Run/Stop buttons
- A File I/O section
- An array to hold data set in memory for fast access
- A math section to duplicate formulas
- Control Logic, including the randomize functions for Monte Carlo simulations
- A results and sort routine
The VB.net environment is extremely strong in its graphical user interface (GUI) capability, prompting the choice to start with that aspect of the design first. The Visual Studio 2010 Express IDE worked flawlessly and the user interface came together quickly (Figure 2).
Figure 2: GUI of VB.net App in Visual Studio 2010 Express IDE
Thanks in part to the IntelliSense feature of the IDE coding the File I/O, the general control logic and the randomize functions were easy. Next it was necessary to tackle the math functions. Since the Excel spreadsheet used VBA, however, porting them to VB.net was almost seamless. The result was a working VB.net application that produced the same results as the original spreadsheet.