Refactoring is the process of changing how a program works without changing what it does; even before the term was coined, it was practiced by programmers as “program restructuring” from the early 1950s. Refactoring itself came to prominence with work by Opdyke, Griswold, and Johnson in the early 1990s and was popularized by Fowler’s 1999 book. Refactoring is done to improve code for a range of reasons: to make it conform to coding standards, to make it easier to read, or to prepare the code for modification or enhancement.

Whatever the case, refactoring of large code bases can be infeasible without automated, or semiautomated, tools, and many integrated development environments (IDEs) incorporate refactoring for a variety of languages, although it is perhaps most developed in the IDEs for the Java language, including IntelliJ and Eclipse. Refactoring “in the small” is the preserve of the developer, and may be done as a part of his or her day-to-day development process; larger-scale refactoring is often anticipated, but perhaps harder to justify as part of an aggressive release cycle, unless, of course, there is some concrete gain to be made. What better example could there be of this than migrating an existing system to the cloud?

Taking a system and moving it to the cloud must be the right thing to do: it provides scalability, resilience, and also fits the zeitgeist. However, as the authors make very clear, it is not without difficulties. It is important to preserve functionality; the system should not change what it does. However, it should also maintain nonfunctional properties like efficiency (for example, latency and throughput), and questions of resilience are more acute in a distributed/cloud setting.

In common with many other refactoring tool builders, the authors propose a two-pronged approach to the problem: first, they give an analysis to provide recommendations of how systems might be refactored, and then they develop a tool to implement the refactorings identified. Their first phase combines static clustering analysis with runtime profiling to identify potential services that can be migrated, and their second implements refactorings that make this change through introducing the appropriate interfaces and proxies and at the same time adding fault-handling facilities to deal with the additional risks introduced by moving to a more distributed application platform.

These refactorings are included in Eclipse and available through its standard refactoring workflow, and the work is demonstrated through two small examples and a larger case study performed for GE Research. One of the key questions faced by designers of a cloud refactoring tool and their users alike is how much of the refactoring workflow should be automated. In discussing a number of examples, the authors say that they “selected appropriate classes for the reason of the performance, call-by-reference, and meaning of features,” thus making clear the role for the domain-aware engineer in the process. It would have been interesting to have heard more about the software developers” view about the results of the analysis: Were the services identified meaningful to them? Would they have structured things somewhat differently from the analyses of the tool?

In summary, this paper makes a clear and well-described contribution to what is a fast-moving field: Google Scholar, for example, gives over 1,000 references matching the keywords “cloud” and “refactor,” and this number can only be set to grow as migrating to the cloud proves to be more of a challenge than its advocates suggest.