Cloud Technology Partners has just released its new PaaSLane for AWS, a software solution that analyses codebases and pinpoints issues that would likely cause problems if the code were to be deployed to Amazon Web Services or other elastic environments.
A key feature of cloud (on-premises or public, PaaS or SaaS) is elasticity, the ability to dynamically change the amount of resource applied to service the application based on demand. Most people tend to think of this in terms of scale-up—increasing the amount of resource—but if you are taking an existing application to the cloud, it’s actually scale-down that is the business benefit. In non-elastic environments, your application will already be scaled to cope with the maximum anticipated workload, but most of the time that silicon is just sitting there costing you money. In an elastic environment, you can dynamically load-balance and avoid paying for compute resource that you aren’t using.
The problem is that there are some architectural design patterns that can easily support this form of scalability, and there are some that can’t. For example, it is much easier to dynamically scale and load-balance JSON/REST or XML-RPC (which are web services) than Java RMI (which is not). It’s not that the latter can’t be made scalable or performant, it’s just that the infrastructure components for doing it aren’t built into the cloud. Similarly, there may be things in your codebase that just plain don’t work in a cloud environment. For example, you may be writing files to shared filesystems—yes, people still do that. In a SAN that may be OK, but in the cloud it isn’t like that. Either the data goes across the wire (slowly) to some form of shared storage, or it stays local to the node, and that breaks the application logic because it isn’t shared and it isn’t persistent. And of course you may have hardcoded database names, locations, usernames, and passwords, or even IP addresses, and none of this really works in the cloud. In addition, your application may assume features of the application server and database layer that aren’t provided in “vanilla” clouds. For example, you may have built your software for WebLogic or WebSphere, which you would need to license again for the cloud, whereas the cloud vendor is offering you Tomcat at no extra charge. Further, there are some things that work but which you really shouldn’t do in the cloud, like send email directly from your AWS server. These IP addresses are very likely to be blacklisted (think who could have used them previously), so you may want to use Amazon Simple Email Service instead. Finally, there may be additional policies you may wish to apply to codebases that are exposed in the cloud, e.g., the use of a specific security framework, and you need to check that these are indeed in place.
None of this is rocket science, but it is quite obscure, and it is time consuming to go through an existing codebase, make sure it is OK, and pinpoint exactly where the changes need to be made, even if that codebase is clean and new. In most cases, the developers who wrote the codebase will have moved on, so anyone getting involved in refactoring will have to sift through some unfamiliar code to find all the gotchas. Up until now, the solution seems to have been to “hire an expensive consultant.” Unfortunately, there aren’t too many of these around, and they are expensive, so one of them—Cloud Technology Partners—has decided to codify its experience and sell it. The product is called PaaSLane (with that particularly ugly capitalization). It comes in SaaS (upload your code) form for those brave enough to do that, or it can be purchased for use on premises.
The technology used by Cloud Technology Partners is fairly established in its use for other purposes. It is typically known as static analysis, and the main proponents are Fortify, Coverity, and Klocwork. It works by generating an abstract representation of the codebase (source code or occasionally directly from bytecode) and matching patterns or analysing data flows. Fortify, Coverity, and Klocwork focus on code quality (e.g., null pointer exceptions, deadlocks) and security (SQL injection, relative path traversal, etc.). The tools work via a combination of an analysis engine and a ruleset. There are open source analysis engines, and we assume these are used by Cloud Technology Partners.
Cloud Technology Partners has, then, provided a ruleset that can detect the sorts of defects that cause problems in AWS deployments. Over time, it is enriching the ruleset to increase the set of problems it can address. However, there is some “low hanging fruit” covered in the existing product that can address a very large number of practical problems with existing codebases. It targets Java and .NET, and whilst they are talking exclusively about AWS, it is likely to be of benefit on AWS-compatible clouds like Eucalyptus or other technologies such as OpenStack.