Provisioning an Event Hubs Namespace

1. Start Locally

Firstly, we need to launch Locally which we can do from a terminal by running:

Once Locally has started, the Locally Dashboard will open automatically:

2. Create a Resource Group

Next we can create the Resource Group to hold the namespace:

There's two things to note here:

1. The Azure CLI supports Automatic Configuration, meaning that it can automatically be configured to work against Locally just by prefixing commands with locally run.
2. Locally intentionally uses a different set of locations to Azure as a safety precaution, so that you can be confident you're deploying against Locally rather than regular Azure. You can also configure Locally to use the Azure locations too, but you'll want to be extra sure that you're prefixing commands with locally run when you do.

3. Create the Event Hubs Namespace

With the Resource Group in place, we can create the Event Hubs Namespace:

{
  "note": "some fields skipped for brevity",

  "location": "berlin",
  "name": "samplehubs1",
  "provisioningState": "Succeeded",
  "resourceGroup": "sample-resources",
  "status": "Active",
  "type": "Microsoft.EventHub/Namespaces"
}

4. Create an event hub

A namespace is just a container, so next we'll create an event hub inside it. Event Hubs partitions its stream, and the partition count is fixed at creation, so it's the one setting worth thinking about up front:

Which gives us the hub along with the IDs of its partitions:

{
  "note": "some fields skipped for brevity",

  "name": "telemetry",
  "partitionCount": 4,
  "partitionIds": [
    "0",
    "1",
    "2",
    "3"
  ],
  "status": "Active",
  "type": "Microsoft.EventHub/Namespaces/EventHubs"
}

We can list the hubs in the namespace at any point:

Name       Partitions    Status
---------  ------------  --------
telemetry  4             Active

5. Create a consumer group

Consumers read from an event hub through a consumer group, which is how two independent readers can each track their own position in the stream. Every hub starts with one called $Default, and we can add our own:

{
  "name": "processor",
  "type": "Microsoft.EventHub/namespaces/eventhubs/consumerGroups"
}

Locally has a built-in helper for listing them, which shows the default alongside ours:

NAME
$Default
processor

6. Get the connection string

To have an application publish and consume events, we need the namespace's connection string. Locally has a helper for this too:

Endpoint=sb://samplehubs1.eventhub.locally;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=...

That eventhub.locally hostname is served by Locally's own DNS server and points at the Event Hubs Emulator running on your machine.

Locally also lets you look at what's landed in a partition without consuming it, which is handy while you're debugging a producer. Since Event Hubs is partitioned, you peek one partition at a time:

As we haven't published anything yet:

No events in event hub "telemetry" partition 0.

We can see the Event Hubs Namespace in the Locally Dashboard too:

7. Tidy up

Finally, we can tidy up. To remove the Resource Group and everything within it:

There's nothing billable to clean up, since everything ran on your machine, but it's still worth checking your teardown scripts work here before you run them against Azure.

Doing this with other tooling

Whilst this guide used the Azure CLI, Event Hubs works the same way through any of the tooling that Locally supports - Microsoft.EventHub/namespaces and Microsoft.EventHub/namespaces/eventhubs resources in HashiCorp Terraform or OpenTofu, Pulumi, Bicep or an ARM Template all provision against Locally in the same way, with only the location changed.

Next steps

The Event Hubs Emulator lets you send events from the browser and pause a hub. To consume events in code, a Function App can use an Event Hubs trigger, and IoT Hub telemetry arrives through Event Hubs too.

Should you encounter any issues, please take a look at the troubleshooting section.