Perché abbiamo smesso di essere un negozio .NET

Per la maggior parte della nostra storia, eravamo un negozio .NET. Rilasciamo ancora molto .NET — è un ecosistema maturo, performante e profondamente capace, ed è lo strumento giusto per molti lavori enterprise. Ma intorno al terzo cliente il cui problema voleva davvero Go e ha ricevuto .NET perché era quello che vendevamo, abbiamo smesso di descriverci in quel modo.

Il conflitto di interesse dello stack singolo

Le agenzie a stack singolo hanno un conflitto di interesse strutturale con i propri clienti. Si consiglia sull'architettura; si viene pagati solo se l'architettura usa lo stack che si vende. Il consiglio si piega. Si piega silenziosamente, con giustificazioni che suonano ragionevoli, ma si piega.

Un team che fa solo .NET troverà una risposta .NET a ogni problema. Lo stesso farà un team che fa solo Node, o solo Python. Nessuno di loro è sbagliato di proposito. Sono sbagliati per incentivo.

Cosa significa davvero stack-agnostico

Non significa che conosciamo ogni stack ugualmente bene. Nessuno lo fa. Significa che i nostri ingegneri senior hanno rilasciato sistemi in produzione su più stack e hanno il giudizio per raccomandare quello giusto per il problema — incluso raccomandare di non assumere noi, quando la risposta giusta è qualcosa che non facciamo.

Quest'ultima parte è il test. Un'agenzia disposta a dire "questo dovrebbe essere Elixir e non facciamo Elixir" è onesta. Un'agenzia che trova il modo di adattare ogni problema al proprio stack sta vendendo, non consigliando.

Come viene davvero fatta la scelta

La selezione dello stack è per lo più a valle di quattro cose, all'incirca in quest'ordine:

Il team che si ha o si assumerà conta più della purezza. Uno stack teoricamente migliore che non si riesce a staffare è peggio di uno leggermente peggiore che si può. Prima si parla del mercato delle assunzioni.

I vincoli di compliance e dati restringono il campo rapidamente. I carichi di lavoro dei servizi finanziari su certi cloud regionali collassano le opzioni a due o tre. La sanità le restringe ulteriormente. Questi vincoli sono non negoziabili; tutto il resto è preferenza.

La superficie di integrazione con ciò che si ha già. Riscrivere il mondo per un runtime marginalmente migliore raramente ne vale la pena. Si ottimizza per ciò che si può rilasciare il prossimo trimestre, non per l'eleganza teorica.

Il profilo di performance — solo dopo i primi tre. La maggior parte del software enterprise è limitata da I/O, rete e design del database, non dalla scelta del linguaggio. Scegliere Go rispetto a Node "per le performance" prima di sapere se il collo di bottiglia è il linguaggio è, nel novanta percento dei casi, prematuro.

Cosa siamo ancora

Siamo ingegneri senior che si trovano molto a loro agio in .NET, JVM, Node, Python e Go, su Azure, AWS e GCP. Abbiamo opinioni su tutti loro e vi diremo quale si adatta alla vostra situazione.

Non siamo, più, un negozio che ha una sola risposta.