Channels
academy
amazon
arm
azure
cabpr
chinese
ci-cd
danish
deutsch
developer
elemental
epinio
espanol
events
extensions
fleet
français
gcp
general
harvester
harvester-dev
hobbyfarm
hypper
japanese
k3d
k3os
k3s
k3s-contributor
kim
kubernetes
kubewarden
lima
logging
longhorn-dev
longhorn-storage
masterclass
mesos
mexico
nederlands
neuvector-security
office-hours
one-point-x
onlinemeetup
onlinetraining
opni
os
ozt
phillydotnet
portugues
rancher-desktop
rancher-extensions
rancher-setup
rancher-wrangler
random
rfed_ara
rio
rke
rke2
russian
s3gw
service-mesh
storage
submariner
supermicro-sixsq
swarm
terraform-controller
terraform-provider-rancher2
terraform-provider-rke
theranchcast
training-0110
training-0124
training-0131
training-0207
training-0214
training-1220
ukranian
v16-v21-migration
vsphere
windows
Title
w
worried-fountain-60974
05/09/2023, 6:06 PMI think there are some open questions regarding our direction of microservices, grpc comms, API, etc.
1. What gets broken out into microservices? Auth I think is a good target and is in-progress. What else? Let's define that roadmap
2. gRPC comms between services - authenticated or no? I said no on today's call but I wonder if I'm wrong
3. How are we presenting a REST API to external consumers (incl. frontends)?
4. Is an API gateway necessary here or is it overkill?
For #1, I am worried a bit about sprawl. I don't want to do microservices just for the sake of microservices. But I also think that some places it makes sense, auth seems to be one of them. What areas can we define that should or should not be microservice'd?
For #3, to me it is imperative that we offer a human-readable API.
For #4 I know that many of the features we are implementing ourselves are also handled by an api gateway. For instance, authN/Z can be done at a gateway and we delegate that work away from the HF core. But does that make sense for us? How would an api gateway integrate with our existing RBAC model based on kubernetes roles? Should it?
Also if we decide to use an api gateway, we may not want to delegate authN/Z to that service. That would undo a lot of the efforts that Philip AB has made on writing the auth microservice
f
faint-optician-47536
05/10/2023, 1:09 PMthe gateway might just use the autN/Z service.
philip draw outlines of what micorservices we might need. He looked at all of the server / controllers available in garg right now. The conclusion was that we need 1 microservice per server in gargantua iirc.