If you frequently work with serverless architectures and expecially with Azure Functions, I think that you know that splitting a complex process in multiple “microservices” is often a good architectural choice.
When using Azure Functions, sometimes could be quite difficult to test a serverless process that requires interaction between multiple function apps (components) during the development phase. Just as an example, imagine to have a serverless process where some Azure Function apps read sales orders from different B2B system and put the order message (details) into a queue. Then another Azure Function app takes the message from the queue, process it and creates an order into Dynamics 365 Business Central:
How can I test the entire process easily? I would like to have all functions apps up and running in my development environment quickly and maybe on different ports.
In the latest workshop about Azure Functions development that I’ve recently done for some partners, I presented an open source project called Microsoft Tye. Tye is a developer tool that makes developing, testing, and deploying microservices and distributed applications easier. It was born for Kubernetes and for developing microservices easier (with the ability to deploy microservices to Kubernetes with minimal configuration) but I think it’s absolutely helpful also for Azure Functions projects.
Microsoft Tye is currently on alpha stage and it’s available on NuGet here: https://www.nuget.org/packages/Microsoft.Tye/
It requires .NET 6.0.
To explain wy I think it should be helpful also for Azure Functions developers, let’s consider the previous example (simplified). I have the following solution in Visual Studio:
This project contains 2 Azure Function apps (called B2BService and D365BCOrderService). When you create a function app project in Visual Studio or Visual Studio Code, the function app is configured to run on a specific port.
To test this project with Microsoft Tye, you need to first install it on your development machine. To do that, just open a command prompt and execute the following command:
dotnet tool install --global Microsoft.Tye --version 0.11.0-alpha.22111.1
where –version is the current version available at the time of writing this post.
Microsoft Tye has a optional configuration YAML file (tye.yml
) to enable customizing settings. This file contains all of your projects and external dependencies. tye.yml
lists all of the application’s services under the services node. This is the place for per-service configuration. To learn more about Tye’s yaml specifications and schema, you can check it out here in Tye’s repository on Github.
In my solution, I’ve created a tye.yml file as follows:
name: AFServices services: - name: B2BService azureFunction: b2bservice/ bindings: - port: 7011 - name: D365BCOrderService azureFunction: d365bcorderservice/ bindings: - port: 7012
This YAML file maps the two services (Azure Function apps) that I have with the local folder repo (where the source code is stored) and with the specific port that I want to use for each service.
Now, open the command prompt in the folder where this tye.yml file is located:
and execute the following command:
tye run
The Microsoft Tye engine starts:
and now you have two services (Azure Function apps) running on two different ports (B2BService is running on port 7011, D365BCOrderService is running on port 7012).
Microsoft Tye has also a nice user interface for managing your service that responds to the following url:
http://localhost:8000
The Tye UI appear as follows:

You can now test your integrations easily.
Please remember that this project (managed by the .NET Team) is actually in an alpha stage and something can change in the future. If you’re working with multiple Azure Function apps or with microservices architectures, I suggest to give it a try. It can save your development life a lot.