Devo introdurre gli strumenti anche se potrei non averne bisogno adesso

Alcune decisioni di design non possono essere facilmente annullate. Ecco perché sono fatti presto.

Nonostante gli avvertimenti sull'ottimizzazione prematura, è in realtà una buona idea prendere decisioni di progettazione decenti fin dall'inizio, incluso avere un'architettura ragionevole e fare un uso ragionevole delle strutture dati. La complessità non è necessariamente un prerequisito; alcune delle soluzioni più scalabili e manutenibili sono anche le più semplici.

Tuttavia ...

Quando sei una startup, il bisogno più urgente è quello di arrivare sul mercato rapidamente, non di ingegneria su larga scala. Alcune delle startup di maggior successo nel mondo alla fine hanno riprogettato i loro sistemi per ospitare enormi basi di utenti, tra cui Facebook, Twitter e l'onnipotente Google. Ma lo hanno fatto dopo avevano già una grande base di utenti e un mucchio di soldi, quando diventava un buon problema.

Il novantacinque percento di tutte le startup non diventerà mai così grande, quindi progettare i sistemi da cima a fondo non ha assolutamente senso.

Molte persone sembrano pensare che strumenti come Kubernetes siano solo per le persone che hanno bisogno di una scala "massiccia". In realtà, i problemi risolti da un programma di pianificazione si manifestano a volumi molto modesti. Se provi a lanciare le tue soluzioni, ti ritroverai molto presto a reinventare la ruota per fare cose come aggiornamenti continui, controlli di integrità, gestione della capacità, test di a / b, adattamento degli ambienti di sviluppo e test agli ambienti di produzione, guasti / aggiornamenti hardware, registrazione, metrica e così via. Questo è utile anche su cluster di nodi 1-3.

Se sei una grande azienda puoi facilmente permetterti di mantenere un sistema homegrown mentre passi a qualcos'altro. Se sei una società più piccola che non può semplicemente avere un "nuovo team di pianificazione" completamente dedicato, è estremamente doloroso aver bisogno delle funzionalità di uno scheduler, ma non avere le risorse per passare a una, perché sono tutte dedicate a mantenere il tuo vecchio sistema homegrown. Se potessi tornare indietro nel tempo a quando il mio team pensava per prima cosa sarebbe stato più facile usare gli script Python "solo per ora", questo è quello che vorrei dire loro.

Dalla tua descrizione, non vedo una contraddizione tra i due, perché i problemi sono molto diversi, e penso che potresti interpretare erroneamente il significato di "complessità essenziale"

Quando l'articolo su Kubernetes menziona la "complessità essenziale", lo interpreto come una complessità essenziale o accidentale *.

• La complessità essenziale: la complessità della soluzione necessaria a causa della complessità del dominio del problema. Per esempio. se si fa un'applicazione di contabilità, la complessità della contabilità a partita doppia sarebbe una complessità essenziale.
• Complessità accidentale: la complessità introdotta quando realizziamo un'applicazione software. Un esempio di complessità accidentale sarebbe il codice per gestire le rimozioni orfane nel database relazionale perché il tuo ORM non lo gestiva bene. Una certa complessità accidentale è inevitabile, ad es. occupandosi di ridimensionamento.

Quindi esaminiamo il problema della distribuzione per i due casi citati:

• Reddit - La complessità essenziale si riferisce a post e commenti, ecc. La complessità introdotta negli script di distribuzione rientra in una complessità accidentale.
• Kupernetes - Essendo uno strumento correlato alle distribuzioni in un ambiente scalabile, queste due cose diventano una complessità essenziale (ho poca esperienza con Kubernetes, quindi quanto bene risolve questi problemi non è per me un commento)

Quindi, se parli di introdurre uno strumento di cui non hai bisogno in questo momento ma che potrebbe essere necessario in futuro, suona come inutile complessità accidentale.

Ricorda, proprio come Robert Harvey ha scritto, per una startup, il time to market dovrebbe essere la tua preoccupazione. E sarà perfettamente giusto introdurre ora una certa complessità accidentale al fine di ottenere un time-to-market più rapido. Potresti anche introdurre uno strumento di cui hai bisogno in questo momento, ma non in futuro!

E stai attento a prendere decisioni difficili da cambiare in anticipo. Presto è il momento in cui hai la minima conoscenza per aiutarti a prendere la decisione giusta. Se riesci a impostare te stesso in modo da poter posticipare tali decisioni, ti servirai parecchio.

E ricorda anche che i problemi di ridimensionamento possono essere affrontati gradualmente. Normalmente non hai bisogno di gestire grandi quantità il giorno 1 (sostituendo un'applicazione esistente con una grande base di utenti che è l'unica eccezione che mi viene in mente in questo momento)

* Credo che i termini Complessità accidentale ed essenziale siano stati introdotti nel libro "No Silver Bullet", che sfortunatamente non ho ancora letto