search

dotnet / tye

Tye is a tool that makes developing, testing, and deploying microservices and distributed applications easier. Project Tye includes a local orchestrator to make developing microservices easier and the ability to deploy microservices to Kubernetes with minimal configuration.
MIT License
5.3k stars 520 forks source link

Extending Tye #1004

Open aL3891 opened 3 years ago

aL3891 commented 3 years ago

What should we add or change to make your life better?

There has been a few issues about publishing with tye to other places than kubernetes, this is something that I'm interested in as well, but more generally, what are the plans for extensibility in tye? From what I've gathered, extensions are currently baked into tye and can't be added without changing the code, atleast not easily (i have not dug super deep into this though so feel free to correct me)

It would be very useful to be able to

Extension points i would like

Why is this important to you?

Tye is a very promising project for us and it would be a shame if it was limited to kubernetes. Many developers have very customized deployment setups that are basically one off solutions, as well as legacy systems that might not use k8 at all. By adding the more extensibility points to tye deveopers can leverage the great stuff already in tye and also use it in more places, and also take pressure off the dev team to support more external stuff and focus on the tye core

jkotalik commented 3 years ago

This, selfishly, is one of the main features I want added to tye. I think the ability to reference a 3rd party package in your tye yaml that would be able to modify how a service starts (like dapr, zipkin, etc.) is critical for the success of tye long term.

I think you issue mentions two types of extensions, ones which add to a service during tye run and tye deploy. The other portion is adding extensions which deploy to something other than k8s. I think the first is more attainable at this point; a design for an extension model to handle how applications are deployed seems much more involved.

aL3891 commented 3 years ago

For sure, i understand that tye was created as a tool for Kubernetes and extending the actual publishing part is a much broader task. Many concepts in Kubernetes do not exists in other platforms and vice versa, and what if i want to extend my custom service fabric publish pipeline? could a plugin target a specific publish service? All these things could be solved of course, its just a lot of work and changes to the current architecture

Even so, using tye as kind of a way to model a microservice system in an abstract sense, services, ingress, containers, mapping ports... That would be pretty rad, even if the primary goal is publishing to Kubernetes.

Again, i understand this is not that can be done in a weekend, but maybe the model stuff could be exposed as a library so that you could read the yaml file into an object model, have the "service plugins" potentially modify it, and then hand if off to the library consumer to party on?

For example, my current thinking in using Tye with service fabric would be to just read the tye.yaml file directly and generate a servicefabric deployment from that. I haven't tried this though and it might not work if i can't add custom values to the tye file (i.e. values that tye just ignores). Having the object model, ConfigApplication basically, would make that a lot easier

RichiCoder1 commented 3 years ago

I have the far more kubernetes-focused case in that we don't use ingress in our clusters, and I'd like developers to be able to wire out routes and autoscaling without having to deploy extra yaml. As an offhand example, we're considering using KubeVela's [https://kubevela.io/docs/cue/component](extensibility feature) to potentially make "app yamls", but that doesn't cover the local dev case.

FiniteReality commented 3 years ago

I'd love to extend tye with support for mahou, because tye makes debugging microservices so much easier, but kubernetes has a very high barrier-to-entry.