Cómo construir una infraestructura escalable

Escalar en vertical es hacer más grande el mismo elemento: subir la licencia de rendimiento de un router, sumar tarjetas a un chasis modular, ampliar memoria o cambiar por un modelo superior. Escalar en horizontal es multiplicar elementos iguales y repartir la carga entre ellos: más puntos de presencia, más concentradores de suscriptores, más nodos de caché, más servidores detrás del mismo servicio. La mayoría de las redes de la región crecen en vertical durante los primeros años porque es lo más simple, y descubren tarde que la capa que había que multiplicar era otra.

El crecimiento vertical funciona bien mientras exista margen dentro de la plataforma y el elemento no sea crítico por sí solo. Un ASR1001-X que se licencia de dos coma cinco a veinte gigabits por segundo, un MX480 al que se le suman tarjetas o un chasis al que se le agrega memoria son formas legítimas y baratas de ganar tiempo. El problema aparece cuando el límite ya no es el rendimiento sino la tabla de rutas, la memoria del plano de control o la capacidad del plano de conmutación, porque esos techos no se corren con una licencia.

Hay capas donde la única respuesta correcta es horizontal, y conviene identificarlas desde el diseño: el borde con múltiples tránsitos y peering, donde la resiliencia depende de tener más de un camino; la agregación de suscriptores, donde un solo concentrador concentra también todo el riesgo; el DNS recursivo y los servicios de red, que se replican con costo marginal; y la caché de contenido, que se acerca al usuario multiplicando nodos pequeños. En estas capas, un equipo más grande no reduce el riesgo operativo: lo aumenta.

La forma más barata de hacer escalable una red no es comprar mejores equipos sino comprar menos modelos distintos. Una regla que funciona en operadores regionales es dos modelos por rol como máximo: uno vigente y uno heredado en salida. Un punto de presencia estándar con el mismo switch de agregación de fibra y el mismo equipo de sitio, replicado veinte veces, permite que el técnico de campo trabaje siempre con la misma configuración, que el inventario de repuestos sea corto y que un cambio se pruebe una vez y se aplique veinte con confianza.

El inventario de reserva se calcula, no se improvisa. Un criterio práctico es mantener entre el cinco y el diez por ciento de la flota de cada modelo como repuesto, con un mínimo de una unidad por rol crítico, y una unidad adicional en cada sitio cuyo acceso sea difícil o lento. Un punto de presencia en la sierra peruana, en la selva o en una isla no se atiende el mismo día por más contrato que se firme, y esa distancia es un parámetro de diseño tan real como el ancho de banda del enlace.

Aquí es donde el equipo refurbished certificado cambia la economía del asunto. Comprar repuestos nuevos de cada modelo sería difícil de justificar ante cualquier dirección financiera; comprar repuestos de la misma referencia en condición refurbished certificada, probados antes del envío y con garantía, permite tener el inventario que el diseño exige sin que el CAPEX se dispare. Es el mismo razonamiento que sostiene buena parte de la base instalada de la región: la unidad que reemplaza a otra idéntica no necesita ser de última generación, necesita ser idéntica.

Una infraestructura escalable no es la que no falla, es la que falla en pedazos pequeños. El ejercicio útil consiste en recorrer el diagrama y preguntarse, elemento por elemento, cuántos suscriptores o cuántos servicios caen con él y en cuánto tiempo se restablece el servicio. Ese recorrido suele revelar cosas incómodas: el segundo enlace de fibra que va por el mismo ducto que el primero, las dos fuentes del chasis conectadas a la misma barra de distribución, o el router de respaldo que nunca recibió la configuración actualizada del principal.

La redundancia que sirve tiene nombre propio en cada capa. En transporte, diversidad física real de rutas, no dos hilos del mismo cable. En energía, dos circuitos independientes y verificación de que uno solo sostiene la carga. En enrutamiento, más de un tránsito y presencia en el intercambio local —NAP Colombia, Perú IX, NAP.EC, PIT Chile o IX.br según el país—, que además baja el costo por megabit. En detección de fallas, sesiones de verificación bidireccional para que la convergencia se mida en milisegundos y no en temporizadores de protocolo.

Y después está la parte que no se compra: procedimientos. Ventanas de mantenimiento definidas, respaldo automático de configuraciones, un procedimiento de reversión escrito para cada cambio y pruebas periódicas de conmutación real. Un respaldo que nunca se probó tiene una probabilidad sorprendentemente alta de no funcionar el día que hace falta, y en las revisiones posteriores a incidentes eso aparece una y otra vez. Diseñar para el fallo cuesta poco en la etapa de diseño y resulta carísimo de agregar cuando la red ya está en producción.

El límite práctico de crecimiento de la mayoría de los operadores medianos no es el capital sino la cantidad de cambios manuales que su equipo puede hacer sin equivocarse. Configurar a mano el punto de presencia número cuarenta es estadísticamente una garantía de error, y los errores de configuración causan más caídas de servicio que las fallas de hardware. La salida es convertir la configuración en plantillas con variables y generar el resto: mismo modelo, misma plantilla, mismas convenciones de nombres, mismo esquema de direccionamiento en cada sitio.

No hace falta una plataforma cara para empezar. Un inventario que funcione como fuente única de verdad, plantillas de configuración con variables por sitio, una herramienta de despliegue que aplique cambios de forma repetible y respaldo automático diario de todas las configuraciones cubren la mayor parte del valor. Las interfaces programables de los equipos actuales, tanto las de los grandes fabricantes como las interfaces de scripting de las plataformas más económicas, permiten llegar bastante lejos sin comprar software adicional ni contratar un equipo nuevo.

Lo que sí conviene hacer temprano, porque después duele, es el plan de numeración y direccionamiento. Direcciones de bucle invertido en un bloque reservado, un prefijo IPv6 asignado por punto de presencia con una lógica legible, nombres de equipo que digan sitio y rol, descripciones de interfaz obligatorias y una regla fija para numerar enlaces. Con varios países de la región superando el cincuenta por ciento de tráfico IPv6 hacia los grandes destinos y los intercambios avanzando hacia redes de peering solo IPv6, el plan v6 dejó de ser un ejercicio teórico.

La planificación de capacidad empieza midiendo, no estimando. El insumo mínimo es el percentil noventa y cinco del tráfico en cada enlace, la cantidad de suscriptores activos y la evolución de ambos en los últimos doce meses. Con eso se obtiene la tasa de crecimiento real, que en operadores de mercados en expansión como Colombia, Perú o Ecuador suele ubicarse entre el treinta y el cuarenta por ciento anual. A un treinta y cinco por ciento el tráfico se duplica en poco más de dos años y se multiplica por dos y medio en tres, que es justo el horizonte a presupuestar.

La segunda regla es no planificar al límite. Un enlace que pasa del sesenta por ciento de utilización en hora pico ya no tiene margen para un evento, para una caída de la ruta alternativa o para un mes de crecimiento fuerte, así que la capacidad se dimensiona para que el pico proyectado a doce meses no supere ese umbral. Lo mismo aplica a la memoria del plano de control frente al crecimiento de la tabla global de rutas, que suma decenas de miles de prefijos cada año y no se detiene porque su presupuesto sí lo haga.

Y hay dimensiones que no se miden en gigabits y que igual se agotan. Sesiones concurrentes de traducción de direcciones, del orden de cien a doscientas por suscriptor residencial activo. Suscriptores por concentrador. Unidades de rack, kilovatios y capacidad de refrigeración por sitio. Puertos disponibles en el intercambio local y capacidad contratada de tránsito. Direcciones IPv4, que desde el agotamiento del bloque general de LACNIC en agosto de 2020 se compran entre veinticinco y treinta dólares en el mercado secundario. Un plan que solo proyecta ancho de banda está incompleto.

Cada plataforma adicional en la red trae consigo un conjunto completo de costos que no aparecen en la orden de compra: un inventario de repuestos propio, un ciclo de actualizaciones de firmware con sus propios fallos conocidos, una herramienta de gestión que hay que integrar al monitoreo, una curva de aprendizaje para el equipo de operación y un conjunto de comportamientos particulares que solo se descubren en producción. Ese costo es recurrente y crece con el tamaño de la red, mientras que el ahorro de la compra oportunista ocurrió una sola vez.

El efecto más medible es sobre el tiempo medio de reparación. En una red con dos plataformas, el técnico de guardia conoce ambas. En una red con seis, hay noches en que el equipo que falla es justo el que nadie domina, y el diagnóstico pasa de veinte minutos a tres horas de leer documentación bajo presión. Ese tiempo tiene un costo comercial concreto y rara vez se contabiliza contra la decisión de compra que lo originó. Estandarizar no es una preferencia estética: es una reducción directa del tiempo fuera de servicio.

Eso no significa que la respuesta sea siempre un solo fabricante. Hay razones válidas para introducir una plataforma nueva: una capacidad que la actual no tiene, una diferencia de precio que cambia el proyecto entero, o la conveniencia deliberada de no depender de un único proveedor en la capa más crítica. La regla sana es que cada plataforma nueva tenga un caso escrito que la justifique, un rol delimitado y un plan de repuestos, y que se introduzca por una capa completa en lugar de quedar salpicada por toda la red.

La forma en que la mayoría de las redes de la región financian su crecimiento no es eligiendo entre equipo nuevo y refurbished certificado, sino asignando cada uno a la capa donde tiene sentido. El criterio es la exposición: donde la falla afecta a todos los suscriptores y la tecnología cambia rápido, equipo nuevo; donde la función es estable, replicable y la generación anterior cumple de sobra, refurbished certificado; donde la plataforma ya no se fabrica pero sigue en producción, unidades descontinuadas. Es una decisión por capa, no una postura general de compra.

Un ejemplo de cómo se ve eso en un plan real: borde nuevo cuando hay que sostener tabla completa y crecer a cien gigabits; segundo chasis de núcleo en refurbished certificado, porque su trabajo es estar listo ante un fallo y una unidad idéntica probada cumple exactamente esa función a una fracción del costo; servidores de servicios de red —autenticación, DNS, monitoreo, aprovisionamiento— en refurbished certificado, porque un equipo de dos sockets de hace algunas generaciones mueve esas cargas sin esfuerzo; y laboratorio íntegro en refurbished, porque su valor está en la fidelidad con producción.

El efecto financiero es el que interesa a quien firma: liberar capital de las capas donde no aporta diferencia técnica y concentrarlo donde sí. En la práctica eso suele significar que el mismo presupuesto alcanza para redundar el núcleo, cubrir el inventario de repuestos y adelantar la ampliación del borde, en lugar de comprar una sola capa nueva y quedarse sin margen para el resto del año. La condición de cada equipo se declara siempre en la cotización, con la garantía correspondiente confirmada allí, para que la comparación entre opciones sea real.

Hay síntomas que aparecen antes que el colapso y que conviene tratar como alarmas de planificación. El primero es que cada crecimiento requiere un diseño nuevo: si sumar mil suscriptores obliga a rediseñar la agregación, el problema no es de capacidad sino de arquitectura. El segundo es que los cambios se hacen siempre de madrugada porque nadie confía en poder revertirlos. El tercero es que incorporar a un ingeniero nuevo tarda meses, porque no hay dos sitios iguales y el conocimiento vive en la cabeza de dos personas.

Los indicadores duros son igual de claros: utilización sostenida por encima del setenta por ciento en enlaces sin ruta alternativa, memoria del plano de control por encima del setenta y cinco por ciento en equipos de borde, ausencia de repuesto para algún modelo del que dependen varios sitios, o un tiempo de reposición que se mide en semanas para un equipo crítico. Cualquiera de esos cuatro justifica una revisión del plan, y los cuatro juntos explican por adelantado por qué el próximo incidente será largo.

La buena noticia es que corregir esto rara vez exige rehacer la red. Suele bastar con consolidar modelos en las próximas compras, ordenar el plan de direccionamiento, automatizar lo que ya se repite, cerrar el inventario de repuestos con unidades refurbished certificadas y ubicar el crecimiento en la capa correcta. Es trabajo de un par de trimestres, se puede hacer sin detener la operación y cambia por completo el costo de los tres años siguientes.