Ambienti di sviluppo virtualizzati nelle reti aziendali

Stiamo tentando di implementare un ambiente di sviluppo utilizzando la virtualizzazione per un piccolo team di 4 sviluppatori all'interno di un'organizzazione aziendale. Ciò ci consentirebbe di creare ambienti di sviluppo, test e staging separati, oltre a consentire l'accesso a nuovi sistemi operativi che sono requisiti per sistemi o strumenti che stiamo valutando. Abbiamo riproposto una macchina esistente di classe workstation, abbiamo aggiunto 24 GB di RAM e RAID-10 e abbiamo funzionato bene fino a quando non abbiamo tentato di aggiungere la macchina al dominio.

Ora stiamo iniziando la guerra che tutti gli sviluppatori aziendali hanno dovuto combattere dall'inizio del tempo - la lotta per il controllo locale di un ambiente di sviluppo e testing. La rete e gli amministratori IT hanno sollevato preoccupazioni che vanno da "ESX Server è lo standard aziendale" a "server non consentiti su VLAN client" a "[riempire lo spazio vuoto] non è un insieme di competenze attualmente posseduto nel locale o organizzazione IT aziendale ".

Se necessario, potremmo giustificare l'hardware di classe produzione e il supporto IT formale, ma ci vorrebbe tempo e comporterebbe un sacco di mal di testa. Anche allora potrebbero essere necessari mesi per ottenere formalmente le risorse IT assegnate trattando questo come un sistema di produzione - e anche se lo facessimo, probabilmente perderemmo il controllo locale di cui abbiamo bisogno.

Immagino che molti di voi abbiano avuto lotte simili sul controllo da parte degli sviluppatori di ambienti non di produzione - e in particolare la virtualizzazione - quindi le mie domande sono le seguenti:

1. Quali strategie e argomenti ti hanno aiutato a conquistare le persone dell'infrastruttura (IT e di rete) per consentire a questi tipi di silos di esistere all'interno di aziende che hanno in atto politiche di rete e di sicurezza standard che generalmente (e comprensibilmente) precludono questo tipo di non- ( gestione centralizzata)?
2. Hai trovato che questa è una questione di giustificazione tecnica - o più di una lotta politica per il controllo e la proprietà?
3. Se sei finito con un ambiente di sviluppo gestito dall'IT, quanto è stato un blocco per lo sviluppo e il test quotidiani?
4. Qualcuno ha finito per spostare il proprio ambiente di sviluppo in una VLAN disconnessa o in una rete completamente separata per evitare queste difficoltà di accesso alla rete?

Inoltre, questa non è una guerra santa tra Hyper-V e ESX (andremmo bene con entrambi - ma Hyper-V è stato selezionato poiché è "gratuito" con MSDN per questi scopi [sì, VMWare ha anche strumenti gratuiti - ma il buoni strumenti di gestione in genere non lo sono], e sarebbe più facile da gestire dagli sviluppatori locali in un "Microsoft Shop") - quindi gli argomenti a favore o contro non rientrano nell'ambito di questa domanda.

Anche questa è meno una virtualizzazione rispetto all'hardware fisico - suppongo che la stessa domanda possa essere fatta senza il componente di virtualizzazione dell'equazione.

Supponi anche che il team di sviluppo abbia già assicurato la gestione della patch e dell'antivirus o l'integrazione con i sistemi aziendali esistenti se lo supporteranno. Questo scenario, con diverse domande, è anche pubblicato su SF per sperare di ottenere il punto di vista opposto.

Sei andato "fuori dalla prenotazione" e stai cercando di giustificarlo.

Non si tratta di virtualizzazione; Si tratta di controllo e responsabilità. Il dipartimento IT ha la responsabilità della sicurezza e dell'affidabilità dei sistemi dell'azienda. Per assicurarsi che funzionino, l'IT li mantiene sotto il proprio controllo. Hai creato un sistema non sotto il controllo dell'IT e ora sta diventando un problema.

Le solite ragioni per cui i programmatori vogliono i propri sistemi, secondo la mia esperienza, sono:

• L'IT non risponde. Ci vogliono settimane per ottenere un nuovo ambiente, ma ora ne hai bisogno.
• Hai bisogno di controllo; Non te lo daranno. Devi essere in grado di impostare autorizzazioni, installare componenti, ecc. IT non te lo consente.

Alla fine, quando vai in produzione, vorrai un sistema gestito dall'IT completamente bloccato. Ma mentre stai sviluppando, hai bisogno di flessibilità. Alcuni suggerimenti:

• Stringere amicizia. conoscere alcune persone nell'IT; Parla con loro faccia a faccia. Spiega la tua situazione e chiedi loro cosa si può fare. Potresti essere in grado di ottenere i diritti di amministratore di un server dev semplicemente chiedendo.
• Esegui locale. Se è possibile eseguire porzioni dell'applicazione sui computer locali, potrebbe non essere necessario un server oppure è possibile cavarsela con un'istanza DB bloccata.
• Ottieni uno sponsor. Niente fa muovere l'IT come un vicepresidente che entra e dice "Perché stai bloccando il mio progetto?" Usa il peso del tuo sponsor del progetto.
• Alla nuvola! Se il budget del tuo progetto lo coprirà, esegui l'hosting su EC2: ignori l'intero reparto IT. I rischi vengono violati e licenziati per aver lasciato le informazioni dell'azienda al di fuori del firewall.
• Esegui il gioco lungo. Inserire anticipatamente le richieste di server correttamente autorizzati e amministrati. Quando ricevi lamentele sul tuo homebrew, supponi che stai ancora aspettando sui server ufficiali.
• Preallocare. Richiedi server che ritieni possano essere necessari in futuro. Quindi riutilizzali quando hai esigenze reali.

Per quanto io sia un dilettante in situazioni come queste, sembra che sia necessario un argomento appropriato e ben costruito per giustificare ai responsabili dei dipartimenti la necessità di spese extra (e di estensione) delle risorse IT. Probabilmente vuoi un buon oratore in grado di intermediare i problemi e mettere in relazione il potenziale valore della proposta con coloro che finiscono per pagarla.

Il problema è in realtà uno che merita una vera considerazione: un gruppo vuole l'ambiente Dev, ma ciò mette una certa pressione sull'altro gruppo che si sente responsabile, anzi sono responsabili della sicurezza dell'intero sistema, essendo la rete soprattutto qualcosa che l'IT ritrae è giustificabile prezioso circa.

Mi sembra che la capacità di off-site determinate risorse per un progetto prospetticamente redditizio o anche solo un ambiente libero per gli sviluppatori sia stata superata da una razionalizzazione del mercato per la virtualizzazione come misura di riduzione dei costi e controllo delle risorse.

Ora non fraintendetemi, non sono contrario alla virtualizzazione, tutt'altro. Ma mi viene in mente che spesso ci sono rison molto buone e spiegabili per consentire a un gruppo di sviluppo di avere diritto a un regno separato che sarebbe un ambiente più produttivo e potenzialmente più sicuro della semplice virtualizzazione di tutto.

Sicuramente un'azienda può risparmiare denaro utilizzando il cloud per le normali cose di partenza inter-ufficio, è molto utile lì. (è una forma di virtualizzazione, ma diverso, lo so)

Ma supponiamo che uno sviluppatore generi un errore non identificabile che non può essere debug perché c'è una domanda sul fatto che l'applicazione / il programma si sia rotto a causa di un'implementazione della virtualizzazione (cioè che non si verificherebbe in un computer autonomo), quindi diventa controproducente per perdere tempo cercando di rintracciare il bug che non è in realtà nella programmazione, ma nell'implementazione della VM.

Spero di essere chiaro. Non ho la risposta per il tuo caso specifico, ma penso che si tratti di considerazioni che si spera siano utili in termini di problema, e raccomanderei vivamente che tali questioni siano discusse apertamente e pienamente con entrambi i dipartimenti coinvolti, e forse un rappresentante del gestione aziendale che alla fine avrebbe dovuto difendere gli acquisti. Da qui il mio suggerimento di un buon oratore o intermediario!

Presumibilmente se richiede più dipendenti, allora potrebbe essere una cosa positiva (ci sono molti disoccupati là fuori) ma potrebbero esserci abbastanza risorse informatiche nella sezione sviluppatori per aggiungere un ruolo come l'amministratore del server per il proprio gruppo?

So che in realtà è abbastanza importante, quindi non vorrei essere irriverente, ma ci sono momenti in cui penso che il consolidamento e l'aggiunta di ruoli ai lavoratori esistenti ponga un carico eccessivo sul loro tempo personale, che tendono a finire per risentirsi , specialmente quando potrebbero far parte di qualcosa di radicalmente nuovo e di successo nell'ingegneria del software.

Non invidio il tuo problema, tuttavia invidio il posto di lavoro che è completamente impegnato nella realizzazione di nuovi design, nuovi software e nuove idee. Vi auguro sinceramente buona fortuna e spero che i miei contributi siano di qualche aiuto.

Mihaly

Il reparto IT ha effettivamente un punto.

Probabilmente gestiscono migliaia di applicazioni su centinaia di sistemi. L'unico modo in cui possono farlo in modo efficace è avere alcuni stack software standard selezionati in esecuzione su ancora meno configurazioni hardware standard.

Se segui questa strada incontrerai sempre più problemi man mano che ti avvicini alla produzione - nel peggiore dei casi dovrai rifattorizzare l'intera applicazione per essere eseguita in un ambiente di produzione standard giorni prima di andare in diretta.

Meglio lavorare con il gruppo IT e chiedere loro di configurare alcuni ambienti di test standard per te, è quello che devono pagare. - Ironia della sorte, probabilmente configureranno la macchina virtuale per ogni ambiente.

I programmatori dovrebbero programmare, lasciare che i ragazzi dell'infrastruttura IT forniscano l'infrastruttura e i ragazzi della rete configurino le reti - è come funzionano le aziende!

Inoltre, se la tua applicazione è così non standard che l'IT non prenderà in considerazione la creazione di un ambiente di test, non avrai alcuna possibilità di metterlo in produzione. Parla con i tuoi architetti aziendali per scoprire quali ambienti sono standard e prova a usarli. Se davvero non è possibile implementare l'applicazione utilizzando il software / hardware standard, è necessario presentare una richiesta formale per l'architettura aziendale per approvare la propria infrastruttura come caso eccezionale.

Dovrai presentare il tuo caso alla direzione che:

1. Avere l'ambiente virtualizzato soddisfa uno o più dei requisiti specificati dall'azienda (come la flessibilità di supportare piattaforme multiple) e

2. È possibile implementarlo in modo più tempestivo, con costi inferiori rispetto all'IT, e

3. Avere il controllo locale ridurrà i costi e ridurrà i ritardi nel time-to-market, e

4. È possibile soddisfare i problemi di sicurezza e manutenzione dell'IT e

5. La produttività del programmatore non sarà influenzata.

L'ultimo è un grande if.   Ho discusso di questo problema con un numero di persone specializzate in questo tipo di virtualizzazione. Mi dicono che, quando lancerai abbastanza hardware per renderlo reattivo come un PC locale, non ci sarà alcun risparmio sui costi dell'hardware.

Pertanto, i risparmi sui costi dimostrati dovranno presentarsi sotto forma di flessibilità nella configurazione e capacità di modificare tali configurazioni in un attimo.