En todo emprendimiento tecnológico, una de las preguntas más importantes es: ¿cuándo escalar? o mejor dicho, ¿cuándo refactorizar el código de la plataforma a modo de permitirle escalar a un ritmo y magnitud adecuada sin matar los servidores en el intento? ¿cuándo hacemos las cosas bien?
Para responder la pregunta, veamos primero cuando no hacerlo:
No es al comienzo
Muchos ingenieros, en especial aquellos de la vieja escuela, tienden a pensar: si vamos a hacerlo, mejor hacerlo bien desde un comienzo, con una buena arquitectura, un buen diseño y una buena implementación desde el día #1. Nada más equivocado; “lo perfecto es el enemigo de lo suficiente”, y si bien es cierto te ahorrarías mucho trabajo más adelante haciéndolo “bien” desde el principio… debes asegurarte que exista ese principio.
Ya resulta complejo encontrar suficiente dinero para financiar la implementación de una plataforma de alta ingeniería, doble cuando ni siquiera tienes un modelo de negocios validado para respaldarte. Pero, ¿y si necesitas dos? ¿o tres, o cuatro? Puede sonar pesimista, pero la verdad es que buena parte de los emprendimientos famosos solo triunfaron en su segunda o tercera idea, e incluso primeras ideas triunfadoras pasaron por varias iteraciones antes de convertirse en lo que finalmente sería la mina de oro; por eso una de las ideas principales del emprendimiento es “falla rápido, falla barato, y vuelve a levantarte”.
Por tanto, tenemos que comenzar barato aún cuando esto implique una plataforma que muere trágicamente con más de diez usuarios concurrentes y necesite mantención todos los días; porque es imposible saber con antelación cual idea merecerá nos endeudemos hasta el alma para darle alas.
No es cuando lo necesitas
Tentador es entonces postergar el dolor de construir una plataforma escalable hasta el último minuto, sacarle el jugo a tu plataforma con fósforos y elásticos hasta que no resista más. También gran error.
La razón es sencilla de explicar: la planificación, estudio, diseño, implementación y puesta en marcha de una plataforma escalable y de alta ingeniería es un proceso largo y árduo; incluso en equipos con ingenieros de primer nivel tiende a tomar varios meses, y ni hablar de cuando tu “departamento de Informática” es en realidad un sujeto con tantos títulos que parece salido de Game of Thrones: Robert Baratheon, Primero de su Nombre, Administrador de UNIX, Gestionador de Servicios, Hechizero del Terminal, Rey de Rails y React, Embajador de Git y Ocasional Hamster probablemente no tendrá siquiera un esqueleto semi-funcional en menos de tres o cuatro meses, y si intentas presionarlo casi seguro sus cien cargos terminarán en manos de tu hamster de tiempo completo.
Pero claro, durante el desarrollo de la nueva plataforma necesitas seguir vendiendo y seguir creciendo, el mundo no se detiene porque tengas un problema, así es que no queda otra que salir con el viejo prototipo. Por eso esperar hasta que duela es un error; porque el dolor solo aumenta en el tiempo así es que casi seguro ese prototipo no llega sano hasta el final, con la pérdida de clientes y confianza que ello implica; algo que ha causado la muerte de miles de plataformas a lo largo de la historia.
Entonces, ¿cuándo?
La verdad y como le encantaba decir a mi profesor de Gestión, depende. De la complejidad de tu idea, las habilidades de tu equipo, tu ritmo de crecimiento y tantas otras variables. Pero, basado en la experiencia tanto personal como de emprendedores con los que he trabajado cercanamente, el punto que veo más apropiado es el del primer momento de tranquilidad: cuando dejas de festejar con una bebida helada (porque no puedes costear algo más fuerte) cada nueva firma, cuando clientes comienzan a venir a tí sin que tengas que perseguirlos casi con un hacha, cuando un día tirado en tu cama comienzas a hilar la idea de pagarte un sueldo. Como dice el viejo adagio, en la paz, prepárate para la guerra, porque guerra vas a tener; el crecimiento es una bola de nieve que cuesta mover al principio, pero una vez comienza a andar por su cuenta se lleva consigo todo a su paso, incluso tu plataforma con fósforos y elásticos si no la has reemplazado para entonces.
Pero claro, tus fosforitos tienen que aguantar hasta que tengas esa mejor solución, por lo que aparte de comenzar el proceso de alta ingeniería contratando personal y analizando requisitos, es bueno tomar algunas mitigaciones de baja ingeniería para evitar disgustos y alargar tus plazos lo más posible.
Frenando la avalancha
Lo primero y más fácil es ir por la fruta baja de las optimizaciones: si tu motor de bases de datos tiene “Prototipo” en letras gigantes por el costado, probar tu plataforma sobre un motor más profesional de código abierto; si tu framework tiene un “modo desarrollo” y “modo producción”, pasar a este último aunque la depuración le tome cinco veces más a tu desarrollador (quien probablemente esté ocupado con tu nueva plataforma de todas formas). Luego está la fruta un poco menos baja: lanzar tu contenido estático a un CDN, cachear agresivamente tu contenido dinámico, lo que tu Informático multipropósito considere factible en un tiempo razonable. Ajustar las finanzas para pagar el doble o cuádruple mensual en servidores también es buena medida; puede que duela en el bolsillo, pero perder clientes va a doler muchísimo más.
Aparte de ésto, un “truco” que me gusta bastante aunque no es sin peligros es el de preparar de antemano una página estática, netamente informativa, y subirla a un servidor de reserva “en caso de”. Si notas una baja en tu calidad de servicio, filtrar a tus clientes de alto valor y redireccionar tu tráfico nuevo a este respaldo estático puede minimizar el efecto nocivo de una caída completa de un modo no tan dañino para tus finanzas inmediatas; especiamente porque servicios como GitHub proveen hosting de contenido estático gratuito y de muy buen nivel en todo el mundo. Pero, “minimizar”, no “eliminar”: una página informativa lógicamente tendrá menos agarre entre potenciales clientes que tu verdadera plataforma, por lo que redireccionar a una página estática debiese ser tu último plan de contingencia, jamás el único.
En conclusión
Escalar es un problema complejo sin soluciones obvias en un mundo donde el tiempo y dinero no son infinitos, pero algunas reglas básicas se pueden derivar de la experiencia, que espero haber podido aportar desde este blog. Finalmente, la decisión es individual debido a los diversos factores que gobiernan los costos y plazos que una refactorización implica, pero a fin de cuentas ésto de preguntas sin respuestas claras es uno de los gajes del oficio al emprender, ¿no? sin embargo, algo que puedo decir categóricamente es que, como mínimo, es positivo pensar en escalar desde el primer día. Quizás no preparse tecnológicamente, tal vez no hacer nada más que anotarlo en alguna esquina de la pizarra, pero tenerlo en mente y estar consciente que si tenemos éxito, algún día será un problema.
Fuente: ZeroQ
