Posted by m.jackson on 22 May 2013 - 6:29pm 

By Mike Jackson.

You have access to a new computing infrastructure – a cluster, grid, cloud, HPC facility or volunteer computing infrastructure – and you wish to get your application running on it. This may be as simple as copying across an executable and running it, or, it may equally require a significant re-working of your application’s configuration or code. How you proceed depends upon your preferred working practices – you may want to scope out the work in advance in some detail or you may just want to get on and experiment.

How you port your application depends upon your application, your infrastructure and your personal preferences. However, there are a number of things that have the potential to make the porting go smoothly and that will also help others who wish to undertake similar work in the future. Here are our top tips for porting your application…

1. Plan for unforeseen but inevitable delays

Porting an application onto a computing infrastructure may be something you’ve done many times before. Or, it may be new to you. It is always useful, in any software development or deployment activity, to plan for unforeseen but inevitable delays. These delays may be caused by a lack of tools to make things easy, poor documentation, evolving or prototypical software, versioning, divergence from agreed APIs, cryptic error messages, software inter-operability issues, software-hardware incompatibilities etc. Consider how much time you’ll invest in trying a specific task e.g. trying to use a specific piece of software, or tying to configure the software in a certain way, and when you’ll call it quits and explore other options, and how much time you'll allocate for this.

2. Don't be afraid to look, or ask, for help

It's useful to search the web to see if others have ported applications similar to yours, or, even, have experience of porting your application. How they did it may help you on your way or provide ideas if you are stuck. If having to engage in low-level system administration-type tasks, which could be the case if using a cloud, then don’t neglect your local system administrators. They’ll have a wealth of expertise in system configuration and deployment and may be able to help you if you run into problems. Indeed, they may be prepared to work with you, or even to do it for you.

3. Don’t try to do everything in one go...

..as when things go wrong it may take more time to identify where the problem might lie. For example, if you have to install a software stack, then install, configure and test each component in the stack in turn. When you’re sure one component is installed and working, move onto the next. Breaking your porting down allows issues to be identified more rapidly since the potential sources of problems at each stage, caused by interactions with the various components, is reduced.

4. Write down what you try

If you don’t already, write down what you try. This can include: software used, including its version; commands run, arguments provided, data files used; errors encountered; errors you ignored that turned out to be OK to ignore; fixes or workarounds you applied, how you applied them and where you found these; links to sites where you found hints and tips; everything! Once you get things running you'll have a record of how you got there. This can be useful if you have to take a break for a few days, or a resource goes down, as it allows you to repeat your steps. Your notes can also be converted into a HOW-TO or tutorial for other researchers (see 7. below)

If doing a lot of work using the Linux/UNIX shell, then the "script" command is your friend.

5. Let software providers know of bugs

Pass back bugs, comments and suggestions on any software and its documentation to software providers. This can contribute to the improvement of the software. If suppliers provide e-mail lists, ticketing systems or forums then use these so that bugs are recorded and discoverable by others. If not, then you may want to highlight bugs via your web site or blog. This can ensure that others are aware of the bugs and don’t spend the same time you did in trying to detect, or solve, them.

6. Assess the stability and maintainability of other software

You may find that you need to use other software when deploying your application, whether this related utilities, libraries, configuration software, virtualisation tools etc. When selecting what software you use, consider the status of the software. Is it stable or a prototype? Is it developed by a team or a single developer? Does it have a user community, or is there evidence of users? Is there any support available? Is there documentation? Does it look up-to-date? This can help you understand whether the software is being actively maintained, that any critical bugs may be fixed promptly, and that help is available if you run into problems.

You should also consider the licensing of any such software and whether its terms and conditions places any restrictions on how, or whether, you are allowed to deploy it onto your infrastructure.

7. Share your outputs and experiences

When you’re done, let people know about what you’ve achieved and how you did it. Your porting work may be of interest to others who are porting similar applications. Sharing your experiences about how you did it, the software you used, bugs you encountered and patches you tried can save others going through the same trials-and-errors, help them to port their application more rapidly, and create goodwill towards you for saving them some of the pain!

If porting applications to be exposed as Software-as-a-Service publicise the availability of the software to your research community. This may prompt other researchers to reuse your software and data in their research, which has the potential to improve the quality of your research and the quantity and cost-effectiveness of theirs, to your mutual benefit.