Sytex es un monolito Django. Es una base de código de más de un millón y medio de líneas. Las primeras líneas se escribieron cuando las arquitecturas de servicios apenas comenzaban a ganar atención. Hemos decidido que Sytex seguirá siendo un monolito (por ahora), y aquí está nuestro razonamiento.

Nótese el “por ahora”

En todos los aspectos de Sytex, entendemos que existen las herramientas adecuadas para el momento adecuado. Por ejemplo, confiamos en nuestra base de datos relacional para las consultas de texto hasta que los beneficios de una base de datos de búsqueda se hicieron evidentes.

Como startup que aspira al crecimiento, debemos estar atentos al momento adecuado para iterar. Todo lo que sigue pertenece al estado actual de Sytex, y es probable que lo revisemos y posiblemente lo cambiemos en el futuro.

Nuestros tres enfoques: producto, producto, producto

Aunque llevamos varios años operando, tenemos clientes destacados y una buena tracción, todavía nos consideramos pre-PMF. Por lo tanto, nuestro principal objetivo es iterar el producto hasta que encontremos lo que nuestros clientes realmente quieren. Nuestros esfuerzos se dirigen allí, y hemos notado que cuando desviamos el esfuerzo a la evaluación de nuevas tecnologías, perdemos el enfoque. Nos desempeñamos mejor utilizando tecnologías “aburridas” que conocemos a la perfección. De esta manera, podemos asignar todo nuestro presupuesto de incomodidad e impulso para desafiarnos a nosotros mismos a avanzar en el producto. Exploramos nuevas tecnologías solo cuando el producto lo exige o cuando la escala lo requiere.

Somos un equipo compacto al que le gusta moverse rápido

Cuando seamos 100 ingenieros, es probable que el monolito se interponga en nuestro camino, y será necesario desmantelarlo. Lo tenemos en cuenta y nos esforzamos por mantener un código modular y fácil de probar. Pero ahora mismo, creemos que las ventajas de mantener una arquitectura monolítica superan sus desventajas. Entendemos que cada decisión tecnológica implica concesiones, e intentamos evaluar qué características nos benefician o nos perjudican en cada paso. Permanecemos atentos para iterar cuando llegue el momento.

Nos hemos tropezado

Tenemos esta claridad ahora después de explorar alternativas y darnos cuenta de que lo que pensábamos que nos aceleraría en realidad nos ralentizaría. Somos curiosos y nos gusta experimentar. Cada experimento nos enseña algo nuevo. Algunas lecciones impregnan nuestra base de código, mejorando nuestras prácticas. Otras nos muestran que un camino en particular no es el correcto (por ahora).

Específicamente

Lo que nos gusta:

• Tener una única tecnología de backend que todo el equipo pueda utilizar con comodidad.
• Operaciones unificadas, entendidas por todos los desarrolladores. Las configuraciones son claras para todos.
• Es fácil poner en marcha un entorno local muy similar al de producción.
• Iterar en las características rápidamente sin introducir nuevas “incógnitas”.
• La pila Python/Django no es la más eficiente del mercado, pero escalar la capacidad de cálculo es trivial.

Lo que no nos gusta:

• Las implementaciones pueden crecer mucho, lo que aumenta el riesgo de interrupción del servicio.
• Los tiempos de integración aumentan aproximadamente de forma lineal con el número de características añadidas.
• No podemos escalar funcionalidades específicas de forma aislada, lo que aumenta los costes operativos.