Ambienti di sviluppo virtualizzati in reti aziendali

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

Non si tratta di virtualizzazione; Si tratta di controllo e responsabilità. Il reparto IT è responsabile della sicurezza e dell'affidabilità dei sistemi dell'azienda. Per assicurarsi che funzionino, IT li tiene sotto il proprio controllo. Hai costruito un sistema non sotto il controllo dell'IT e sta diventando un problema.

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

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

In definitiva, quando si va in produzione, si vorrà un sistema gestito dall'IT completamente bloccato. Ma mentre stai sviluppando, hai bisogno di flessibilità. Alcuni suggerimenti:

• Fai amicizia. conosci 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 su un server di sviluppo semplicemente chiedendo.
• Esegui locale. Se puoi eseguire porzioni dell'applicazione sui tuoi computer locali, potresti non aver bisogno di un server, oppure puoi scappare con un'istanza DB bloccata.
• Ottieni uno sponsor. Niente può influenzare l'IT come un VP in arrivo e dire "Perché stai bloccando il mio progetto?" Usa il peso dello sponsor del tuo progetto.
• Verso il cloud! se il budget del tuo progetto lo copra, ospitalo solo su EC2: elimini l'intero reparto IT. I rischi vengono violati e vengono licenziati per consentire alle informazioni aziendali di uscire dal firewall.
• Esegui il gioco lungo. Inserisci le richieste di server correttamente autorizzati e amministrati in anticipo. Quando ricevi lamentele riguardo al tuo homebrew, dì che stai ancora aspettando sui server ufficiali.
• Prealloca. Richiedi server che ritieni possano essere necessari in futuro. Quindi ri-sceglierli quando hai esigenze effettive.

Per quanto io sia un dilettante in tali situazioni, 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 che sia in grado di mediare i problemi e collegare il valore potenziale della proposta a chi finisce per pagarlo.

Il problema è in realtà uno che merita una considerazione reale: un gruppo desidera l'ambiente Dev, ma ciò mette una certa pressione sull'altro gruppo che si sente responsabile, infatti è responsabile della sicurezza dell'intero sistema, in particolare il networking essendo qualcosa che IT gli incarichi sono giustamente preziosi.

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

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

Sicuramente un business può risparmiare denaro utilizzando il cloud per la roba da partitiere tra gli uffici, è molto utile lì. (è una forma di virtualizzazione, ma diversa, lo so)

Supponiamo tuttavia che uno sviluppatore sollevi un errore non identificabile che non può essere sottoposto a debug perché esiste una domanda sull'eventualità che l'applicazione / il programma si sia interrotto a causa dell'implementazione della virtualizzazione (ovvero che non si verificherebbe in un computer autonomo ) quindi diventa controproducente sprecare tempo cercando di rintracciare il bug che non è in realtà nella programmazione, ma nell'implementazione VM.

Spero di essere stato chiaro. Non ho la risposta per il caso specifico, ma ritengo che si tratti di considerazioni utili per quanto riguarda il problema, e raccomando vivamente che tali questioni siano discusse apertamente e pienamente con entrambi i dipartimenti coinvolti, e forse un rappresentante del gestione aziendale che alla fine dovrebbe fare il caso per l'acquisto. Da qui il mio suggerimento di un buon oratore o intermediario!

Presumibilmente se richiede più dipendenti, potrebbe essere una cosa positiva (ci sono un sacco di disoccupati là fuori) ma potrebbero esserci abbastanza intelligenze IT nella sezione sviluppatore per aggiungere un ruolo come amministratore del server per il proprio gruppo stesso ?

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

Non invidio il tuo problema, tuttavia invidio il posto di lavoro completamente impegnato a realizzare nuovi progetti, 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 per farlo in modo efficace è avere alcuni stack software standard selezionati che girano su un numero ancora inferiore di configurazioni hardware standard.

Se segui questo percorso incontrerai sempre più problemi man mano che ti avvicini alla produzione - nel peggiore dei casi dovrai ridirigere 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 chiedergli di configurare per te alcuni ambienti di test standardizzati, è quello che sono pagati per fare. - Ironicamente, probabilmente installeranno una macchina virtuale per ogni ambiente.

I programmatori dovrebbero programmare, lasciare che i ragazzi dell'infrastruttura IT forniscano l'infrastruttura e i membri della rete configurino le reti - il modo in cui funzionano le aziende!

Inoltre, se la tua applicazione è così non standard che l'IT non considererà la creazione di un ambiente di test, avrai zero possibilità di ottenerlo in produzione. Parlate con voi architetti aziendali per scoprire quali ambienti sono standard e provare a utilizzarli. Se davvero non è possibile implementare la propria applicazione utilizzando il software / hardware standard, è necessario presentare una richiesta formale per l'architettura aziendale per approvare l'infrastruttura come caso eccezionale.

Dovrai fare il tuo caso con la gestione che:

1. Avere l'ambiente virtualizzato soddisfa uno o più requisiti specificati dalla società (come la flessibilità di supportare più piattaforme), e

2. Puoi implementarlo in modo più tempestivo, con un costo inferiore a quello consentito dall'IT e

3. Avere controllo locale ridurrà i costi e ridurrà i ritardi del time-to-market e

4. Puoi 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 questo problema con un numero di persone specializzate in questo tipo di virtualizzazione. Mi dicono che, nel momento in cui lanci abbastanza hardware per renderlo reattivo come un PC locale, non ci saranno risparmi sui costi dell'hardware.

Quindi i vostri risparmi dimostrati dovranno arrivare sotto forma di flessibilità nella configurazione e la possibilità di modificare tali configurazioni in qualsiasi momento.