Sytex é um aplicativo Django monolítico. É 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ço estavam apenas começando a ganhar atenção. Decidimos que a Sytex continuará sendo um monólito (por enquanto), e aqui está o nosso raciocínio.

Observe o "por enquanto"

Em todos os aspectos da Sytex, entendemos que existem ferramentas certas para o momento certo. Por exemplo, confiamos em nosso banco de dados relacional para consultas de texto até que os benefícios de um banco de dados de pesquisa se tornaram claros.

Como uma empresa iniciante que almeja o crescimento, temos que ficar atentos ao momento certo para iterar. Tudo o que está abaixo se refere ao estado atual da Sytex, e provavelmente o revisaremos e possivelmente o modificaremos no futuro.

Nossos três focos: produto, produto, produto

Embora estejamos operando há vários anos, tenhamos clientes de destaque e uma boa tração, ainda nos consideramos pré-PMF. Portanto, nosso foco principal é iterar o produto até encontrarmos o que nossos clientes realmente querem. Nossos esforços são direcionados para isso, e percebemos que, quando desviamos o esforço para avaliar novas tecnologias, perdemos o foco. Temos um desempenho melhor usando tecnologias "chatas" que conhecemos bem. Dessa forma, podemos alocar todo o nosso orçamento para o desconforto e nos desafiar a desenvolver o produto. Exploramos novas tecnologias somente quando o produto exige isso ou quando a escala exige isso.

Somos uma equipe compacta que gosta de agir rapidamente

Quando formos 100 engenheiros, o monólito provavelmente ficará em nosso caminho e será necessário desmontá-lo. Temos isso em mente e nos esforçamos para manter um código testável e modular. Mas, no momento, achamos que as vantagens de manter uma arquitetura monolítica superam suas desvantagens. Entendemos que toda decisão tecnológica envolve compensações e tentamos avaliar quais recursos nos beneficiam ou prejudicam em cada etapa. Continuamos atentos para iterar quando chegar a hora.

Nós tropeçamos

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

Especificamente

Do que gostamos:

• Ter uma única tecnologia de back-end que toda a equipe possa se sentir confortável em usar.
• Operações unificadas, compreendidas por todos os desenvolvedores. As configurações são claras para todos.
• É fácil criar um ambiente local muito semelhante ao de produção.
• Iteração rápida de recursos sem a introdução de novas "incógnitas".
• A pilha Python/Django não é a mais eficiente do mercado, mas o dimensionamento da capacidade de computação é trivial.

Do que não gostamos:

• As implementações podem se tornar grandes, aumentando o risco de interrupção do serviço.
• Os tempos de integração aumentam aproximadamente de forma linear com o número de recursos adicionados.
• Não podemos dimensionar funcionalidades específicas de forma isolada, o que aumenta os custos operacionais.