_When not to
While Windows Azure, being based on existing Microsoft technologies, is appropriate for a wide range of applications, some are less able to take advantage of the benefits and some may not work at all.
The following characteristics are good indicators that the application should be avoided, at least for the time being:
- Applications that have too much legacy code, components or interfaces are difficult to turn into astounding Windows Azure successes. This may be because of specific tools (such as ETL tools), interfaces with legacy systems that require complex security infrastructure, or installations that require significant manual configuration. Applications that have a lot of legacy components or a lot of integration with legacy applications are hard to deliver and may not be made significantly easier with Windows Azure.
- Security and regulatory compliance is often used by detractors of Windows Azure. While Windows Azure will satisfy most regulations, for a first application it would be easier to attempt something that does not have complex regulatory compliance. Regardless of the technical and legal merits of Windows Azure, such applications have, for good reason, far more governance, audit, testing and other processes. Even if the regulatory minefield can be navigated, it is likely that the benefits of rapid provisioning that are offered by Windows Azure will be offset by compliance rigour.
- Because Windows Azure requires a different way of thinking, a different architectural approach and a different set of skills, building an application that has a big bang implementation, where the entire business is bet on the success on the first day one of the system going live is too risky. It is better to start with systems that are small and tactical, extensions to existing systems or a green fields development where risks can be managed and releases can be incremental.