Arquitecturas para la nube

Balancear la asignación de peticiones globalmente con un DNS que geolocalice al cliente. Los datos pesados se pueden obtener de réplicas próximas o rápidas (por ejemplo, un CDN), mientras que los datos “exclusivos” (que sólo están replicados en algunos centros de datos) se pueden obtener a través del punto de acceso más próximo (que internamente usa el enlace privado que interconecta todos los centros con suficiente velocidad y latencia)

Mantener al tanto a los interesados usando paso de mensajes. Esto permite que dispongan de las últimas novedades tanto el servicio que recibe una petición (y que dispone de estas novedades en su caché local) como el servicio que tiene que almacenarla a largo plazo (base de datos)

Procurar que la unidad básica sea el servicio, accesible vía API. Esto permite mayor flexibilidad y desacoplamiento. Como tantas cosas “mejores”, una arquitectura orientada a servicios (SOA) cuesta esfuerzo. Por eso lo habitual es comenzar con una arquitectura monolítica y fuertemente acoplada, y mantenerla hasta que no escale más. Momento en el cual se comienza la migración a SOA :-p

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *