3 ms·

> If your teams work with AWS, GCP, or Kubernetes, I’d love to hear about your experiences, pain points, and what you think a product like Argonaut should be ab

> If your teams work with AWS, GCP, or Kubernetes, I’d love to hear about your experiences, pain points, and what you think a product like Argonaut should be able to do. Using Kubernetes in Azure (and this might be Azure specific), there isn't enough easy diagnostics via point/click for production issues. It is a nightmare trying to figure out why something happened and feels like you need to gain more expertise (at time sensitive times!) each time it does. Azure has improved over the years in this regard. But it might be a Kubernetes thing. A cool feature would be "This pod stopped, and didn't restart for 10 minutes" and the reason is "{the reason in plain English}". Kubernetes feels like a leaky thing to throw abstractions over, so the pain with using it is you need to become an expert in it, more so than the serverless offerings that are more genuinely abstracted, like the various app platforms that run the containers directly, or functions. I guess even when managed by the cloud host, it is more serverful (e.g. the need to SSH into VMs to do security hardening checks), but then there is this beast running on those servers you need to understand too. And at that point you need a lot of engineer time anyway and probably a platform separation to deal with it all. So I think if your product could remove some of those kinds of issues it would be good - but then I am still trying to work out "why choose Kubernetes and not some sort of app service" for the majority of users (I am keeping an open mind!)

suryao 3y ago
> A cool feature would be "This pod stopped, and didn't restart for 10 minutes" and the reason is "{the reason in plain English}". There is a little "bulb" icon on the top. That enables a "highlight mode" where you can select some text, usually kubernetes error messages. That is sent to an OpenAI LLM to (1) convert the error into plain english (2) show potential fixes. This is limited by what GPT4 can provide but it is still helpful in some cases. Maybe we should highlight this feature more :) > Kubernetes feels like a leaky thing to throw abstractions over, so the pain with using it is you need to become an expert in it, [..] We believe two things: (1) k8s features exist because they are genuine user needs and we don't want to hide them (2) things get very complex very quickly because the "beast" is complex. Argonaut's approach is what I call "Progressive Discovery". There is a good happy path that works for 80% of use cases. When you need to deviate, we make it easy to work with the underlying primitives to enable your use case. This enables users to move fast without hitting an abstraction ceiling and it keeps the complexity in check. That said - Argonaut is not for everyone. If you have just a service or two, you're better off running it on a hosted runner instead of an aws or gcp or azure. It is going to be cheaper at small scale too.
- quickthrower2 3y ago
  Thanks. I think using AI to help with translating error messages, and perhaps finding the logs that matter, and even being an "expert system" of sorts to give an opinion on what went wrong is useful. Sort of how Windows diagnosis of why something isn't working (like wifi) has got better over the years, probably by adding more and more edge cases!
  - suryao 3y ago
    Yeah, I think there is a long way to go before the AI gets good enough to be trustworthy for infra type tasks but I am super excited for that future.
- frakkingcylons 3y ago
  I hope your AI helper is named Jason :)
  - suryao 3y ago
    Haha
- RadiozRadioz 3y ago
  > sent to an OpenAI LLM to (1) convert the error into plain english It is unfortunate that this is necessary. This feels like a bodge instead of a fix for the underlying issue. Are the error messages genuinely impenetrable / the wrong level of abstraction, or are they appropriate and the engineers simply lack the training? I should point out that I'm not speaking down on the service or the people who use it. I think this is a useful and pragmatic feature, but it feels like those other issues should be looked at before we start throwing everything at LLMs.
tru1ock 3y ago
Sound like a problem https://www.stackstate.com/ https://www.stackstate.com/ is trying to solve.

suryao 3y ago

> A cool feature would be "This pod stopped, and didn't restart for 10 minutes" and the reason is "{the reason in plain English}". There is a little "bulb" icon on the top. That enables a "highlight mode" where you can select some text, usually kubernetes error messages. That is sent to an OpenAI LLM to (1) convert the error into plain english (2) show potential fixes. This is limited by what GPT4 can provide but it is still helpful in some cases. Maybe we should highlight this feature more :) > Kubernetes feels like a leaky thing to throw abstractions over, so the pain with using it is you need to become an expert in it, [..] We believe two things: (1) k8s features exist because they are genuine user needs and we don't want to hide them (2) things get very complex very quickly because the "beast" is complex. Argonaut's approach is what I call "Progressive Discovery". There is a good happy path that works for 80% of use cases. When you need to deviate, we make it easy to work with the underlying primitives to enable your use case. This enables users to move fast without hitting an abstraction ceiling and it keeps the complexity in check. That said - Argonaut is not for everyone. If you have just a service or two, you're better off running it on a hosted runner instead of an aws or gcp or azure. It is going to be cheaper at small scale too.

quickthrower2 3y ago
Thanks. I think using AI to help with translating error messages, and perhaps finding the logs that matter, and even being an "expert system" of sorts to give an opinion on what went wrong is useful. Sort of how Windows diagnosis of why something isn't working (like wifi) has got better over the years, probably by adding more and more edge cases!
- suryao 3y ago
  Yeah, I think there is a long way to go before the AI gets good enough to be trustworthy for infra type tasks but I am super excited for that future.
frakkingcylons 3y ago
I hope your AI helper is named Jason :)
- suryao 3y ago
  Haha
RadiozRadioz 3y ago
> sent to an OpenAI LLM to (1) convert the error into plain english It is unfortunate that this is necessary. This feels like a bodge instead of a fix for the underlying issue. Are the error messages genuinely impenetrable / the wrong level of abstraction, or are they appropriate and the engineers simply lack the training? I should point out that I'm not speaking down on the service or the people who use it. I think this is a useful and pragmatic feature, but it feels like those other issues should be looked at before we start throwing everything at LLMs.

tru1ock 3y ago

Sound like a problem https://www.stackstate.com/ https://www.stackstate.com/ is trying to solve.