Scalability and robustness
Since a very compelling business reason for using cloud computing is the ability to scale on demand and when needed, using the best practices and guidelines for designing large scale distributed systems is a good starting point. While academia has a preference for distributed transactions, ACID properties, and all kinds of consensus protocols, you are better off with loosely coupled systems where nodes will eventually reach a consistent state (as opposed to waiting for all nodes in a very large system to reach a consistent state before proceeding). Considering the state of existing systems, loosely coupled self healing self regulating systems should be preferred over system with exotic distributed transactional properties and consensus protocols.
Be prepared to lose computational appliances. As you already know, stateful systems are bad for scalability. Avoid storing the state in server sessions. If you are designing a client-server system from scratch, do not store client sessions on the server. For typical web applications, this means that your HTTP calls should be stateless. GWT and other rich AJAX or Flex clients let you do this relatively easily.
You should also try to avoid solutions that try to replicate state across multiple nodes. This almost always leads to overly complicated solutions. You are better off being prepared for loss of data and designing with the assumption that client application state, if at all available on the server side, may not be synchronized across all nodes. UDP, which is often used for discovery, and negotiating other information may not even be available on many cloud platforms.
These are important design decisions that you must make right up front. Retrofitting these into existing solution might be impossible.
Software engineering
In addition to strictly technical design and runtime issues, you also need to take into account other software engineering issues which affect you development.
As already discussed, you need to have a pool of engineers who understand the technologies you will be using. You may find it hard to find many engineers who have had experience with large scale, self healing, self managing systems. While one of the objectives of most cloud platforms is to take these complexities away from the developers, you will need engineers who understand these concerns.
You also need to find out if the platform you have selected provides good tools for development, deployment and debugging. You should ask the same questions you ask when selecting any technology.
- Find out if the platform integrates with the IDE you are planning to use (or if the platform comes with an IDE that will serve your development needs). I would recommend staying away from custom IDEs. Amazon, Google and Microsoft support industry standard IDEs for their respective platforms.
- You need to design for testability right from day one and your design should be testable on the platform.
- If your organization has an enterprise architecture, you need to be sure that your design and tools meet the standards and approaches laid down by it. Different network topologies, moving data in and out of the cloud and integrating systems running in the cloud with the systems inside the enterprise will come with its own set of challenges. While most enterprises have already started looking into cloud as a viable means for extending their computational needs, they may not be ready for a complete adoption.
- Security is an important aspect that you may not have full visibility into when you are running on someone else’s platform. Work with your security experts, quality assurance and compliance team to make sure everyone understands the security risks. A perceived security risk and lack of visibility could be a major problem while adopting any new technology (anyone remember trying to use Java RMI across enterprise firewalls?) and clouds are no exception. In fact the shared nature of the services makes security a bigger concern.
- Finally, you need to design for monitoring. It is best if the platform supports automated monitoring. Otherwise you may need to design for it right from day one. Even when the platform provides some tools, you may still have to monitors aspects not supported by the platform tools.
This discussing should provide you with a good starting point for creating your own best practices and guidelines. These are important design decisions that you should try to get right up front. Retrofitting these into existing solution might be impossible.
