Sytex is a Django monolith. It’s a codebase of over one and a half million lines. The first lines were written back when service architectures were just starting to gain attention. We’ve decided that Sytex will remain a monolith (for now), and here’s our reasoning.

Note the “for now”

Across all aspects of Sytex, we understand that there are right tools for the right time. For instance, we relied on our relational database for text queries until the benefits of a search database became clear.

As a startup aiming for growth, we have to stay alert to the right time to iterate. Everything below pertains to Sytex’s current state, and we’ll likely revisit and possibly change it in the future.

Our three focuses: product, product, product

Even though we’ve been operating for several years, have prominent clients, and good traction, we still consider ourselves pre-PMF. Therefore, our main focus is iterating the product until we find what our customers truly want. Our efforts are directed there, and we’ve noticed that when we divert effort to evaluating new technologies, we lose focus. We perform better using “boring” technologies that we know inside out. This way, we can allocate all our discomfort budget and drive to challenge ourselves into advancing the product. We explore new technologies only when the product demands it or when scale requires it.

We’re a compact team that likes to move fast

When we’re 100 engineers, the monolith will probably get in our way, and it will be necessary to dismantle it. We keep that in mind and strive to maintain testable, modular code. But right now, we find that the advantages of maintaining a monolithic architecture outweigh its disadvantages. We understand that every tech decision involves trade-offs, and we try to evaluate which features benefit or harm us at every step. We remain vigilant to iterate when the time comes.

We’ve stumbled

We have this clarity now after exploring alternatives and realizing that what we thought would accelerate us would actually slow us down. We’re curious and like to experiment. Each experiment teaches us something new. Some lessons permeate our codebase, improving our practices. Others show us that a particular path isn’t the right one (for now).

SpecificallyWhat we like:

• Having a single backend technology that the entire team can feel comfortable using.
• Unified operations, understood by all developers. Configurations are clear to everyone.
• It’s easy to spin up a local environment very similar to production.
• Iterating on features quickly without introducing new “unknowns.”
• The Python/Django stack isn’t the most efficient on the market, but scaling compute capacity is trivial.

What we don’t like:

• Deployments can grow large, increasing the risk of service disruption.
• Integration times increase roughly linearly with the number of features added.
• We can’t scale specific functionalities in isolation, which raises operational costs.

Sytex es un monolito de 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 empezaban a llamar la atención. Decidimos que Sytex seguirá siendo un monolito (por ahora), y aquí está nuestro razonamiento.

Presten atención al “por ahora”

En todos los aspectos de Sytex, entendemos que hay herramientas adecuadas para cada momento. Por ejemplo, nos apoyamos 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 apunta al crecimiento, tenemos que estar atentos al momento adecuado para iterar. Todo lo que sigue corresponde al estado actual de Sytex, y es probable que lo revisemos y posiblemente lo cambiemos en el futuro.

Nuestros tres focos: producto, producto, producto

Aunque llevamos varios años operando, tenemos clientes destacados y buena tracción, todavía nos consideramos pre-PMF. Por lo tanto, nuestro foco principal es iterar el producto hasta encontrar lo que nuestros clientes realmente quieren. Nuestros esfuerzos están dirigidos ahí, y hemos notado que cuando desviamos esfuerzo a evaluar nuevas tecnologías, perdemos foco. Rendimos mejor usando tecnologías “aburridas” que conocemos a fondo. De esta manera, podemos destinar todo nuestro presupuesto de incomodidad y nuestras ganas de desafiarnos a avanzar 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, el monolito probablemente se interpondrá en nuestro camino, y será necesario desmantelarlo. Lo tenemos presente y nos esforzamos por mantener un código testeable y modular. Pero en este momento, encontramos que las ventajas de mantener una arquitectura monolítica superan a sus desventajas. Entendemos que toda decisión técnica implica trade-offs, e intentamos evaluar qué características nos benefician o perjudican en cada paso. Nos mantenemos atentos para iterar cuando llegue el momento.

Nos hemos equivocado

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

En concretoLo que nos gusta:

• Tener una única tecnología de backend con la que todo el equipo se siente cómodo.
• Operaciones unificadas, entendidas por todos los desarrolladores. Las configuraciones son claras para todos.
• Es fácil levantar un entorno local muy similar al de producción.
• Iterar sobre las funcionalidades rápidamente sin introducir nuevas “incógnitas”.
• El stack de Python/Django no es el más eficiente del mercado, pero escalar la capacidad de cómputo es trivial.

Lo que no nos gusta:

• Los despliegues pueden volverse grandes, aumentando el riesgo de interrupciones del servicio.
• Los tiempos de integración aumentan de forma aproximadamente lineal con la cantidad de funcionalidades agregadas.
• No podemos escalar funcionalidades específicas de forma aislada, lo que eleva los costos operativos.

A Sytex é um monolito em Django. É uma base de código com mais de um milhão e meio de linhas. As primeiras linhas foram escritas quando as arquiteturas de serviços estavam apenas começando a ganhar atenção. Decidimos que a Sytex continuará sendo um monolito (por enquanto), e aqui está o nosso raciocínio.

Repare no “por enquanto”

Em todos os aspectos da Sytex, entendemos que existem ferramentas certas para cada momento. Por exemplo, contamos com o nosso banco de dados relacional para consultas de texto até que os benefícios de um banco de dados de busca ficaram claros.

Como uma startup que busca crescimento, precisamos ficar atentos ao momento certo de iterar. Tudo o que segue diz respeito ao estado atual da Sytex, e provavelmente iremos revisitá-lo e possivelmente mudá-lo no futuro.

Nossos três focos: produto, produto, produto

Mesmo já operando há vários anos, com clientes de destaque e boa tração, ainda nos consideramos pré-PMF. Portanto, nosso foco principal é iterar o produto até encontrar o que nossos clientes realmente querem. Nossos esforços são direcionados para lá, e percebemos que quando desviamos esforço para avaliar novas tecnologias, perdemos o foco. Temos um desempenho melhor usando tecnologias “chatas” que conhecemos de cabo a rabo. Dessa forma, podemos destinar todo o nosso orçamento de desconforto e a nossa vontade de nos desafiar para avançar o produto. Exploramos novas tecnologias apenas quando o produto exige ou quando a escala requer.

Somos uma equipe enxuta que gosta de se mover rápido

Quando formos 100 engenheiros, o monolito provavelmente vai atrapalhar, e será necessário desmontá-lo. Mantemos isso em mente e nos esforçamos para manter um código testável e modular. Mas neste momento, achamos que as vantagens de manter uma arquitetura monolítica superam suas desvantagens. Entendemos que toda decisão técnica envolve trade-offs, e tentamos avaliar quais funcionalidades nos beneficiam ou prejudicam a cada passo. Permanecemos atentos para iterar quando chegar a hora.

Nós tropeçamos

Temos essa clareza agora depois de explorar alternativas e perceber que o que achávamos que nos aceleraria na verdade nos deixaria mais lentos. Somos curiosos e gostamos de experimentar. Cada experimento nos ensina algo novo. Algumas lições permeiam nossa base de código, melhorando nossas práticas. Outras nos mostram que um determinado caminho não é o certo (por enquanto).

EspecificamenteO que gostamos:

• Ter uma única tecnologia de backend com a qual toda a equipe se sente confortável.
• Operações unificadas, compreendidas por todos os desenvolvedores. As configurações são claras para todos.
• É fácil subir um ambiente local muito parecido com o de produção.
• Iterar sobre as funcionalidades rapidamente sem introduzir novas “incógnitas”.
• A stack Python/Django não é a mais eficiente do mercado, mas escalar a capacidade de computação é trivial.

O que não gostamos:

• Os deploys podem ficar grandes, aumentando o risco de interrupção do serviço.
• Os tempos de integração aumentam de forma aproximadamente linear com a quantidade de funcionalidades adicionadas.
• Não conseguimos escalar funcionalidades específicas de forma isolada, o que eleva os custos operacionais.