Considerazioni sullo sviluppo mediante macchine virtuali [chiuso]

Lavorerò come lead di sviluppo per una startup e ho suggerito di usare VM per lo sviluppo. Non sto parlando di ogni sviluppatore che ha un desktop con VM per test / sviluppo, intendo avere un server rack in cui tutte le VM sono gestite e gli sviluppatori lavorano da un microPC (ChromeOS qualcuno?) Localmente, o anche da remoto da casa computer.

Per me, i vantaggi sono il fatto che è estremamente scalabile, più economico a lungo termine, più facile da gestire e che utilizziamo l'hardware il suo massimo potenziale. Per quanto riguarda gli svantaggi, non riesco a pensare a particolari showtopper diversi da quelli di cui avremo bisogno di qualcuno per configurare / mantenere detta configurazione.

Speravo che alcuni di voi potessero avere un assetto simile nel luogo di lavoro ed essere in grado di ponderare con le proprie opinioni. Grazie.

Cosa speri di risparmiare, come una frazione del budget di sviluppo? Mi sembra che ti preoccupi per un epsilon. Il costo delle macchine per gli sviluppatori è inferiore al 5% del costo totale per mantenere uno sviluppatore nel personale. Pertanto l'unica domanda importante è "farà risparmiare tempo agli sviluppatori?" Potrebbe, se non devono passare il tempo a installare e aggiornare il software di sviluppo. Oppure potrebbe costare tempo, se la rete si interrompe, o il server si spegne, o, molto probabilmente, se la reattività attraverso la rete è la minima mancanza. Lo sviluppo moderno dipende dall'interazione tasto per tasto con un IDE, o almeno un editor molto intelligente. Ritardare tale interazione anche di poche decine di millisecondi distrugge la produttività degli sviluppatori. C'è anche il costo per gli sviluppatori di imparare questo nuovo modo di lavorare.

Queste non sono obiezioni alle macchine virtuali, ma potenziali obiezioni allo sviluppo remoto.

Penso che tu sia un soldo saggio e uno sciocco.

Prima di tutto, i costi delle macchine sono insignificanti rispetto al costo di uno sviluppatore. Dovresti lavorare per massimizzare la produttività, non minimizzare i costi della macchina.

In secondo luogo, la latenza (non la larghezza di banda) è la chiave per molte attività di programmazione, in particolare l'editing di testo. Per ogni dollaro / sterlina / euro che risparmi sulle macchine per i tuoi sviluppatori, spenderai almeno dieci per gli aggiornamenti di rete per mantenere anche una parvenza di produttività - e anche allora, probabilmente sarebbero più produttivi se risparmiassi fornendo li con Pentium III che hai trovato in un cassonetto da qualche parte.

Penso anche che ci sia un sostanziale vantaggio nel fatto che i tuoi sviluppatori utilizzino un ambiente almeno ragionevolmente vicino a quello atteso dall'utente finale di destinazione. Indipendentemente dagli obiettivi prestazionali ufficiali in una specifica e simili, la maggior parte dei programmatori si basa piuttosto su come "si sente" il codice quando lo testano. Quando utilizzano un ambiente completamente diverso da quello dell'utente finale, è probabile che perdano tempo in banalità pur trascurando completamente i problemi principali.

Per quanto attraente sia un ambiente omogeneo dal punto di vista del supporto e simili, dovresti generalmente incoraggiare quanta più varietà possibile nelle macchine degli sviluppatori. Gli sviluppatori raramente hanno bisogno di molto supporto, e sapere immediatamente quando si dispone di codice che fallirà con un diverso chip grafico, CPU, scheda di rete, ecc., Più che ripaga dell'investimento minimo.

In conclusione: se stai scrivendo un codice che è destinato (almeno principalmente) ad essere utilizzato in un ambiente server virtualizzato, devi semplicemente fornirlo per i tuoi sviluppatori. Se lo fai comunque per i test, può (ma non necessariamente) avere senso anche per lo sviluppo. Allo stesso modo, se hai bisogno (o almeno hai) un server e una rete severamente sovradimensionati, potrebbe avere senso approfittarne usando ciò che hai già a disposizione.

Nella maggior parte dei casi tipici, tuttavia, mi sembra che ciò possa introdurre più problemi di quanti ne risolva.

Questa era una delle mie idee in passato: avere un server ad alte prestazioni che avesse tutto il software richiesto e un sacco di PC desktop a basse prestazioni che sarebbero stati usati solo per connettersi al server tramite Desktop remoto.

I benefici sarebbero:

• Il solido backup. Alcuni sviluppatori potrebbero non voler eseguire regolarmente il backup dei propri computer desktop, quindi una soluzione centrale sarebbe più affidabile,
• La possibilità, per ogni sviluppatore, di lavorare ovunque. Con questo intendo anche lavorare da qualsiasi PC dell'azienda. Diciamo che la mattina lo sviluppatore vuole condizioni di lavoro silenziose. Va nella sua stanza e lavora lì. Quindi vuole fare un po 'di programmazione in coppia o lavorare in un ambiente più sociale. Spegne semplicemente il suo PC desktop, va in un'altra stanza dove ci sono dieci computer e si connette da lì. No "Devo ricaricare nuovamente tutte le mie app".

Bene, ci sono molti seri problemi che mi fanno pensare che non userò mai la cosa in questo modo nei prossimi anni.

• Specificità delle soluzioni remote. Che ne dici di lavorare a distanza usando diversi schermi di computer contemporaneamente? Voglio dire, è facile? È ovvio? Le scorciatoie che uso quotidianamente sono abilitate quando lavoro a distanza? Non sono così sicuro. Cosa succede se premo Ctrl + Maiusc + Esc per visualizzare l'elenco dei programmi attualmente in esecuzione? Oh sì, non funziona, quindi ora devo ricordare di averlo fatto in modo diverso.

• Colpo di prestazione. Non sono sicuro che non ci sarà alcuna riduzione delle prestazioni. E ricorda, un programmatore che usa un computer lento è un programmatore infelice. E la società che rende i propri programmatori scontenti delle condizioni scadenti non produrrà mai software di alta qualità.

• Maggiore impatto di un disastro. Ospiterai la soluzione su un server ridondante? Hai una rete ridondante nella tua azienda? Supponiamo che il router non funzioni e non sia ridondante. Significa che ora tutti gli sviluppatori non sono in grado di lavorare. Affatto. Perché non hanno software installato localmente. Perché non hanno nemmeno il codice sorgente: è sul server. Quindi tutti si fermano e tu paghi tutte quelle persone all'ora solo per aspettare che il router venga sostituito.

• Costi hardware. Se si tratta di un unico server, quanto costerà? Se avete, diciamo, venti sviluppatori, 64 GB di RAM sul server sarebbero sufficienti? Non sono così sicuro Sarebbe sufficiente una soluzione quad-core con due CPU? Ancora una volta, ho dei dubbi. Altrimenti, cosa ne pensi? Una sorta di nuvola? O hai una soluzione scalabile che funziona su più server? Sei pronto a pagare il costo di Windows Server (se usi Windows) per macchina?

• Costo dell'elettricità. Se lavori completamente in remoto, significa che spendi quasi la stessa quantità di energia sul lato server come se stessi lavorando localmente, oltre alla quantità di energia sprecata dal computer locale e dalla rete.

• Licenze. Non sono sicuro se devo metterlo come un vantaggio o un problema, ma penso che il costo delle licenze software in questo caso sarà molto più alto.

E ancora, pensa a tutti i costi di gestione, supporto, implementazione, manutenzione. Con una soluzione personalizzata come questa, può facilmente diventare enorme, senza contare che ogni volta che qualcosa fallirà, vedrai tutti gli sviluppatori che si aggirano, aspettando di poter continuare il suo lavoro.

Usiamo istanze di Amazon ec2 on demand come macchine sviluppatore. Questo non ha nulla a che fare con i costi. Abbiamo un "pool di sviluppatori" che lavora su diversi progetti e abbiamo bisogno della capacità di spostarci rapidamente tra i progetti.

In generale, la VM risparmia tempo di installazione iniziale. Ma a lungo termine, si perde tempo a causa della perdita di produttività. Il costo è un non-asse, perché il costo dello sviluppatore è molto più del costo della macchina.

I costi di produttività includono: tempo impiegato per avviare un'immagine di macchina virtuale (diversi minuti), scarsa reattività e vincoli di risorse / memoria. Inizialmente non sono molto, ma col tempo diventano fastidiosi.

In uno dei nostri progetti abbiamo riformattato il codice per semplificare l'installazione iniziale per "scaricare il codice ed eseguire maven". Con questa modifica, è stato semplice per un nuovo sviluppatore iniziare a lavorare sul progetto - e ora nessuno usa l'immagine VM di Amazon. Stiamo cercando di emularlo anche su altri progetti, ma ci vorrà del tempo. Fino ad allora, abbiamo le nostre immagini ec2.

Stai molto attento qui. Di recente sono stato distribuito a un cliente in cui tutti gli addetti al reparto IT avevano la propria VM essenzialmente per lo stesso motivo: per consentire loro di avere PC di fascia bassa sulla scrivania e quindi di accedere alla VM in remoto e svolgere il loro normale lavoro.

L'esperienza non è stata carina. Almeno una volta alla settimana correvamo molto lentamente per vari motivi. In generale, potremmo dire quando qualcuno nel team stava eseguendo una serie di pacchetti SSIS ad alta intensità di processore. Alla fine hanno spostato alcuni di noi su server diversi, il che ha aiutato alcuni, ma le prestazioni non sono mai state giuste.

Penso che se hai intenzione di farlo - fai la tua dovuta diligenza nella potenza del server, le tue esigenze di elaborazione, quante macchine stai per servire, ecc. Potrebbe farti risparmiare un po 'di denaro, ma se non implementato correttamente, può causare LOTTI di mal di testa.

Nota: questa NON è una fiamma dell'architettura della VM - solo un avvertimento per le persone che la stanno esaminando - assicurati di avere le tue anatre di fila prima dell'implementazione.

Lo sviluppo su macchine virtuali può funzionare abbastanza bene, ma solo se fatto bene:

• Solo perché l'utilizzo di VM ti consente di avere un singolo computer per l'intero team anziché uno per sviluppatore, non significa che sia una buona idea
• Il riavvio non dovrebbe richiedere l'apertura di un ticket di supporto con un tempo di risposta di 24 ore
• Le VM di sviluppo non dovrebbero trovarsi in un datacenter a 5000 miglia di distanza dagli sviluppatori.
• Sebbene le macchine virtuali possano essere gestite dagli sviluppatori e quindi non supportate, ciò non significa che non dovrebbero essere in grado di accedere ai servizi di rete come il controllo del codice sorgente.
• La connessione desktop remoto dovrebbe essere standard, non un'applet personalizzata di "alta sicurezza" che converte le virgolette digitate in umlaut.
• Ottenere una nuova macchina virtuale o ricostruirne una esistente dovrebbe richiedere minuti, non settimane

Ho visto tutti questi problemi e non mi piace particolarmente lavorare con loro. Tuttavia ho anche una configurazione VM a casa che uso per scelta. Funziona più velocemente di un'installazione locale e consente cose come ambienti separati per progetti diversi e ricostruzioni veloci quando un ambiente diventa instabile.

Lavoro con le macchine virtuali, ma non lo consiglio per il tuo progetto principale.

Il motivo per cui utilizzo le VM per lo sviluppo è perché devo supportare progetti legacy (ad es. VB6, .NET 1.1, ecc ...) e non voglio sporcare la mia macchina principale installando VS2003 / 2005 / vb6 / etc ... Funziona bene, ma ci sono problemi intermittenti qua e là.

Inoltre, l'interazione è più lenta, le macchine virtuali impiegano un po 'ad avviarsi / spegnersi, non hanno effetti UI nativi (come Aero in Win7), ecc ...

Qualunque cosa tu abbia intenzione di risparmiare in termini di denaro, sprecherai e altro per la seccatura che stai per imporre alla tua squadra. Inoltre, come qualcuno qui menzionato, nessun supporto multi-schermo. Ho bisogno di almeno 3 schermi per essere il più produttivo possibile.

La regola di sviluppo numero 1 è quella di rendere felici i tuoi sviluppatori. Lo troverai quasi impossibile da fare con le VM remote. Il supporto multi-monitor è discutibile, i ritardi di rete e i bip sono problematici e i risparmi sui costi sono generalmente minimi.

Lavora su VM, certo, ma consenti anche VM locali e rendi anche il computer fisico una bestia ridicolmente veloce.

Telelavoro al 100% e tra il mio ISP personale e la VPN - nonostante l'elevata affidabilità - hanno abbastanza segnali acustici che mi farebbero impazzire se non potessi lavorare in modalità offline.

In genere, eseguo solo il rollup di una varietà di immagini di VirtualBox e ne lavoro. Copiare qualche centinaio di MB sul cavo non è troppo dispendioso in termini di tempo se ne hai bisogno uno nuovo a livello locale.

Il mio team ha implementato con successo una configurazione di "PC lento / server VM veloce". Per un team di 20 sviluppatori, avevamo un server RAM da 8 processori, 256 GB RAM collegato tramite fibra ottica a una SAN molto veloce. Era costoso, ma più economico che offrire a ciascuno sviluppatore una workstation con prestazioni simili. Per un piccolo team (4 sviluppatori) non sono sicuro che le economie di scala entrino in gioco e in realtà ti fanno risparmiare qualsiasi cosa.

Vale la pena guardare le macchine virtuali per lo sviluppo, ma i costi finanziari sono la ragione sbagliata .

Questo è stato brevemente trattato in Expert .NET Delivery di Marc Holmes usando NAnt e CruiseControl.net - in breve l'argomento per lo sviluppo su una VM è che scoraggia qualsiasi aspetto del lavoro dal diventare dipendente dalla particolare configurazione dello sviluppatore. Nuke la tua VM all'inizio di ogni progetto e, a meno che tu non abbia effettivamente bisogno di uno strumento particolare, non continua a muoversi. Ciò riduce al minimo la probabilità che le modifiche apportate si rompano sulla macchina di chiunque, tranne la tua. Gli sviluppatori potrebbero piangere per il fatto che i loro giocattoli vengano portati via, ma alla fine, fare affidamento sugli strumenti è un punto debole e tutto ciò che non si può fare intuitivamente in un ambiente pulito è un odore.

Nota che non credo necessariamente agli argomenti presentati sopra. Capisco e, in una certa misura, mi allineo a loro, ma li sto facendo per motivi di discussione, per generare discussione.

Potenziali svantaggi

• Se l'host di macchine virtuali si arresta ... siete tutti colpiti. Se hai mai avuto una squadra di 20 persone urlare "GAH! HOST NON RISPONDE !?" all'unisono ... non è divertente.
• Se stai permettendo le istantanee ... quelle consumano rapidamente le risorse. 20 persone * 10-20 istantanee ciascuna occupano molto spazio sull'HDD (o almeno abbastanza per iniziare a causare problemi).
• Se riscontri problemi con l'utilizzo delle risorse sull'host, tutti nuovamente avvertono il dolore.

IME, è una buona soluzione e funziona, ma hai bisogno di hardware decente sull'host e quando accadono cose brutte, accadono a tutti.

Questo fallisce uno dei criteri più importanti del test Joel.

Mi assicuro che tutti i miei sviluppatori abbiano almeno un laptop o desktop i3 o migliore con la quantità di RAM che può contenere.

8 GB è ciò per cui mi impegno.

Li rende più produttivi e possono effettivamente eseguire Virtual Box sui loro computer locali per lo sviluppo e il test, anziché su costosi server di manutenzione. Possono eseguire lo snapshot della loro Virtual Box per installare roba folle e testare diversi browser e installatori e tutto e in pochi secondi tornare a una buona configurazione nota senza la necessità di contattare i servizi "IT".

Gli sviluppatori hanno bisogno dei computer più veloci dell'azienda, con il maggior numero di RAM e permessi di root sui loro computer locali. Fine della storia.

Ho già lavorato su VM per lo sviluppo, sia VM locali (in esecuzione sul PC locale) che remote. Quelli locali erano molto più belli da lavorare rispetto a quelli remoti.

Le VM remote, a cui ci stavamo connettendo tramite RDP, presentavano un piccolo ritardo tra ogni sequenza di tasti e azione. È possibile svilupparsi in tali condizioni per un breve periodo, ma giorno dopo giorno è diventato molto frustrante.

Sono stato felicemente sviluppato con una VM locale su VMWare perché avevo bisogno di eseguire Flash Builder su una macchina Linux, e ne sono rimasto abbastanza soddisfatto fintanto che aveva memoria sufficiente: era abbastanza utilizzabile.

Lo facciamo per le nostre macchine remote e funziona abbastanza bene. Molto raramente lavorano da casa (normalmente solo per una soluzione di emergenza qua e là), quindi utilizziamo solo netbook di fascia bassa, remotati nelle nostre macchine desktop veloci in ufficio. Sono sicuramente ancora più lenti (probabilmente limitati dalla rete più di ogni altra cosa), ma di tanto in tanto lavorano per compiti brevi. Questo non sarebbe davvero accettabile per un cavallo da lavoro a tempo pieno, tuttavia, poiché la VM può spesso causare un po 'di ritardo che anche con l'hardware migliore, IMHO, è un po' distratto.

Nel mio ultimo lavoro, abbiamo fatto esattamente questo:

Abbiamo utilizzato un Windows Terminal Server, in cui ogni sviluppatore aveva un account. Gli sviluppatori avevano ancora PC regolari (perché erano già lì), ma i PC eseguivano solo il client RDP.

Abbiamo sviluppato Java, quindi il software utilizzato dove compilatore Java + IDE (principalmente Eclipse), oltre a browser Web, strumenti di query DB, client di controllo versione e occasionalmente sw per ufficio (nel nostro caso OpenOffice.org).

Non abbiamo riscontrato alcun problema reale e le prestazioni sono state abbastanza decenti.

L'unico vero problema era che devi davvero fare attenzione a non disturbare gli altri in alcune situazioni, perché stai condividendo un sistema. Quando le operazioni IT dovevano eseguire copie di file di grandi dimensioni o eseguire backup sul server, le prestazioni diminuivano per tutti. Quando lo abbiamo identificato e risolto (copiando con priorità bassa o durante la notte), tutto ha funzionato bene.

Quindi l'avvertenza è: valutare le prestazioni il più presto possibile e pianificare l'hardware e il suo utilizzo di conseguenza.

TL; DR: l' ho fatto in diversi lavori e ora lo preferisco.

Il costo è la ragione sbagliata su cui concentrarsi. Eccone alcuni migliori.

Motivi

• Coerenza della piattaforma nei diversi ambienti (sviluppo, test e produzione).
  • Perché: elimina completamente un vettore di difetti, difetti derivanti dalle differenze della piattaforma in ambienti diversi.
• Permette che cambiamenti di sistema come gli aggiornamenti avvengano prima in vms di sviluppo, siano verificati, roll-up per testare, essere verificati e passare alla produzione; tutto molto più semplice con sviluppo (e test) vms.
  • Perché: controllo. Posso eseguire l'istantanea, eseguire il rollback, identificare i delta, apportare le modifiche su un server e propagare un successo semplicemente duplicando la VM, ecc.
• A volte i sistemi su cui si sviluppa sono disponibili solo su una rete protetta. In alternativa, il server su cui verrà eseguito il software potrebbe avere accesso limitato o caratteristiche di rete diverse.
  • Perché: la VM di sviluppo può trovarsi sulla VLAN che ha accesso al sistema o al servizio bloccato. In alternativa, se il server di sviluppo ha lo stesso accesso limitato del server di test e di produzione, non è mai una questione di codifica accidentale di un requisito su una caratteristica di rete o accesso che non sarà disponibile.

Le sfide

La sfida numero uno è lo sviluppo remoto, soprattutto se devi passare attraverso un gateway o saltare un server. Ciò rende difficile, soprattutto se gli sviluppatori non sono ben arrotondati (hanno alcune conoscenze di ingegneria di sistema, conoscenze di rete, ecc.).

Esistono molte varianti dello sviluppo remoto, ma di solito si riducono a 2 differenze principali.

• Esegui i tuoi strumenti di sviluppo in ambiente remoto e utilizza protocolli come client RDP, client X11 remoti, ecc.
• Esegui i tuoi strumenti di sviluppo localmente e usa i protocolli per sincronizzare o eseguire in modo trasparente sul server remoto, spesso usando ssh come livello di trasporto.

Utensili

Esistono strumenti che aiuteranno lo sviluppo remoto e IDE che lo facilitano. Dovrai indagare fino a che punto è in grado di sviluppare in remoto, molti non lo sono senza lo stesso server su cui è stato sviluppato il codice. Tuttavia ci sono altri strumenti.

• Secure Shell: le configurazioni di sviluppo remoto di maggior successo utilizzano ssh in misura maggiore, utilizzando accessi senza password (utilizzando l'autenticazione con chiave), multihops trasparenti (risolve il problema del server di salto) e altre opzioni di configurazione per migliorare i tempi di risposta. Nota: ho sempre avuto problemi con le implementazioni non OpenSSH di SSH.
• Schermo GNU / TMUX: multiplexer terminali. Lo schermo è il nonno di loro e sta ancora andando forte, ma penso che la maggior parte delle persone abbia iniziato a cambiare (o addirittura a iniziare) su TMUX.
• Vim / Emacs : la vecchia guardia, ma entrambi funzionano alla grande per lo sviluppo remoto in diversi modi. È Vim, quindi tutto ciò che serve è una shell, mentre Emacs può essere eseguito localmente e utilizzare TRAMP per lo sviluppo remoto.

Su un approccio leggermente diverso - hai dato ai tuoi manager / contabili un foglio di calcolo che evidenzia il costo dell'uso di queste macchine lente? Fai notare loro che una soluzione VM (a meno che non sia fatta nel modo giusto e che non sia facile) potrebbe semplicemente mettere gli sviluppatori e quindi la società nella stessa barca.

Questo dipenderà dalla quantità di potere amministrativo che hai sull'installazione di VMware, se sei inserito in un pool secondario a bassa priorità, avrai macchine lente a seconda dell'attività di altri subpool.

L'hardware è economico, i programmatori sono costosi.

Perché vorresti che i tuoi programmatori fossero frustrati dando loro macchine a sviluppo lento? Il costo dell'aggiornamento dell'hardware impallidisce rispetto al vantaggio in termini di prestazioni che otterranno.

Chiedi macchine migliori. Per lo meno, chiedi di 4 GB di RAM. L'aggiunta di un altro tablet da 2 GB verrà recuperata in meno di una settimana.

La mancanza di supporto per doppio schermo è sempre stata il killer degli affari. Non riesco proprio a immaginare di fare un significativo lavoro di sviluppo su un singolo schermo.

Ora, fanno rock per testare / schierare / giocherellare, quindi non penso che dovrebbero cadere dallo stack.

Se hai un mainframe con 50 dischi SSD in RAID10 e usi solo 3-4 macchine su quel mainframe, allora potrebbe funzionare.

Altrimenti sono in ritardo, molto in ritardo (anche se in alcuni rari casi lo snapshot può compensarlo).

Ho una buona macchina desktop in ufficio a cui posso collegarmi dal mio laptop tramite VPN usando la condivisione dello schermo.

Funziona per incidenti di assistenza fuori orario e occasionali lavori forzati a distanza. È certamente meglio che mantenere un ambiente completamente configurato su un secondo computer o per sviluppare elementi che richiedono una bassa latenza per il data center attraverso una WAN.

Tuttavia, è frustrante lavorare in questo modo per lunghi periodi. A volte mi sono recato al lavoro per la seconda metà della giornata, una volta che tutto ciò che mi ha tenuto a casa è stato rimosso.

Latenza e proprietà dello schermo sono i due assassini per me.

Non penso che tu voglia andare con una soluzione VM remota. La connessione di rete sarà il collo di bottiglia e anche su una connessione veloce, può essere sufficiente per causare frustrazione. Ci stiamo allontanando da questa tecnica per utilizzare gli ambienti di sviluppo locale.

Sviluppiamo su iMac, il che è davvero bello, ma le nostre applicazioni web sono in esecuzione su un ambiente Linux in produzione. Il problema è che alla fine potremmo incorrere in un problema che si verifica solo su Linux e potrebbe essere difficile da risolvere. È qui che entra in gioco la potenza delle macchine virtuali. Tuttavia, non mi piace nemmeno l'idea di utilizzare una VM il 100% delle volte.

Di recente ho imparato a conoscere Vagrant (http://vagrantup.com/docs/getting-started/why.html) e Chef per rendere il lavoro con VirtualBox super facile. Vagrant ti dà la possibilità di avviare facilmente una VM quando ne hai bisogno e di demolire una VM quando non lo fai. Quindi ho potuto fare tutto il mio sviluppo usando il mio Mac. Quindi quando sono pronto per testare il mio codice, posso avviare una macchina virtuale per testarlo e tenerlo in circolazione solo quando ne ho bisogno. Vagrant ti dà anche la possibilità di condividere facilmente le VM con i tuoi colleghi in modo che tutti tu possa essere sicuro di lavorare nello stesso ambiente.

Consiglierei di dare un'occhiata a Vagrant in modo da essere almeno a conoscenza delle opzioni disponibili quando si tratta di sviluppare e lavorare con le macchine virtuali.

Ho lavorato su un progetto legacy relativo a 5 macchine, ognuna ha un ruolo in una pipeline di calcolo (la macchina 1 invia la richiesta alla macchina 2, che a sua volta invierà la richiesta alla macchina 3 ecc.). La distribuzione delle impostazioni sulla macchina virtuale ci ha fatto risparmiare un tempo ENORME: 1. Il sistema era indefinibile in quanto gli sviluppatori erano pigri / non avevano il tempo di incorporare i test nella progettazione. 2. Sono state implementate troppe configurazioni e avevo bisogno di tempo per organizzarle in gruppi.

Ora lo uso perché lavoro su troppi progetti contemporaneamente. Il problema principale che ho ora sono: 1. Le macchine virtuali richiedono troppo tempo per essere gestite. 2. Le macchine virtuali consumano enormi quantità di memoria per l'esecuzione

Questo genere rende le VM difficili da usare quando si tenta di usarle per avere ordine. Mantieni una macchina principale con la tua e-mail e il tuo testo, sviluppala su macchine virtuali dissociate. Tiene la vita ordinata e pulita a un costo.

Come affermato da altri, dipende davvero dal problema che si sta tentando di risolvere con i desktop VM e quindi valutando i vantaggi della risoluzione di tale problema rispetto agli svantaggi che incorreranno nell'ambiente VM.

Ci stiamo muovendo verso un ambiente ibrido in cui tutti i nostri sviluppatori onshore disporranno di macchine fisiche tradizionali ma gli sviluppatori offshore (che lavorano in questo momento con una piccola società di outsourcing) useranno desktop virtuali. I problemi che stiamo cercando di risolvere con i desktop remoti sono legati alla sicurezza e alle prestazioni. L'ambiente virtuale ci fornirà ovviamente un maggiore controllo dal punto di vista della sicurezza e per prestazioni trasferiremo solo "pixel modificati" anziché il codice sorgente completo e dovremo implementare server proxy e simili.

Non sono ancora sicuro che sia la strada giusta da percorrere, ma è dove siamo diretti.