Hello Platform Engineers, I hope you'll are doing...
# general
m
Hello Platform Engineers, I hope you'll are doing great. Just wanted to check if there are any open source platform orchestrators (graph based) to hook into the backend? Any help, suggestions, demo or document links are greatly appreciated. Thanks 🙏
a
Hey Manish, I work on kratix.io which may fit your needs. Happy to help if you have any questions.
m
Thanks @Abby Bangser. I will go through this. Just want to confirm once gain, is that open source? or graph based backend architecture like humanitec?
a
Yes OSS (Apache 2). As for graph, can you describe what you get from that? My understanding is that it's about mapping requests to one more deployment locations and deciding on that through logic defined in the platform. If that is your understanding then yup!
There is no industry standard for graph based platform orchestrators so I just want to be sure we are reading the Humanitec description the same way 😅 (maybe @Clemens Jütte can correct me too if I'm wrong here?)
m
Thanks for explaining that @Abby Bangser. from graph based I meant decision making tree mapping as you explained. are they recoded videos or demos for this?
a
Awesome. Yea we use labels and selectors (will be familiar if you're familiar with k8s) to allow a 1:1 or 1:many mapping for all resources. Plus resources can split across one or more destinations 👍
As for video,

this is a good overview one

, but we don't have one on the scheduling in particular, but that's a good idea! Can do a demo if that helps?
m
That sounds great 🙂. I will watch this video and go through the doc and let you know about scheduling a demo.
Thanks a lot @Abby Bangser I truly appreciate it
a
No worries 😊 happy to help
c
Hey Manish! Hey Abby! That’s not how I would read “graph based” in this case - the mapping logic for deployment locations is one thing but the question is “how is my actual deployment represented?” - almost any infra product (e.g. Terraform & friends) are graph based because the dependencies between infra components are too complex to be handled in a linear processable way. Platform orchestrators care for infra but elevate the problem to the next level by including the actual deployment in the graph and thus form a solution as a whole by understanding what “an application” actually is. Orchestrators achieve this differently - Kratix has a flat system of promises until they get inserted into the Kubernetes object system (fancy words for a graph! 😄 ) and become a graph by proxy while Humanitec has it’s own graph on the input and processing side. Both approaches are vaild and result in a graph based processing of the application (so basically deployment and infra) as a whole instead of piecemealing it in different systems and trying to assemble it later down the road. Makes sense?
a
I knew you'd come in with the details Jay! Thank you 🙇‍♀️ I need a minute to process that and unfortunately need to run for the train. But I'll come back to you 🙌
m
Thank you @Clemens Jütte for the details.
a
Sorry, that train ride turned into 2 long days 😂 So @Clemens Jütte, is it fair to say that “graph” == DAG? With one of the values being that each vertex (or node) can be self contained, therefore allowing the graph to portray things at different levels of abstraction and defined in different languages/tools? I would absolutely agree that one of the big values of an orchestrator is that it can make changes to a platform atomic in nature, therefore removing the complexity of changing APIs, pipelines, infrastructure and applications in all different locations to make a cross cutting change! I am not quite sure I follow the “flat in” vs “graph in” distinction yet though 🤔 Not sure if you have a video/blog I could read? Else maybe run into you at SLC? 🤞
m
@Clemens Jütte @Abby Bangser Would you be able to schedule a demo? I would love to see how this works.
a
Of course. I will ping in a DM to set some time 🙌