State of Tye

[AndrewBabbitt97]

Development of Tye seems to have slowed in recent times, so I want to get a gauge on what the current status of the project and what future plans may be.

.NET is starting to evolve to contain better tooling for building containers which is fantastic, is this the start of making container and microservice development easier directly in the SDK? Are there plans to make features in Tye directly available in the .NET SDK? If so do we have any timelines for this?

What is the plan for Tye as it stands now? A 4 week release cycle is listed in the readme but dropped off after 0.10.0 in September of last year. We have only had one release since then back in February. Is there a lack of developers to support working on this and more maintainers are needed? I'm sure integrating with the new .NET 7 container build tooling as well as some other open issues such as #1013 are desirable. As it currently stands Tye is falling behind capabilities in the SDK.

It would be sad to see Tye slowly die off, as it really is a useful tool. I hope there is some future in it as either Tye as it stands or its features migrated into the .NET SDK.

[dziedrius]

It would be very interesting to understand what is the future for the Tye, as some of the PRs are hanging for more than a year.
It is a wonderful little tool, that is saving lots of time each day for us, it would be really sad if it would die.

[AndrewBabbitt97]

Gonna tag @jkotalik @rynowak @philliphoff and @davidfowl for visibility.

[benmccallum]

We're currently looking at moving the last of our apps over to containers (likely to be hosted w/ AWS Fargate) and I threw Tye out there as something we should look at as a lot of its goals and features we'd benefit from greatly.

I think we may just jump onto the .NET 7 container publishing if it's flexible enough for us, just to get these app containerized and running on Linux; but then we miss out on Tye features like service discovery (hardcoding our app ports right now, and Windows likes to take them!) 😞

[davidfowl]

Tye was an experiment from the .NET team and it's not dead but it's definitely not actively being work on at the moment. We're working on figuring out how these fits into our cloud native tooling story. I do believe this approach is one we want to take, at least for the developer experience, I'm not sure about the deployment story (though there's no harm in having something like that for toy scenarios).

Stay tuned...

[AndrewBabbitt97]

To give some input:

The developer story is what at least me, my team, as well as companies I consult tend to really care about.

For deployment, we tend to use Tye to at least build and push containers to our registry. This works very well from CI pipelines. This is however where Tye usage stops as pretty much everyone prefers to develop and maintain a helm chart for deployment.

It would be interesting to see what ways deployment could be handled, but right now the yaml generation that tye does is not flexible enough to be used for most scenarios.

Always around to discuss what I have seen and discussed with others. Pretty much everyone has been happy with how Tye handles development.

[joelnotified]

Just popping by to +1 the developer story usage of Tye. Personally I've never seen the benefits of the deployment parts, but the "docker compose" like functionality is awesome. It's working well and I'm using it daily. It could however benefit from a couple of smaller improvements (like being able to start/stop individual services without restarting Tye completely).

I would love to see a future where Tye could support other types of projects, not only .NET and containers. Maybe it could be extensible in a way that one could write their own plugins or general tasks for other types.

Go Tye! 😄

[davidfowl]

If you're using Tye, make sure you fill out the survey, all of that feedback helps us make decisions about what to prioritize.

[joelnotified]

I'm guessing it's this one: https://www.surveymonkey.com/r/RWHQYL7

[onionhammer]

Tye was an experiment from the .NET team and it's not dead but it's definitely not actively being work on at the moment. We're working on figuring out how these fits into our cloud native tooling story. I do believe this approach is one we want to take, at least for the developer experience, I'm not sure about the deployment story (though there's no harm in having something like that for toy scenarios).

Stay tuned...

I vote incorporate the ability to run multiple apps at once into the dotnet CLI.. Honestly that's the most important thing to me, being able to run all the apps/dependencies from a single command

[allensiho]

The inference Im making reading the comments that tye will not die and wirse case it will be folded into other tools?

One concern is if it dies all our work to get our projects to support its configuration will be wasted?

So we should not worry about this?
Cheers

[miroslavpopovic]

Survey filled. I would really like to see the development of Project Tye resumed. I use it on all my projects, and all the sample codes for my talks. Also, I have started collecting some usage samples into a GitHub repository - https://github.com/miroslavpopovic/tye-and-docker-compose-samples.

[a-shoemaker]

Is there potentially any process that this can just get turned over to the community in some official capacity? Or is there anything perhaps coming in the immediate future about rolling in somewhere else (Dapr or official dotnet project)?

[lopezbertoni]

Tye was an experiment from the .NET team and it's not dead but it's definitely not actively being work on at the moment. We're working on figuring out how these fits into our cloud native tooling story. I do believe this approach is one we want to take, at least for the developer experience, I'm not sure about the deployment story (though there's no harm in having something like that for toy scenarios).
Stay tuned...

I vote incorporate the ability to run multiple apps at once into the dotnet CLI.. Honestly that's the most important thing to me, being able to run all the apps/dependencies from a single command

+1 on this one and on the developer story.
For web development and the popular use case of 1 or more SPAs with 1 or more APIs (even Azure Functions) running behind a reverse proxy (we use YARP) this is super handy and works like a charm.

[davidfowl]

Is there potentially any process that this can just get turned over to the community in some official capacity? Or is there anything perhaps coming in the immediate future about rolling in somewhere else (Dapr or official dotnet project)?

Turn it over? Anyone can fork it.

[spboyer]

Tye was an experiment from the .NET team and it's not dead but it's definitely not actively being work on at the moment. We're working on figuring out how these fits into our cloud native tooling story. I do believe this approach is one we want to take, at least for the developer experience, I'm not sure about the deployment story (though there's no harm in having something like that for toy scenarios).

Stay tuned...

From a tooling story we are looking at the principles that Tye offered and seeing where we can take this within the bigger story and support more the .NET, reduce dependencies and as David mentioned, making the cloud native story as best as possible.

The deployment story was specifically targeted at Kubernetes, and with many other container host options available; integration with GitHub Actions, DevOps and a part of the developer experience without cognitive overload and complicated configuration is also key.

[Kralizek]

Love the tool. Blogged about it, my customers love to use it because it makes it extremely easy to run multiple applications at once, even mixing them with containers.

I don't particularly care for Kubernetes integration because I deploy mostly to AWS ECS.

The tool needs some QoL improvements but it works nicely already now. Yet, I'm curious to see where it can go.

My posts about Tye:

• https://renatogolia.com/2020/11/12/developing-distributed-applications-with-tye/
• https://renatogolia.com/2022/07/21/using-localstack-with-microsoft-tye/

I already filled in a survey around 0.6, is the survey a new one?

[onionhammer]

Also it makes running dapr applications much easier..

[davidfowl]

@Kralizek these blog posts are amazing. I'd love to also hear about the way tye is being used. The original intent was distributed applications and microservices but is anyone using tye as a local orchestrator (or in prod?)?

[Kralizek]

@davidfowl what do you mean by local orchestrator?

My customer uses Tye to start around 15 ASP.NET Core services (GRPC and classic REST) together with a container for local DynamoDB, ElasticSearch and OpenTelemetry. All works great because the services are able to talk to each other and consume the containers all retaining debugging and quick reload capabilities. I guess this is what you would call local orchestration.

In production, we pass envs that follow the schema of the Tye Configuration extensions. The values are calculated by Terraform and fed into the ECS Task definition.

Some QoL I'd love to see:

• possibility to compose envs from other envs and values providing some kind of format pattern Support replacement tokens in environment variables #377 (comment)
• possibility to express envs at root level to avoid duplication
• possibility to run a certain command (useful to automatically hydrate a database or a dev environment)
  • on start
  • on [service] start
  • on [service] stop
  • on stop

[davidfowl]

I'm going to be reviewing and merging PRs on Tye again (yay down to 14 at time of writing). I'll also be looking at fixing some of the issues that are long standing paper cuts.

[dziedrius]

Currently we use the same way @Kralizek does - with similar amount of services (although we rarely start all the services, tags functionality helps a lot to quickly start only needed set of services).
If it would allow us to better control host names (support network aliases like in docker-compose, so that we could mock actual services like twilio with our container images), I'm pretty sure we would replace docker-compose with tye for integration tests too.

[davidfowl]

If it would allow us to better control host names (support network aliases like in docker-compose, so that we could mock actual services like twilio with our container images), I'm pretty sure we would replace docker-compose with tye for integration tests too.

Can't you control the host names by changing the service name? Can you show what you mean?

[dziedrius]

@davidfowl I think I can't use dots in service name.
In our integrations tests docker-compose we have proxy with such settings:

 tests.mock.proxy:
    container_name: tests.mock.proxy
    image: nginx
    volumes:
      - ./integration-test/proxy-nginx.conf:/etc/nginx/conf.d/default.conf
      - ./integration-test:/etc/nginx/certs
    extra_hosts:
      - "host.docker.internal:host-gateway" # TODO: only linux
    networks:
      default:
        aliases:
          - secure.efaxdeveloper.com
          - api.twilio.com
          - pinpoint.us-east-1.amazonaws.com
          - fcm.googleapis.com
          - connect.us-east-1.amazonaws.com

That allows us to forward requests for example from api.twilio.com to our container for mocking.
To be fair we're using WireMock library to mock requests in the integration tests, so that we could setup specific responses for each test, so nginx config looks like:

server {    
    access_log /dev/stdout detailed;

    listen 443 ssl;

    ssl_certificate     /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;
    
    location / {
        proxy_pass http://host.docker.internal:5055;
    }
}

[davidfowl]

@dziedrius I see, please file another issue with these details.

[Kralizek]

Oh, another small QoL: when in tye run --watch, react to updates to the tye.yaml.

[davidfowl]

Yea, that's QOL but requires some big design changes.

[benmccallum]

Awesome blog posts @Kralizek , the one about LocalStack could be really useful for us as we're getting to that point now where shared queues and whatnot are a problem across the team. We also use ECS, so Kubernetes support isn't relevant to us for now.

We'll be jumping onto Tye in the NY, mostly for local orchestration if I understood the meaning correctly (we need service discovery so we're not hardcoding ports mostly).

Some local, some remote
As the number of services/apps we've got starts to increase it becomes less viable to run them all locally (esp for FEDs), so then I'm searching for a way to easily say run A, B and C locally, but point at D, E and F running on a shared host. Unfortunately, the limiting factor then becomes which database to use (local ideally, but shared becomes necessity if D, E and F are shared). Our microservices all point to the same mega DB, but even if the DB was split up more, I don't think that'd make this any easier. Having all our devs point at one shared DB is theoretically fine, but every now and again a rogue DB migration could cause havoc. It also doesn't scale well if/when we have devs in different parts of the world (we're in Aus, but I was working out of France for a while and now one is in Spain).

Debugging
One thing I noticed seemed a little tricky in my reading was the debug experience. I'd love to see improvements here, if possible, though I might be missing something.

The VS Code extension seems to be more fully fledged, but most of us I imagine would be running VS.

I saw a few VS extensions that seemed useful. Here.

• Tim's Tye Explorer - allowed you to attach to process from an explorer of running services.
• EasyRun - has its own higher-level profiles config which seem to be tied to sln files (so we'd likely need to move to an All.sln with .slnf files, which I've wanted to do for ages anyway)

Summary
Just musings really, but I'm glad my original comment triggered some focus in this space as there's a lot of people benefitting greatly from Tye. I know the ChilliCream/HotChocolate guys use it extensively too if you need more developer insights.

[Phiph]

I use Tye in every project I come across these days, and even go so far as use it to run live automation tests in pipelines (probably a no no, but hey it's a container so why not :D)

Do you think it should be a part of dotnet, or should we just keep the project alive with a community call or something?

maybe we could get some good value out of it by making a module to deploy to Azure Container Apps from tye.

[lefig]

Reading between the lines would it be reasonable to say that the project is effectively dead and the tool experiment was a success and will be released perhaps in a different form.

There appears to be new updates in 2023.

[Phiph]

@lefig it might not have active development, but it still works and I think that's the beauty of it!

It's simple, and pluggable and over the last few years that I've used it I have had almost no trouble in getting it to work with my dotnet 3.1 -> 7 projects.

[Kralizek]

@Phiph I agree with you, it works. But some features are still missing (environment variable manipulation for one).

Also, if it focused only on the inner development cycle, it should support better some use cases like frontend applications.

My hope is for an arrangement like the one for CoreWCF: a community led project with supervision by Microsoft.

[Phiph]

@Kralizek I haven't come across the environment variable manipulation problem, what's the challenge?

For my front end apps I tend to point at a container, which isn't ideal, but gets me somewhere!

[onionhammer]

You can kinda sorta launch an npm app, not very cross-platform friendly though;

- name: your-service
  executable: "%ProgramFiles%/nodejs/npm.cmd"
  args: start
  bindings:
    - port: 5050
      protocol: http

[Kralizek]

@onionhammer this is also the approach I'm using.

The container suggested by @Phiph makes it uncomfortable for frontend developers who are used to work with the hot reload.

There are few issues opened regarding environment variables manipulation. I'm from the phone right now. I'll add some links and comments tomorrow.

[Phiph]

Ahhh good point - it just shows how much front end dev I do in anger!

don't worry I scrolled up and found your issue - #377 (comment)

Is there a Discord, or community around tye? If not should we set one up?

[Kralizek]

Gonna tag @jkotalik @rynowak @philliphoff and @davidfowl for visibility.

[davidfowl]

Does anyone have nodejs front end + backend samples with tye?

[somecodingwitch]

@davidfowl I just worked with it at work so private projects. Maybe I can write some boilerplate using Tye with mixed node and .net services in free time

[Kralizek]

@davidfowl

Here is what I got running right now

name: sample

services:
- name: web
  executable: cmd
  args: '/c npm run start --prefix Web'
  bindings:
  - protocol: http
  env:
    - name: BROWSER
      value: none

- name: legacy
  executable: '%PROGRAMFILES(x86)%\IIS Express\iisexpress.exe'
  args: '/path:%LegacyAppPath% /systray:false /port:29213'
  bindings:
  - protocol: http
    port: 29213

- name: api
  project: Backend/src/API/API.csproj
  bindings:
    - protocol: http
      
- name: database
  image: mcr.microsoft.com/mssql/server:2022-latest
  bindings:
    - containerPort: 1433
      connectionString: Server=${host},${port};Database=sample;User Id=sa;Password=${env:MSSQL_SA_PASSWORD};TrustServerCertificate=True
  env:
    - name: ACCEPT_EULA
      value: Y
    - name: MSSQL_SA_PASSWORD
      value: yourStrong!Password
  volumes:
    - target: /var/opt/mssql/data
      source: data/database/data
    - target: /var/opt/mssql/log
      source: data/database/log
    - target: /var/opt/mssql/secrets
      source: data/database/secrets
  tags:
    - db

ingress:
  - name: ingress
    bindings:
      - protocol: http
        port: 11470
    rules:
      - path: /api/v1
        service: api
      - path: /api
        service: legacy
        preservePath: true
      - path: /services
        service: legacy
        preservePath: true
      - path: /
        service: web
        preservePath: true

Here I have:

• api as a ASP.NET Core 8 backend app mapped to /api/v1
• legacy is a old style ASP.NET MVC webapp hosted on IIS Express mapped to /api and /services
• web is a React app mapped to / and used as a fallback for everything not mapped

Major pain points with this setup:

• IIS Express executable path is hardcoded.
• IIS Express port is hardcoded
• Sometimes the process hangs and we can't terminate tye by pressing CTRL+C. Only workaround is killing the processes and the containers found in the files in the .tye directory
• Integration with auth providers like Entra are annoying because of the port mapping

A tiny bit OT:
My customer really wants to migrate their gargantuan .NET Framework web app piece by piece. YARP was a first step in that direction. But application composition also helps a lot.
We have an experiment ongoing where legacy endpoints are still mapped to the api service and we use YARP to reroute spillover requests to legacy. It mostly works but it creates ambiguity between /api/v1 endpoints and /api legacy ones.

[onionhammer]

Does anyone have nodejs front end + backend samples with tye?

Yeah, looks something like this

name: c2c-app
services:
- name: c2c-app-frontend
  executable: "%ProgramFiles%/nodejs/npm.cmd"
  args: start
  bindings:
    - port: 5050
      protocol: http
- name: c2c-app-graphql
  include: ../../tye.yaml

Not the best, or cross-platform ready, you can either start tye in the root (which skips starting frontend) or start tye in the src/Frontend folder, which also includes the root tye project

[spboyer]

Anyone setting up emulators for storage, eventgrid or other systems instead of using containers? Have a sample?

[Kralizek]

I wrote a blog post about using LocalStack with Tye, maybe that could be of help?

https://renatogolia.com/2022/07/21/using-localstack-with-microsoft-tye/

[Kralizek]

I guess Aspire is the new Tye 🤔

[davidfowl]

Ya know I really wanted to tell you all, but now I think we can say it since everything is public 😄. Aspire is a superset of tye. The orchestration pieces are usable in a standalone manner if you just want to use that.

[onionhammer]

Aspire is a superset of tye

Why not just continue to develop Tye as a "v2.0" and evolve it in the open instead of creating a replacement?

[Kralizek]

@davidfowl

One thing I'm looking forward to understand how it works is the replacement for the GetServiceUri extension method.

I'm deploying my services to AWS and with the Tye library I could craft the configuration values so that the services could talk to each other once deployed as well.

I guess I have to go and look in how the new AddServiceDiscovery method works.

Edit: I guess I shouldn't be writing while the panel is ongoing 🫣🫣🫣

[davidfowl]

One thing I'm looking forward to understand how it works is the replacement for the GetServiceUri extension method.

https://learn.microsoft.com/en-us/dotnet/aspire/service-discovery/overview

[AndrewBabbitt97]

I just want to say thanks @davidfowl as well as to everyone on the Aspire team, it seems like you guys listened well to the needs that those of us working on cloud native distributed apps have, and that you guys came up with a good solution. I'm excited for the future of Aspire and where it could go! 😁

[JasonRodman]

I just heard about Aspire today, this is great news. We use Tye with Dapr and heard about project Radius yesterday, are the two related?

[lopezbertoni]

We literally started using tye on a project a couple of weeks ago. I guess it's now time to migrate to Aspire! 😀
Thanks a lot for the effort and listening to the community!

[davidfowl]

Thank you all for the support, usage and feedback. Please dive into https://github.com/dotnet/aspire as the we will not be doing any further work in this repository.

[Kralizek]

@davidfowl one last question pertaining Tye.

I understand Tye is as much as in beta as Aspire is. My question is, is Aspire ready for primetime or is it better to wait few releases before migrating from a tool that has more or less been working for the last years.

Are there features supported in Tye that have been willingly put on a lower priority when working on Aspire?

I haven't had the time to play with Aspire yet (damn timezone 😛) so bear with me if my questions have trivial answers.

A great deal has been given to "hiding" port numbers and connection strings. But sometimes you want to be able to grab the connection string to the database and use it to access the database from mssql management studio or rider/datagrip. Is there a way to access it?

Another thing I didn't see any mention during the panel is an equivalent to the ingress block.

That being said: great work and see you on the other side!

[davidfowl]

s Aspire ready for primetime or is it better to wait few releases before migrating from a tool that has more or less been working for the last years.

That's up to you. Now that you know for a fact that Tye won't get any updates it'll be your choice to make. I'd suggest trying it an evaluating if it works well enough for you or if you can't use it for some reason and file issues or discussions.

A great deal has been given to "hiding" port numbers and connection strings. But sometimes you want to be able to grab the connection string to the database and use it to access the database from mssql management studio or rider/datagrip. Is there a way to access it?

It works much like tye but is a bit more auto-magic because we're using C# and can actually do software composition with abstractions yay! Aspire uses the idiomatic connection string configuration (ConnectionStrings__name), so you can grab it at runtime like normal. Same with the data provided for service discovery.

Once you start using it, it'll make sense.

Another thing I didn't see any mention during the panel is an equivalent to the ingress block.

This is no ingress and this isn't something we're going to bring back. I'd recommend people just make a project with YARP which didn't exist when we did tye.

That being said: great work and see you on the other side!

Can't wait!