warehouse: you connect your warehouse AND astrobee will store your semantic layer (ontology) in your warehouse. it will also use your warehouse to do computation
connect source: you'll use our warehouse under the hood, and when you connect your source systems, data will end up being stored in our warehouse. thats where computation and ontology storage will happen
but i agree it's confusing. we are considering changing the naming around to account for this. i appreciate the feedback!
this is still an early beta, so at the moment everything is only available with OpenAI's API. however, for people who want to use it in a higher security environment, we'll support switching OpenAI with any hosted model API including on-premise or models held in private VPCs. that way people can manage their data with no exfiltration to a third party
Hi,I’m a cofounder of AstroBee and I wanted to share our work with the community.AstroBee is an automatic semantic layer generator for your business. It brings data together from different locations, storing it either in your data warehouse or in one we host. Then, AstroBee scans your data and models it to create an integrated source of truth (we call it an ontology because it’s structured like...
you can have an attitude towards spending the short hours you have on this earth attempting to produce quality work that others appreciate and make their lives easier in some way, as opposed to writing those hours off as sold to someone else
wouldn't have guessed that. that NYC pull is huge
imo any hope of really leveraging llms in this context needs this + human review on additions to a shared ontology/semantic layer so most of the nuanced stuff is expressed simply and reviewed by engineering before business goes wild with it
could be cool to see that unbundled into its own thing though
you can even use ingress and special URL for multiple services in a one-off deviation, but things get really messy when you want to test state-level things too like db migrations.
besides making it more convenient to handle the chain of dependencies and duplicating all the services, we also want to make it easier to test db/state migrations and larger features without having to do an expensive e2e application deploy
we use trace headers to keep track of where the request originally came from to route it to the right database. it's transparent to service B as long as service B is properly propagating the request context from incoming request to outgoing requests
environment is an incredibly overused word for devs. development environment might even mean IntelliJ, not a k8s cluster with your dev versions inside of it
been going back and forth a lot on how to make this more clear without introducing additional confusion
in reality what you're doing with namespace-based deploys or telepresence is equally "lightweight" to what you're doing with Kardinal. it's just that (at least in our phrasing), those don't quite constitute a separate "environment" as state is shared between any developers working at the same time
Kardinal matches those approaches in terms of light-weightedness, but offers state isolation guarantees too (like isolation for your dbs, queues, caches, managed services, etc). so in comparison to "ephemeral environment" approaches that give state isolation, we do believe we're doing this in the most lightweight way possible by implementing that isolation at the layer of the network request rather than by duplicating deployed resources
and thanks for the +1 on the name haha, we called it Kardinal because the goal is to deploy only "unique elements of your ephemeral environments" across the organization, i.e. number of services deployed equals the "cardinality" of service versions