Skip to content

FAQ

Jump to bottom
Colin Scott edited this page Aug 31, 2014 · 4 revisions

What's the difference between LightBlue and the emulator?

The Azure emulator attempts to look as much like actual Azure as is possible on a single machine. Roles must be packaged and deployed. Communication with storage is via the same web service calls but with a different endpoint. Excluding performance and resource limitations code should run in a very similar fashion between actual Azure and the emulator.

In contrast LightBlue explicitly disclaims being an emulator of Azure. It does not use the package and deploy model. It has limitations where it does not exactly match Azure behaviour in the APIs it provides and there are some functions (Table and Queue storage for instance) that it does not address at all. This is an explicit design decision to favour being lightweight over compatible with the full range of Azure behaviours. Some of the reasons why we have made this tradeoff are discussed in Why would I use LightBlue?.

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.

LightBlue allows roles to be started and stopped individually rather than at the deployment level which is useful when you have many roles in a deployment but only wish to adjust one. You can start additional instances of a role at any time without having to restart existing instances. Each role is also given a title that identifies it in the debugger so you can attach to the specific role you wish to debug easily. Worker roles can also be individually started in the debugger if desired.

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.

Why didn't you write the storage emulator as a service?

An alternate implementation strategy considered for LightBlue was to write a service that implements the Azure web APIs allowing clients to use the .NET Storage APIs directly. This would also have allowed non-.NET clients to use the storage emulator. This approach was not selected for a number of reasons:

  • Building the service would be significantly more work, to the extent that it's probably not feasible. It would require replicating a more complicated set of interactions. Wrapping the Azure Storage APIs for talking to actual Azure or the Azure emulator means that this responsibility is passed off to an API that is maintained
  • The risk would be greater. Changes to the Azure Storage API implementation to call additional or different web APIs could break LightBlue. This could happen because a client program updates the version of the Azure Storage APIs that it uses.
  • It would be unclear which capabilities LightBlue actually provides until you get a runtime error.
  • Running entirely in process is faster. This is particularly advantageous when starting many components on a single developer machine.
  • Processes are self-contained. There is no need to check if an external service is running and attempt to start it if necessary.
  • The LightBlue APIs are more testable. Any test written using the Azure APIs is necessarily going to have to be an integration test unless it doesn't try to manipulate or query storage. You can easily provide mock implementations of the LightBlue APIs (manually created or via a framework like NSubstitute) for testing purposes.
Clone this wiki locally