Skip to main content

Azure Tools - Azure CosmosDB Emulator

Highlights of  Azure CosmosDB emulator
Azure Services: Azure CosmosDB
Cost: free of use
How is delivered: Windows Service or Docker container, exposing web endpoint on a local port
Top 3 features:
  • #1 Docker support
  • #2 A web explorer similar with the one available inside Azure Portal for local documents 
  • #3 The option to delete all the data with only one click
Pain points:
  • #1 No consistency level supported
  • #2 Limited to 25 fixed containers or 5 unlimited containers
  • #3 Lack of support for other APIs 
Credits: Azure CosmosDB Team

When I first discovered the emulator support for Azure CosmosDB I was super excited. Azure CosmosDB is not cheap and for development teams is always a challenge when they need to share a data repository.
Usually, each person in the team is working on different areas of the project and needs a different data setup. By having an emulator the team has the possibility to focus on their own area and test it locally without deploying their own instance of Azure Cosmos DB database or container. Not only the development is smooth, but also the running cost of the development environment is lower.

As you can see above, the interface is clean and provides the things that you need in the first moment when you start the emulator - the connection string to connect to it. The Explorer is similar to the one that we have inside Azure Portal, allowing us to do any type of operations inside our containers. We even have the ability to define functions, triggers and stored procedures.
The support of writing queries directly inside the browser it's nice and I used with success to understand some concepts related to how to write queries. You can save the queries defined in the emulator, but we aware that they are saved inside Azure CosmosDB containers. This will generate an additional cost (~$0.77/day) but can be used as a common query repository by the team.
There is an option that allows us to reset all the data stored inside the emulator. Useful during development phases. There is also the ability to upload content from JSON, for cases when you need to prepare your local emulator with fresh data.

The speed and the performance of the emulator are not high, but it is more than enough for development and to play around. Locally I don't see an issue with lack of support of consistency level especially because you have only one instance - no replica.

To be able to activate emulators for Gremlin API, Cassandra API, Table API or MongoDB emulator you need to start the emulator from the command line and specify "/EmulatorMongoDBEndpoint" as the parameter for MongoDB. A similar thing you need to do if you want the emulator for the other APIs. Except for the SQL API that is fully supported, the rest of the APIs are partially supported.
The Docker support for the emulator is awesome and enable you to use the emulator in different and configurations.


Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP