Sebbene negli ultimi tempi le cose abbiano fatto molta strada, nel mio posto di lavoro stiamo ancora discutendo di DLL, contenitori, configurazioni, sostituzioni, condutture, tutte le complessità quando si tratta del codice di spedizione.
Distribuiamo molte delle nostre applicazioni .NET in questo modo:
- Contenitore di tutto con Docker
- Costruisci tutto ed esegui tutti i test in TeamCity
- Invia tutto fino a AWS
L'approccio che adottiamo dice ancora "gestiremo assolutamente tutto dalla nostra parte in termini di imballaggio della nostra app, come verrà eseguito e quindi forniremo alla piattaforma cloud il risultato combinato per gestire la corsa effettiva" .
Il modo in cui vedo il futuro, perché non possiamo semplicemente accedere a AWS / Azure, scrivere tutto il nostro codice applicativo in qualche IDE fornito (magari fornire anche una configurazione di infrastruttura di alto livello), quindi lasciare che la piattaforma Cloud si occupi del resto?
Se hanno il nostro codice sorgente, cos'altro hanno veramente bisogno? Possono eseguire i nostri test, confezionare l'app e distribuirla in base ad alcune configurazioni di base (#instance, restrizioni di rete ecc.). Perché dobbiamo pensare a nient'altro che al codice e impostare pipeline, sostituzioni di configurazione, configurazioni del contenitore, ecc?
Ovviamente Lambdas e serverless sono un approccio a questo, ma hanno stranamente saltato molti passaggi che mettono limiti alla struttura delle funzioni e allo stato ecc. Non possiamo semplicemente scrivere il codice nello stile di un'app "normale" (che è sempre in esecuzione) e per noi ci siamo occupati di tutto in termini di implementazione?
I contenitori per esempio sono impressionanti e utili, ma aggiungono ulteriore complessità alla modalità di esecuzione delle nostre applicazioni. Sono un po 'sorpreso del fatto che dobbiamo ancora parlare di questi concetti nel 2018, quando 10 anni fa avrei previsto che il processo di distribuzione e le sue complicazioni fossero quasi completamente sottratti a noi.