lostbean

This is very exciting! Curious to learn more about how the linear types fits into the picture here?

Calling it an ontology might be confusing indeed — nevertheless it’s definitely valuable to have an automatic way to generate and hydrate a semantic model from raw data

This really isn’t an ontology. Palantir’s marketing around “ontology” is misleading — what they (and you here) are describing is closer to a semantic layer or curated data model.

An ontology in knowledge engineering is an open-ended graph of concepts and relationships, typically expressed as triplets (subject–predicate–object). It’s flexible and domain-agnostic.

I’m quite a visual learner, so I appreciate you sharing this.

Yes, Kardinal is designed to make development environments more efficient and less wasteful compared to your current setup, where each dev instance is a single pod with everything in it. In Kardinal, we calculate reusability at the application level. You only deploy the services you're actively working on, which means you won't need to spin up unnecessary components, like a separate database, if it's not needed for your dev/test case. This will improve both cost and speed.

Not sure if I'm addressing your point correctly, but Kardinal does have the concept of external services and provides a plugin system that allows you to manage stateful external services. Here is an example [1] of a plugin to manage Neon [2] (a serverless Postgres DB with support for branches). You can find more information about plugins here: https://kardinal.dev/docs/concepts/plugins

[1] https://github.com/kurtosis-tech/neondb-plugin [2] https://neon.tech/

You're completely right, ofrzeta! Kardinal does manage Istio for you, so you don't need to learn or interact with Istio at all. In fact, Kardinal acts as a transpiler, taking Kubernetes manifests with simple Kardinal annotations and generating and applying the Kubernetes and Istio resources for you.

It's a fair and valid comparison, and we're tracking this and other comparisons here: https://kardinal.dev/docs/references/comparisons

Regarding how Kardinal compares with vcluster, both aim to provide multitenancy within a single Kubernetes cluster, but they approach it differently.

vcluster is designed to offer a full Kubernetes experience to each tenant, including their own API server, control plane, and other Kubernetes-level components. This makes vcluster an excellent choice if you need strong isolation or want to test Kubernetes-specific features like custom CRDs or operators.

Kardinal, on the other hand, focuses on application-level multitenancy rather than providing the full Kubernetes stack to each tenant. This makes Kardinal lighter-weight and more efficient if you're primarily concerned with deploying and testing application-level changes.

Tilt works as an in-place hot-reload tool for containers. However, because it performs in-place updates, it doesn't support running multiple parallel and isolated versions of your cluster side-by-side.

That said, the timing of your question is perfect since we are about to push a Tilt integration that allows you to create an isolation flow and use Tilt to hot-reload and update that flow in-place! :)

Nice work on Sequencer! I really liked the Workspace CRD.

Nothing too specific on choosing Istio, but it seemed like a popular and battle-tested option to start the implementation with. Kardinal is a fairly young project (about 2 months old), and we expect it to adopt more "service mesh backends" in the future.