FAQ

Why would I use LightBlue?

LightBlue eliminates a lot of the overhead involved in developing Worker and Web Roles for Azure. Roles can be started without packing and deployment and without starting up the emulator.

LightBlue also provides a file system based blob storage implementation that's a lot faster in most cases than the storage emulator and which doesn't have the same tendency to collapse under relatively light load.

This adds up to improved developer productivity due to a lot less waiting around for roles to start or for the storage emulator to store or retrieve data. We think that's well worth the cost of some corner case inconsistency with actual Azure for most projects.

Does a role have to fully convert to LightBlue?

No.

You can choose to continue to use elements of the Azure emulator if you wish. At the most basic level you could start your roles in LightBlue, replacing the compute emulator, but continue to use the Azure storage APIs against the storage emulator. If the storage emulator is working for your purposes but you'd like to start roles faster and be able to control them individually rather than in deployments this might be entirely satisfactory and will be very low impact on your code. This would only require that you use the LightBlue Storage API and Resources API.

You may choose to use the storage emulator for Azure storage options that LightBlue does not support (queues and table storage). This can be done by using the Azure APIs directly as per normal. You could also use the Azure blob storage APIs concurrently with the LightBlue blob storage APIs. In this case each API would give a completely distinct view of blob storage where the contents of one are not reflected in the other. It would be unusual to require this but it may be desirable in specific circumstances where you need to use blob storage functions not provided by LightBlue to operate on data not used by code using the LightBlue APIs.

Using the LightBlue storage APIs in Standalone mode inside the Azure emulator would also be possible but would require custom initialisation on role startup. This is not an officially supported or tested feature.

Does an entire system need to adopt LightBlue simultaneously?

Only elements that communicate via storage will need to simultaneously adopt LightBlue. You may otherwise choose to run some elements inside the Azure emulator using the Azure APIs and others in LightBlue.

Is LightBlue appropriate for my project?

LightBlue covers a lot of general purpose development on Azure but does not claim to be appropriate in all cases. The LightBlue design philosophy is to prefer being lightweight and developer friendly to being an absolute recreation of actual Azure. This is perfectly acceptable for most scenarios which are relatively unconcerned with the corner cases.

Code that requires a deep knowledge of the Azure platform, particularly the more advanced capabilities of blob storage, will generally be a poor fit for conversion to LightBlue. In these case it might be feasible to isolate elements and provide alternate implementations when running in LightBlue. It is more likely that such cases will be better supported by the emulator or against actual Azure.

Key differences when hosting in LightBlue are discussed in Important Differences When Running In LightBlue. You should consider these when deciding what, if any, elements of LightBlue to adopt in your system.