Czy można wirtualizować maszyny deweloperskie?

Question

Jest to budżetowy czas, a firma zaczyna się podważać kosztem zastąpienia maszyny współpracownika, która za nią odpowiada, jej potrzebuje i na to zasługuje.

Nasza grupa to mały niezależny dostawca oprogramowania/SAAS, który istnieje jako oddział większej grupy medialnej. Nie jesteśmy centrum kosztów, zarabiamy nawet w tym roku. Jesteśmy własnością średniej wielkości grupy medialnej, której model biznesowy jest zupełnie inny i wydaje się napędzany jedynie przez redukcję kosztów.

Nasz stos oprogramowania to Visual Studio 2008, SQL 2008, na Windows Server 2008 (tak, że wiele witryn root może być hostowanych i debugowanych na każdym komputerze dewelopera). Naszym docelowym sprzętem jest czterordzeniowa stacja robocza 3GHz, 4GB RAM i dyski twarde RAID 1, które chronią nas przed utratą produktywności związaną z utratą dysku twardego programisty.

Korporacja chce dać nam kilka potężnych, ale zepsutych serwerów wycofanych z eksploatacji, a następnie każdy programista będzie miał wirtualną stację roboczą na tym serwerze. Komputery znajdujące się na naszych komputerach będą niemymi terminalami po 400-500 USD każdy.

Próbuję być neutralny, ale wątpię, czy trudno jest dostrzec moje uprzedzenia. Chciałbym zobaczyć prawdziwe reakcje programistów na to i sądzę, że to najlepsze miejsce, aby to osiągnąć.

Proszę podać argumenty za lub przeciw, dowody, jeśli widzieliście już wypróbowaną i jak dobrze (lub nie) jej nie ma.

Answer 1

To brzmi jak dobre intencje pomysł, ale:

Z mojego doświadczenia trzeba wiele rdzeni, dużo pamięci i szybkie dyski być produktywny w dzisiejszych nowoczesnych IDE. Nie widzę, że dzieje się to w środowisku wirtualnym z jakąkolwiek gospodarką. Poszczególne pudełka są jeszcze lepsze.

To także kwestia kontroli. W środowisku wirtualnym mogę sobie wyobrazić wszelkiego rodzaju ograniczenia. Czy nadal będziesz w stanie instalować własne narzędzia?

W końcu jest to błąd. Jeśli ten pomysł wydłuży czas budowy o znaczną kwotę, wszelkie oszczędności w sprzęcie zostaną szybko usunięte z powodu utraty wydajności. I odwrotnie, pieniądze, które są wydawane na przyzwoite, indywidualne maszyny dla programistów, szybko zwrócą się same w krótszym czasie.

Dobrej jakości pojedyncze maszyny to inwestycja, a nie koszt.

Answer 2

Oprócz wszystkich Givens (Perfomance, miejsca na dysku, itp ...):

byłbym OK z tym tak długo, jak miałem jeszcze Obsługa wielu monitorów.

Bez tego nie można przejść.

Answer 3

Programowanie jest związane z dyskiem, tzn. Użytkownik poświęca czas na oczekiwanie na kompilacje, które w większości przypadków są związane z dyskiem. Jeśli wszyscy dzielicie się czasem budowy maszyny, stanie się znacznie gorzej.

Answer 4

Zakładam, że masz już maszyny dla SVN/TRAC, serwera Continuous Integration, demonstracje produktów, testy itd. I że jedynym możliwym wykorzystaniem twojego zespołu może być wykonanie tych serwerów dla osobistych maszyn wirtualnych.

Answer 5

Robię wiele rzeczy, które wiążą mój procesor na 100%. Kompilacje z pewnością to osiągną. Teraz wyobraź sobie, że musisz udostępnić ten procesor 10 innym programistom. Utrata produktywności stanie się dość widoczna. Jeśli masz komputer wielordzeniowy, nie będzie to tak bolesne.Zdobądź Intel i7 i prawdopodobnie nawet go nie zauważysz, gdy zaloguje się 8 osób. Większość programów (w tym mój kompilator) nie może mimo wszystko używać więcej niż 1 procesora.

Powiedziawszy, że jest to opłacalne rozwiązanie pozwalające obniżyć koszty. Kiedyś pracowałem w firmie, która od tego czasu przeniosła się do tych niemych terminali. To działa dobrze. Moja uczelnia miała maszyny HP UNIX, które były niemymi terminalami. Zalogowali się do serwera, który podzielił własność procesora, pomimo tego, że zalogowano się na wiele osób. Ludzie logowali się do serwera i sprawdzali liczbę zalogowanych użytkowników. Gdyby było ich za dużo, szukaliby następnego jeden, ponieważ czas budowy jest zauważalnie wolniejszy. Nigdy nie logowałbym się do łatwych do zapamiętania nazw serwerów. =)

To zdecydowanie działa, ale także zmniejsza produktywność ze względu na dłuższy czas budowy, szczególnie gdy wiele osób buduje w tym samym czasie. Ponieważ wydajność jest tak trudna do oszacowania, ciężko jest argumentować na twój temat.

Answer 6

Przyspieszenie grafiki może być również problemem, jeśli musisz zrobić coś z animacją, wideo lub edycją obrazu. Naprawdę nie można przetestować odtwarzania wideo w sesji RDP, ponieważ liczba klatek na sekundę i/lub głębia kolorów nie jest wystarczająco wysoka.

Answer 7

Nasz zespół pracuje na zdalnym serwerze (bez GUI, zwykły vim) przez jakiś czas bez problemów. To prawda, że ​​wymaga dość silnego serwera, a czasami zaczyna powoli działać, jeśli wszyscy zaczną kompilować w tym samym czasie.

Ale jako bonus jesteś bardzo mobilny w kategoriach, w których możesz się rozwijać (wszyscy mamy laptopy), czy to w biurze, domu, słonecznej plaży (ostatnia z nich była prawdopodobnie przesadą).

Bute tak, to może nie wszystko dobrze się sprawdza w aplikacjach graficznych.

Answer 8

awaria Podstawowe aby zrozumieć, co się okno deweloper faktycznie robi dużo czasu:

Kiedy buduje swoją żucie przez procesor i dysk - zwłaszcza dysku. Podczas testowania mówisz o uruchomieniu jednego lub kilku wystąpień programu Visual Studio (gdy już przejdziesz do dwóch rzeczy zaczyna się interesować), serwer bazy danych, witryna/usługi i wszystkie inne rzeczy (przeglądarki o numerze część z kart otwarte, oprogramowanie do notebooków i niebo wie tylko, co jeszcze) wszystkie rozłożone na wielu monitorach (co najmniej dwa). Mnóstwo rdzeni, mnóstwo pamięci!

Mogę z radością przyjąć, że istnieje argument dotyczący wirtualizacji - dobry dev box powinien być w stanie obsługiwać wiele wirtualnych maszyn wirtualnych, aby wyizolować niektóre z powyższych i zapewnić "czyste" środowiska do testowania. Zauważ, że to jest pole dla JEDNEGO programisty obsługującego wiele maszyn wirtualnych wyłącznie dla korzyści tego jednego programisty ...

Answer 9

Niezależnie od wydajności, w mojej firmie przechodzimy na laptopy jako maszyny deweloperskie. Główną zaletą jest to, że programiści mogą przynosić swoje komputery na spotkania, konferencje itp. Umiejętność zasiadania obok kolegi, gdy pomagasz mu w rozwiązaniu problemu, i posiadanie własnego środowiska programistycznego jest bardzo cenne.

Answer 10

Wygląda na to, że twoja grupa nie oferuje rozwiązań, które rozważałeś w dobrze udokumentowanym formacie, w przeciwnym razie korporacja nie wciskałaby ci decyzji w gardło. Jeśli masz udokumentowany proces rozwoju, firma może chcieć przedyskutować zmianę procesu z tobą, ale gdy tylko powiesz: "ta zmiana przerwałaby nasz proces i musielibyśmy ponownie przeprogramować nasz proces rozwoju", zobaczą ból z $$ w przerobieniu procesu i najprawdopodobniej wycofaniu.To powiedziawszy, po udokumentowaniu twojego procesu, powinieneś wewnętrznie być bezwzględny, próbując uczynić go bardziej wydajnym i opłacalnym, i mieć otwarty umysł na temat sugestii firmy.