Feda /dev/ - No Javascript allowed

#12570 Paga las licencias, primer aviso.

#12577 Lo normal es montar un servicio en alta disponibilidad del que tirasen el resto de aplicaciones, cada uno con un acceso a medida, en caso de redis, su cola con sus permisos para escribir y leer y demás.

Montar adhoc por cada servicio un redis es un suicidio operacional salvo que esos servicio sean tan grandes y tengan tanta identidad y criticidad que es mejor tenerlos separados por si tienes problemas de rendimiento descartar que haya otra aplicación consumiendo de más, pero en las plataformas lo que se hace es montar los servicios que se van necesitando para el uso de todos, de hecho tecnologías como k8s y demás fomentan esto aunque cada vez van más a nube que usas servicios nube directamente conectados, tener un k8s donde tienes varias aplicaciones cada una aislada en su namespace y con usuarios para cada uno los servicios periféricos que necesitan como una base de datos o directamente una capa de API Gateway para todos que gestiones los certificados y no uno para cada uno.

Esto te responde a la duda?

#12577 Microservice Chasis https://microservices.io/patterns/microservice-chassis.html para cross cutting concerns como caching (Redis) y no andas duplicando cosas.

Luego ya está los niveles de caching y dónde los lo pones: Service vs Client, o en los dos, en datos, etc..

#12578 Me estas diciendo que añada una capa intermedia entre cualquier aplicación de usuario final, para gestionar ahi el tema de permisos y visibiliades.Corrigeme si lo digo mal. Si esa seria la idea, pero en la practica no me he puesto a diseñarlo aun.

#12579 Si claro pasaria por una capa intermedia de permisos donde ahi expondria multiples apis y multiples backends. noveo si los permisos deberia meterlos antes de estos servicios o despues, como tengo unsolo servicio que mehace de puente a todas las apis y backends ??? Me veria obligado a darle la vuelta y meter los permisos detras de las peticiones, intercepto peticion y filtro. Nse como hacer esto en la practica .

USUARIO FINAL
API 0 - API 1 - BACKEN END USUARIO FINAL
CAPA INTERMEDIA DE PERMISOS

vs

USUARIO FINAL
CAPA INTERMEDIA DE PERMISOS
API 0 - API 1 - BACKEN END USUARIO FINAL

La api 0, 1 por ejemplo serviria datos de las bases de datos, el back end usuario final podria ademas gestionar entidades.

No veo a nivel arquitectura como deberia separarlo, me lo voy a mirar.

Ademas tengo la duda de gestion de entidades internas de laplataforma, que para mi eso seriaun backend nuevo interno y unos permisos especiales... en teoria con este modelo que proponeis se podria.

#12581 Si exacto, esto es lo que me parece obvio y tenia asumido.

#12580 uff pretendo alejarme de cosas de microserviciosla verdad... el ejemplo de la redis en verdad no me interesa ahoramismo, solo debo poderpermtirlo. era un ejemplo para el tema de acoplamiento. no quierohacer mil micro servicios.

Disculpad ortografia me han dado un laptop nuevo y el espacio va raruno.

Demasiadas cosas serias.

#12583 Tío, eso es una wec, joder. Con una base de datos con su perfil y todo eso.

#12583 Uff que buena referencia. Mis putos dies. Creo que eso era de @eondev no?

#12582 De arquitecturas IoT y de ingesta de datos no te puedo ayudar porque la verdad no se como funcionan, pensaba que hablabas de como se gestiona en una plataforma para aplicaciones.

Lo que veo es que son dos tipos de input no? (de lo que has pintado)
Por un lado tienes todo el IoT que llega al kaftka y éste estará expuesto a todo internet claro, tendrás que ver como securizarlo pero entiendo que las conexiones IoT to Katfka están securizadas por certificado cliente.
Por otro lado, tienes procesos que cogen datos del Kaftka, los transforman y los vuelven a meter homogeneizados y estos datos son los que van a las bases de datos.

Y luego hay unos usuarios finales que consumen esos datos a través de unos Webservices (WS) que tu montas entorno a esas bases de datos no y es donde está realmnete tu pregunta, ya que prevees que como van a tener uso intensivo y manejar mucho volumen necesitarás cachés.

El tema de identidades lo delegaría en un LDAP y a poder ser que cada cliente tenga su certificado cliente y sea él el responsable y tu en los WS filtras por el DN. Tendrás que ver como dar esos certificados, que es la parte compleja, seguramente crearás una CA, sacas una subCA de esa CA (para control de brechas de seguridad) y con esa firmas esos certificados salvo que tengáis pagada una.