Notes for application developers - PERRINN/infrastructure GitHub Wiki

If you're new to writing code for cloud-hosted environments, here's a few tips to get you going:

1. Nothing is permanent.

Your code will exist on a compute instance that will be created and destroyed outside of your control. Please don't assume that your machine name, network address, working data, memory and CPU will be the same as last time. This also applies to systems you need to connect to. Don't connect via IP addresses. Use the machine names you are given in your app configuration.

2. Local file systems are short-term storage

Any data which needs to be saved must be kept outside of your machine. Either write the data to the database or use the provided external storage service. (S3 in this case)

3. You can't log in and configure something

The entire application needs to be configured either from the start-up parameters, a configuration file or by querying a database. The advantage of using a database is that configuration changes can be immediately available to every part of the application farm.

4. Responses must be available everywhere

If there is a long-running task which creates a report, it is possible that when the user comes back to collect the output, the request will go to a different node. Store the output file on S3, and keep a location pointer in the database.

5. Apps and services must self-start

Whether the underlying system is Linux or Windows, nobody can log onto a console to start the application. It must be capable of being started automatically, and without any interaction.

6. Handle your own errors

Build error-handling into your code. Prepare for things to fail, and be able to handle them. Record your errors to a log file (use log4j or log4net) which we can gather and store in a central location.

7. Services should present a "Status Page"

If you're building a web service or API service, make sure there is a status page which can be queried in a single http(s) request to make sure all is well. Failure to respond to this request in a timely fashion may result in the application instance being killed off and replaced.

A follow-on to this thought is how to handle errors which have no recovery. If you reach this kind of situation, make sure the status page returns something different from "healthy" if you cannot proceed further. This allows the instance to be killed off and replaced.

8. Use garbage collection wisely

Instances have the minimum resources we can get away with and still provide acceptable levels of performance. Why? Because we can scale out to new instances if the work gets too much. As a result, don't waste resources you don't need, or block standard garbage collection in the name of performance.

9. Expansion happens when you don't expect it.

This is an elastic environment, so avoid writing to common files, etc. You don't know at any time how many instances of yourself will be in operation.

10. Do great stuff!

You have a lot more power and capability available to you. Use it wisely and effectively, and you can solve problems you might not even know existed.