what are these "nasty surprises"? they're really not that different
HN user
galenmarchetti
building astrobee.ai
https://twitter.com/GalenMarchetti
then why hasn't the central bank done this yet
yep if you want to just go straight to the docs, they're here: https://docs.astrobee.ai/
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
that's a fair point. we use "ontology" throughout the product because of the influence from Palantir, and the fact that the structure we use in the product (from palantir) is in fact a bit different from what most people would create in semantic layers like dbt or cube
but i agree it's confusing. we are considering changing the naming around to account for this. i appreciate the feedback!
thank you! that's exactly where we're going with this. we're still in the early days, so let us know how you get along!
we're using OpenAI's API for business. they don't train on data sent to the business api, unlike the consumer tier
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
have worked with waku in the past, love the vision
it depends on whether you want to live life with work-as-someone-paying-for-your-time or whether you want to live life as work-as-perfecting-and-delivering-on-craft
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
they kept 2 nonstop routes to NYC, 1 to Chicago, 1 to SF, but none to DC
wouldn't have guessed that. that NYC pull is huge
yeah I agree with this - good text2sql is essential but just one part of a larger stack that will actually get there. Seems possible tho
and then add in ambiguity in the business terms / intention behind the query. still a big need for something like semantic layer or ontology to sit between business and at least right now that stuff hasn’t been automated away yet (it should be though)
still need someone to build the semantic layer, why not use text2sql or something similar for that
there’s two kinds of people using AI to generate SQL…those who say it’s already solved and those who say it’ll be impossible to ever solve
yeah we’re doing something similar under the hood at AstroBee. it’s way way way easier to handle joins this way.
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
i do think there's a lot of opportunity for the AI-assisted kubernetes help feature
could be cool to see that unbundled into its own thing though
"clown car that fell into a gold mine" is such a brilliant image. im not familiar with twitter in those days, but I've seen other companies that definitely match this description
founder/dev on this project here - exactly!! still trying to figure out the wording between "kubernetes development environment", "kubernetes-based application deploys", "application environments in-cluster", etc...i can tell it's not quite coming across clearly in the first go, but yeah you got the idea
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
service B doesn't actually know that - it happens at the level of the service mesh (you have to have a service mesh installed, right now just supporting istio but we plan on making that configurable)
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
founder/developer here - yeah, in the last couple weeks I've had in the back of my mind switching the wording to "lightest-weight application deploys on Kubernetes" or something like that.
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
founder/developer on Kardinal here - that's a good question
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
fast fix! appreciate this
What does your writing process look like when you set out to write an entire book? I know a lot of HN users have blogs, but the idea of writing a whole book seems daunting. Would love to hear the details of your experience and what it looked like particularly for Tripping on Utopia
why? loving aws right now, which products do you think they would keep vs kill
points #3 and #4; "user-friendly helm chart creation" and "values.yaml is an antipattern"...I think we're just all stuck in this horrible middle ground between "need static declarative configurations for simplicity of change management/fewest chances to mess it up" and "need dynamic, sometimes even imperative logic for flexibility, configurability, and ease of development"
several commenters have mentioned Cue/Jsonnet/friends as great alternatives, others find them limiting / prefer pulumi with a general purpose language
our solution at kurtosis is another, and tilt.dev took the same route we did...adopt starlark as a balanced middle-ground between general-purpose languages and static configs. you do get the lovely experience of writing in something pythonic, but without the "oops this k8s deployment is not runnable/reproducible in other clusters because I had non-deterministic evaluation / relied on external, non-portable devices"
Yes! Nailed it :D
Ahh this is the closest one to what we originally meant haha..(founder here). but the intent was to mitigate the impact of “kurtosis” on your system by enabling engineers to see how the whole environment worked in testing (and other parts of the development process). We also have a love for taleb’s books about excelling in uncertainty, in high “Kurtosis” environments, so going with the theme made sense for us.
But I see from the comments it is decently confusing!
(Founder here) I love the thought! We definitely have a smoother understanding of the name from the users in that space from anecdotal experience, but actually it comes from both our own love of the concepts in the book “antifragile” by Taleb that talks about excelling in volatile (high Kurtosis) environments, plus the fact that our first users used it for E2E test environments which we imagined were catching “tail risk” bugs between components.
Although I see how the overloading of the term is pretty confusing here
Hi! Founder here, and apologies if reposting content in other comments above is too much. I can give some context on the name, although of course ideally context from me wouldn’t be necessary if the name was easier to parse.
Our very first users were test engineers who used our tool to spin up test environments for E2E and integration tests, and we called it Kurtosis because we imagined them catching “tail” errors that were out of the expected norm for devs focused on only one component of the system. We imagined a tool that detects bugs happening in a “high Kurtosis” error environment.
We’re also big fans of the book “antifragile” by Taleb, about strategies in general for excelling in the face of volatility environments (can stretch that to kind of look like high “Kurtosis” environments)
The combination of those two things felt right when we started building - but I can see all the confusion it’s now causing here!
Founder here…have definitely seen this. Trying to find some of our users’ open source work on public GitHub repos to see what they’re doing can be tricky because it does pop up a lot of data science / stats work that’s totally unrelated!
Hi! Founder here…thanks for the feedback, deeply appreciate it. Especially the last bit about how hard naming is haha.
To give a bit of context on the name, our first set of use cases was all about test engineers using this tool to testbeds for end to end or large scale integration tests.
Since we are pretty mathy ourselves, we called it “Kurtosis” because we imagined the distribution of errors arising from service to service interactions to have a high Kurtosis - in the sense that there’s a lot of errors you wouldn’t “expect” to happen from a first principles understanding of each component. You’d have put them all together to see those, they’d be “far off the mean”. There’s also a lot of stuff about how we view our work, where we like exposing ourselves to outlier opportunities that we hadn’t previously imagined to produce results that would only happen in a “high Kurtosis results distribution”.
Now that being said, I definitely hear what you’re saying. It’s not obvious that’s where the name came from…and just because we were thinking that when we named it doesn’t mean it resonates with our users the same way!