←back to thread

320 points benocodes | 1 comments | | HN request time: 0s | source
Show context
otterley ◴[] No.41897080[source]
Looks very Azure-centric. Both installation guides (https://drasi.io/how-to-guides/install-sample-applications/b... and https://drasi.io/how-to-guides/install-sample-applications/c...) require Azure to work.

And then there's this:

> Installing Drasi in an EKS cluster can be significantly more complex than a standard installation on other platforms. Instead of downloading a CLI binary using the provided installation scripts, this approach requires modifying the source code of the Drasi CLI and building a local version of the CLI.

Is this an actual requirement or just the current easy path?

replies(7): >>41897227 #>>41897293 #>>41897541 #>>41897811 #>>41897940 #>>41901203 #>>41909560 #
stackskipton ◴[] No.41897811[source]
Azure SRE here, it doesn't appear to have any Azure dependencies. CLI rebuild seems to be that "drasi init" assumes Azure Kubernetes Service built in StorageClasses for Kubernetes PVC for Redis and Mongo and thus fails when running against EKS. I assume same thing would be required on GKE. Yes, it should be more modular but MVP.

As for other stuff, it's using Gremlin Query Language or Postgres which are both open. In fact, it's going out of way it's not to use Azure authenication as loading connection string as Kubernetes secret is 100% AGAINST Azure Kubernetes Best Practice. Best Practice would be Workload Identity.

replies(2): >>41899666 #>>41901190 #
1. ◴[] No.41901190[source]