Думки про розвиток за допомогою віртуальних машин [закрито]

Я буду працювати як керівник розробки для запуску, і я запропонував використовувати VM для розробки. Я не говорю про те, щоб кожен розробник мав робочий стіл з віртуальними машинами для тестування / розробки, я маю на увазі наявність серверної стійки, де всі VM управляються, і розробники можуть працювати з microPC (хтось із ChromeOS?) Локально або навіть віддалено від свого дому комп’ютер.

Для мене переваги полягає в тому, що це надзвичайно масштабовано, з часом дешевше, простіше в управлінні і що ми використовуємо апаратне забезпечення свого максимального потенціалу. Щодо мінусів, я не можу придумати жодних конкретних шоустопперів, окрім як нам потрібен хтось для налаштування / підтримання зазначених налаштувань.

Я сподівався, що хтось із вас, можливо, мав подібне налаштування за місцем роботи та зможе визначити свою думку. Дякую.

Що ви сподіваєтесь заощадити, як частину бюджету розвитку? Мені здається, ти переживаєш за епсилон. Вартість машин для розробників становить менше 5% від загальних витрат на утримання розробника на персоналі. Тому єдине важливе питання - "чи це заощадить розробникам час?" Можливо, якщо їм не доведеться витрачати час на встановлення та оновлення програмного забезпечення для розробки. Або це може затратити час, якщо мережа знизиться, або сервер вийде з ладу, або, швидше за все, якщо швидкість чутливості в мережі є найменшою мірою. Сучасний розвиток залежить від взаємодії натискання клавіші за допомогою клавіші з IDE або, принаймні, дуже розумним редактором. Затримка цієї взаємодії навіть на кілька десятків мілісекунд знищує продуктивність розробника. Існує також вартість розробників для вивчення цього нового способу роботи.

Це не заперечення проти ВМ, а потенційні заперечення проти віддаленого розвитку.

Я думаю, що ти робиш копійки і дурні.

Перш за все, витрати на машину є тривіальними порівняно з вартістю розробника. Ви повинні працювати над досягненням максимальної продуктивності, не зводячи до мінімуму вартість машини.

По-друге, затримка (а не пропускна здатність) є ключем до багатьох завдань програмування - особливо для редагування тексту. За кожен долар / фунт / євро, який ви заощадите на машинах для своїх розробників, ви витратите щонайменше десять на оновлення мережі, щоб зберегти навіть подобу продуктивності - і навіть тоді вони, мабуть, будуть більш продуктивними, якби економили на постачанні їх з Pentium III ви десь знайшли у смітнику.

Я також думаю, що існує велика користь у тому, щоб ваші розробники використовували середовище, принаймні розумно близьке до очікуваного кінцевого споживача. Незалежно від офіційних цілей ефективності в специфікації і подібних, більшість програмістів базуються на тому, як "почувається" код, коли вони тестують його. Коли вони використовують зовсім інше середовище від кінцевого користувача, вони, ймовірно, марнують час на дрібниці, при цьому зовсім не помічаючи основних проблем.

Настільки привабливо, як однорідне середовище звучить з точки зору підтримки та іншого, ви, як правило, повинні заохочувати якомога більше різноманітності в машинах розробників. Розробникам дуже рідко потрібна велика підтримка, і миттєво знаємо, коли у вас є код, який вийде з ладу з іншим графічним чіпом, процесором, мережевим адаптером і т. Д., Більше ніж повертає мінімальні інвестиції.

Підсумок: якщо ви пишете код, який призначений (принаймні в першу чергу) для використання у віртуалізованому серверному середовищі, вам потрібно майже передбачити це для своїх розробників. Якщо ви все одно це робите для тестування, це може (але не обов'язково) мати сенс і для розвитку. Так само, якщо вам все-таки потрібні (або принаймні є) сильно завищений сервер і мережа, можливо, має сенс скористатися цим, використовуючи те, що у вас уже є в наявності.

Однак, за найбільш типових обставин, мені здається, це може спричинити більше проблем, ніж це вирішує.

Це була одна з моїх ідей у ​​минулому: наявність високопродуктивного сервера, який має все необхідне програмне забезпечення, та купу низькопродуктивних настільних ПК, які використовувались би лише для підключення до сервера через віддалений робочий стіл.

Переваги будуть:

• Суцільне резервне копіювання. Деякі розробники можуть не бажати регулярно створювати резервні копії своїх настільних комп'ютерів, тому центральне рішення було б надійнішим,
• Можливість роботи кожного розробника з будь-якого місця. Під цим я також маю на увазі роботу з будь-якого ПК в компанії. Скажімо, вранці забудовник хоче тихих умов роботи. Він іде до своєї кімнати і працює там. Потім він хоче зайнятися деяким парним програмуванням або працювати в більш соціальному середовищі. Він просто вимикає настільний ПК, йде в іншу кімнату, де є десять комп’ютерів, і підключається звідти. Ні "Я повинен перезавантажувати всі свої програми ще раз".

Ну, є кілька серйозних проблем з цим, що змушує мене думати, що я ніколи не буду використовувати подібну річ у наступні роки.

• Специфіка віддалених рішень. А як щодо віддаленої роботи декількох екранів комп'ютера одночасно? Я маю на увазі, чи легко? Це очевидно? Чи вмикаються ярлики, які я використовую щодня, при віддаленій роботі? Я не такий впевнений. Що робити, якщо натиснути Ctrl + Shift + Esc, щоб побачити список програм, які зараз запущені? О так, це не працює, тому тепер я повинен пам'ятати, що робив це по-іншому.

• Виставальний хіт. Я не впевнений, що зниження продуктивності взагалі не буде. І пам’ятайте, програміст, який використовує повільний комп'ютер, - нещасний програміст. І компанія, яка робить своїх програмістів незадоволеними шаленими умовами, ніколи не випускатиме високоякісне програмне забезпечення.

• Більш сильний вплив катастрофи. Чи будете ви розміщувати рішення на надлишковому сервері? Чи є у вас надмірна мережа у вашій компанії? Скажімо, маршрутизатор опускається вниз і не є зайвим. Це означає, що зараз усі розробники не можуть працювати. Зовсім. Тому що у них не встановлено програмне забезпечення локально. Тому що вони навіть не мають вихідного коду: він знаходиться на сервері. Тож усі зупиняються, і ви платите всім цим людям за годину лише зачекати заміна маршрутизатора.

• Витрати на обладнання. Якщо це один і єдиний сервер, скільки це буде коштувати? Якщо у вас, скажімо, двадцять розробників, чи вистачить 64 ГБ оперативної пам’яті на сервері? Не так точно. Чи вистачить чотириядерного рішення з двома процесорами? Знову я маю певні сумніви. Інакше про що ти думаєш? Якась хмара? Або у вас є масштабоване рішення, яке працює на декількох серверах? Чи готові ви заплатити вартість Windows Server (якщо ви використовуєте Windows) за машину?

• Вартість електроенергії. Якщо ви працюєте повністю віддалено, це означає, що ви витрачаєте майже таку ж кількість енергосистемної сторони, як і якщо ви працювали на локальному рівні, а також кількість енергії, яку витрачаєте місцева машина та мережа.

• Ліцензії. Я не впевнений, чи потрібно це сприймати як користь чи проблему, але я відчуваю, що вартість ліцензування програмного забезпечення в цьому випадку буде значно вищою.

І знову подумайте про всі витрати на управління, підтримку, розгортання, обслуговування. Завдяки такому користувальницькому рішенню це може легко стати величезним, не рахуючи, що кожного разу, коли щось вийде з ладу, ви побачите кожного розробника, який НОП навколо, чекаючи, що зможе продовжити свою роботу.

Ми використовуємо екземпляри amazon ec2 на замовлення як машини розробників. Це не має нічого спільного з витратами. У нас є "пул розробників", який працює над декількома проектами, і нам потрібна можливість швидкого переміщення по проектах.

Загалом, VM економить початковий час налаштування. Але більш тривалий термін витрачає час через втрату продуктивності. Вартість - це не вісь, оскільки вартість розробника набагато більше, ніж вартість машини.

Витрати на підвищення продуктивності включають - час, необхідний для створення зображення VM (кілька хвилин), погану реакцію та обмеження ресурсів / пам'яті. Спочатку їх не так багато, але з часом вони дратують.

В одному з наших проектів ми переробили код, щоб спростити початкову настройку, щоб "завантажити код і запустити Maven". З цією зміною новому розробнику було просто почати працювати над проектом - і тепер ніхто не використовує зображення VM Amazon. Ми хочемо наслідувати це і іншим проектам, але це потребує часу. До цього часу у нас є зображення ec2.

Будьте ДУЖЕ обережними тут. Нещодавно мене розмістили до клієнта, де кожен, хто працює в ІТ-відділі, мав свій VM з тієї ж причини - щоб вони мали на ПК стільникові комп'ютери нижнього кінця, а потім віддалені до ВМ та виконували свою звичайну роботу.

Досвід там був не дуже. Принаймні раз на тиждень ми бігали надзвичайно повільно з різних причин. Взагалі, ми могли б сказати, коли хтось із команди працював із набором процесорних інтенсивних пакетів SSIS. Зрештою, вони перенесли декількох із нас на різні сервери, що допомогло деяким, але продуктивність ніколи не була правильною.

Я думаю, якщо ви збираєтеся це зробити - зробіть належну ретельність щодо потужності сервера, ваших потреб в обробці, скільки машин ви збираєтеся обслуговувати і т. Д. Це може заощадити гроші, але якщо не буде впроваджено правильно, це може призвести до багато головних болів.

Зверніть увагу: це НЕ полум’я архітектури VM - лише попередження для людей, які заглядають у нього - переконайтеся, що у вас качки підряд перед реалізацією.

Розвиток на віртуальних машинах може працювати досить непогано, але лише за умови правильного:

• Тільки тому, що використання VM дозволяє вам мати один комп'ютер для всієї команди, а не один на розробника, не означає, що це гарна ідея
• Перезавантаження не повинно вимагати відкриття квитка на підтримку з 24-годинним часом відгуку
• Віртуальні машини для розробки не повинні знаходитися в центрі обробки даних, що знаходиться в 5000 милях від розробників.
• Незважаючи на те, що VM можуть управляти розробниками, і тому вони не підтримуються, це не означає, що вони не повинні мати доступ до мережевих служб, таких як управління джерелами.
• Підключення до віддаленого робочого столу має бути стандартним, а не якимсь спеціальним аплетом "високої безпеки", який перетворює будь-які котирування, набрані в umlauts.
• Отримати новий VM або відновити існуючий потрібно за кілька хвилин, а не тижнів

Я бачив усі ці проблеми, і не особливо сподобався працювати з ними. Однак у мене є домашня установка VM, яку я використовую за вибором. Це працює швидше, ніж локальне встановлення, і дозволяє такі речі, як окремі середовища для різних проектів, і швидке відновлення, коли середовище стає нестабільним.

Я працюю з віртуальними машинами, але не рекомендую це для вашого основного проекту.

Причина, якою я використовую VM для розробки, полягає в тому, що я маю підтримувати застарілі проекти (наприклад, VB6, .NET 1.1 тощо), і я не хочу забруднити свою основну машину, встановивши VS2003 / 2005 / vb6 / тощо ... Це все гаразд, але тут і там виникають переривчасті проблеми.

Крім того, взаємодія проходить повільніше, для запуску / вимкнення віртуальних машин потрібен певний час, не мають власних ефектів інтерфейсу (наприклад, Aero в Win7) тощо.

Що б ви не збиралися економити на грошах, які ви будете витрачати, і більше від клопотів, які ви збираєтесь накладати своїй команді. Плюс, як хтось тут згадував, немає підтримки на багато екранів. Мені потрібно щонайменше 3 екрани, щоб бути максимально продуктивним.

Правило розробки №1 - це підтримувати своїх розробників щасливими. Ви знайдете, що майже неможливо зробити з віддаленими ВМ. Підтримка мультимонітора є плямистою, відставання в мережі та збитки викликають клопоти, а економія витрат, як правило, мінімальна.

Працюйте над візуальними машинами, звичайно, але дозвольте і місцевим VM, і зробіть фізичний комп'ютер також смішно швидким звіром.

Я на 100% комунікую, і між моїм персональним провайдером і VPN - незважаючи на високу надійність - у них є достатня кількість осколків, які б наштовхнули мене, якби я не міг працювати в автономному режимі.

Я, як правило, просто спінірую різноманітні зображення VirtualBox і працюю над ними. Копіювання декількох сотень Мб через провід не надто трудомістке, якщо вам потрібен і новий локально.

Моя команда успішно реалізувала конфігурацію "повільний ПК / швидкий сервер VM". Для команди з 20 розробників у нас був 8 процесор, 256 ГБ оперативної пам'яті, підключений через волокно до дуже швидкого SAN. Це було дорого, але дешевше, ніж давати кожному розробнику робочу станцію з подібною продуктивністю. Що стосується невеликої команди (4 розробники), я не впевнений, що економія на масштабах може наштовхнутися і насправді нічого заощадити.

ВМ для розвитку варто переглянути, але фінансові витрати - це неправильна причина.

Це коротко висвітлювалось у програмі Marc Holmes .NET .NET Доставка з використанням NAnt & CruiseControl.net - коротко кажучи, аргумент для розробки на VM полягає в тому, що це відмовляє будь-якому аспекту роботи від того, щоб стати залежним від конкретної конфігурації розробника. Ви запускаєте свій VM на початку кожного проекту, і якщо вам справді не потрібен певний інструмент, він не продовжує бити. Це мінімізує ймовірність того, що внесені вами зміни будуть порушені на чиїйсь машині, крім вашої. Розробники можуть плакати, коли їхні іграшки забирають, але в кінцевому рахунку, покладатися на інструменти - це слабкість, і все, що ви не можете зробити інтуїтивно в чистому середовищі, - це запах.

Зауважте, що я не обов'язково вірю аргументам, представленим вище. Я розумію і певною мірою їх узгоджую, але я викладаю їх заради аргументів, щоб викликати дискусію.

Потенційні недоліки

• Якщо хост VM знизиться ... ви всі шланги. Якщо у вас коли-небудь була команда з 20 людей, кричите "ГАХ! ХОСТА НЕ ВІДПОВІДАЄТЬСЯ!" в унісон ... це не весело.
• Якщо ви дозволяєте робити знімки ... вони швидко поїдають ресурси. 20 людей * 10-20 знімків кожен робить багато місця на жорсткому диску (або принаймні достатньо, щоб почати створювати проблеми).
• Якщо у вас виникають проблеми з використанням ресурсів у хоста, знову ж таки, всі відчувають біль.

IME, це гарне рішення, і воно працює, але вам потрібно трохи пристойного обладнання для хоста, і коли трапляються погані речі, вони трапляються з усіма.

Це не відповідає одному з найважливіших критеріїв тесту Джоеля.

Я впевнений, що всі мої розробники мають принаймні i3 або кращий ноутбук або робочий стіл з стільки оперативної пам’яті, скільки можливо.

8 Гб - це те, до чого я прагну.

Це робить їх більш продуктивними, і вони можуть фактично запускати Virtual Box на своїх локальних машинах для розробки та тестування, а не на дорогих для обслуговування серверах. Вони можуть зробити знімок своєї віртуальної скриньки, встановити шалені речі та протестувати різні веб-переглядачі та інсталятори, і все, а за лічені секунди повернутися до відомої гарної конфігурації без необхідності звертатися до служб "ІТ"

Розробникам потрібні найшвидші машини в компанії, що мають найбільшу кількість оперативної пам’яті та root-прав на своїх локальних машинах. Кінець історії.

Раніше я працював над VM для розробки, як локальних VM (працює на локальному ПК), так і віддалених. Місцеві з ними були набагато приємніше працювати, ніж віддалені.

Віддалені ВМ, до яких ми підключалися за допомогою RDP, мали невелику відстань між кожним натисканням клавіші та дією. Розвиватися в таких умовах можна за короткий час, але щоденний вихід стає дуже неприємним.

Я щасливо розвивався під місцевим VM на VMWare, тому що мені потрібно було запустити Flash Builder на машині Linux, і був цілком задоволений цим, доки у нього було достатньо пам'яті - це було досить зручно.

Ми робимо це для наших віддалених машин, і це працює досить добре. Найчастіше працюємо вдома (як правило, лише для аварійних виправлень тут і там), тому ми просто використовуємо досить довгі нетбуки, віддалені в наші швидкі настільні машини в офісі. Вони, безумовно, все повільніші (ймовірно, обмежені мережею більше всього), але час від часу працюють над короткими завданнями. Це справді було б не прийнятно для роботи на повній робочій коні, однак, оскільки VM часто може спричинити невеликий відставання, що навіть з найкращим обладнанням IMHO трохи відволікає.

На моїй останній роботі ми зробили зовсім так:

Ми використовували сервер терміналів Windows, де кожен розробник мав обліковий запис. У розробників все ще були звичайні ПК (тому що вони вже були там), але на ПК лише працював клієнт RDP.

Ми займалися розробкою Java, тому програмне забезпечення використовувалося там, де компілятор Java + IDE (в основному Eclipse), а також веб-браузер, інструменти для запитів БД, клієнт управління версіями та інколи office sw (OpenOffice.org у нашому випадку).

Ми не стикалися з жодними реальними проблемами, а продуктивність була цілком пристойною.

Єдиною справжньою проблемою було те, що вам справді потрібно подбати про те, щоб не порушувати інших в деяких ситуаціях, оскільки ви ділитесь однією системою. Коли ІТ-операціям потрібно було зробити великі копії файлів або виконати резервні копії на сервері, продуктивність знизилася для всіх. Коли ми це визначили і вирішили (копіюючи з низьким пріоритетом або протягом ночі), все було добре.

Отже, застереження: Оцініть продуктивність якнайшвидше, і сплануйте обладнання та його використання відповідно.

TL; DR: Я робив це на декількох роботах, і зараз я віддаю перевагу.

Вартість - неправильна причина зосередитися. Ось кілька кращих.

Причини

• Узгодженість платформи в різних середовищах (розробник, випробування та виробництво).
  • Чому: Це повністю виключає дефектний вектор, дефекти від платформних відмінностей у різних середовищах.
• Дозволяє системним змінам, таким як оновлення, спочатку відбуватися в vms-розробці, перевіряти, згортати для тестування, перевіряти і вводити у виробництво; все набагато простіше з розробкою (і тестом) vms.
  • Чому: контроль. Я можу робити знімок, відкидати, визначати дельти, робити зміни на одному сервері та поширювати успіх, просто дублюючи vm тощо.
• Іноді системи, проти яких ви розробляєтесь, доступні лише в захищеній мережі. Крім того, сервер, на якому працюватиме ваше програмне забезпечення, може мати лише обмежений доступ або різні мережеві характеристики.
  • Чому: VM для розробки може бути на VLAN, який має доступ до заблокованої системи чи служби. Крім того, якщо сервер розробників має такий самий обмежений доступ, як і тестовий та виробничий сервер, ніколи не виникає питання про випадкове кодування вимоги в мережевій характеристиці або доступу, який буде недоступним.

Виклики

Завдання номер один - віддалена розробка, особливо якщо вам доведеться пройти через шлюз або стрибнути сервер. Це ускладнює ситуацію, особливо якщо розробники недостатньо округлені (вони мають певні знання про інженерну систему, знання мереж тощо).

Існує багато варіантів віддаленого розвитку, але вони, як правило, зводяться до двох основних відмінностей.

• Запустіть інструменти розробки у віддаленому середовищі та використовуйте такі протоколи, як клієнти RDP, віддалені клієнти X11 тощо.
• Запустіть інструменти розробки локально та використовуйте протоколи для прозорої синхронізації або виконання на віддаленому сервері, часто використовуючи ssh як транспортний шар.

Інструменти

Є інструменти, які допоможуть у віддаленому розвитку, і є IDE, які полегшують це. Вам доведеться дослідити, наскільки він здатний до віддаленого розвитку, багато хто не без роботи на тому ж сервері, на якому розробляється код. Однак є й інші інструменти.

• Безпечна оболонка: Більшість успішних налаштувань віддаленої розробки більшою мірою використовують ssh, використовуючи вхід без паролів (використовуючи автентифікацію ключів), прозорі мультишопи (вирішує проблему сервера стрибків) та інші параметри конфігурації для покращення часу відповіді. Примітка. У мене завжди виникали проблеми з використанням не-OpenSSH реалізацій SSH.
• GNU Screen / TMUX: Термінальні мультиплексори. Екран - це дідусь із них і все ще сильний, але я думаю, що більшість людей почали переходити (або навіть починати) на TMUX.
• Vim / Emacs : Стара гвардія, але обидва чудово працюють для віддаленої розробки різними способами. Це Vim, тому все, що йому потрібно, - це оболонка, тоді як Emacs може працювати локально та використовувати TRAMP для віддаленої розробки.

Що стосується дещо іншого - чи дали ви своїм керівникам / бухгалтерам електронну таблицю, в якій було вказано вартість використання цих повільних машин? Вкажіть на них, що рішення VM (якщо зроблено правильно, і це не просто) може просто поставити розробників і, отже, компанію в одне судно.

Це буде залежати від того, якою мірою вам належить адміністративна потужність над встановленням VMware, якщо ви переведетесь у підпункт із низьким пріоритетом, то у вас будуть повільні машини залежно від активності інших підпунктів.

Апаратне забезпечення дешеве, програмісти - дорогі.

Чому ви хочете, щоб ваші програмісти були розчаровані, надаючи їм машини для повільного розвитку? Витрати на оновлення палітри апаратури порівняно з виграшем від продуктивності.

Попросіть кращі машини. Як мінімум, попросіть 4 ГБ оперативної пам’яті. Додавання ще 2-фунтового планшета заробить менше ніж за тиждень.

Відсутність підтримки подвійного екрану завжди була вбивцею угоди. Я просто не уявляю, як виконувати значну розробку на одному екрані.

Зараз вони рокують для тестування / розгортання / фідінгу, тому я не думаю, що вони також повинні випадати зі стека.

Якщо у вас є мейнфрейм з 50 дисками SSD в RAID10 і ви використовуєте лише 3-4 машини в цьому мейнфреймі, то це може працювати.

Інакше вони мляві, дійсно відсталі (хоча в деяких рідкісних випадках знімок може це компенсувати).

У мене в офісі є гідна настільна машина, до якої я можу підключитися зі свого ноутбука через VPN, використовуючи обмін екраном.

Він працює за інцидентами підтримки години та випадковими примусовими віддаленими роботами. Це, звичайно, краще, ніж підтримувати повністю налаштоване середовище на другій машині або розробляти речі, які потребують низької затримки до центру обробки даних по всій WAN.

Однак працювати це тривалий час неприємно. Мені при нагоді запускали на роботу другу половину дня, коли все, що було, що тримало мене вдома, не виходило з дороги.

Затримка та нерухомість на екрані - це два вбивці для мене.

Я не думаю, що ти хочеш працювати з віддаленим рішенням VM. Мережеве з'єднання буде вузьким місцем, і навіть при швидкому з’єднанні це може бути достатньо, щоб викликати розлади. Ми відходимо від цієї методики до використання місцевих середовищ розвитку.

Ми розробляємо на iMacs, що дуже приємно, але наші веб-додатки працюють у середовищі Linux у виробництві. Проблема з цим полягає в тому, що з часом ми можемо зіткнутися з проблемою, яка трапляється лише в Linux і може бути важкою для усунення несправностей. Ось звідки надходить потужність віртуальних машин. Однак мені навіть не подобається ідея використання VM у 100% часу.

Нещодавно я дізнався про Vagrant (http://vagrantup.com/docs/getting-started/why.html) та шеф-кухаря для того, щоб зробити роботу з VirtualBox дуже просто. Vagrant дає можливість легко запускати VM, коли вам це потрібно, і руйнувати VM, коли цього не потрібно. Тож я міг би зробити всю свою розробку за допомогою свого Mac. Тоді, коли я готовий перевірити свій код, я можу запустити VM, щоб перевірити його, і зберігати його лише до тих пір, поки мені це потрібно. Компанія Vagrant також надає можливість легко ділитися VM з колегами, щоб ви могли бути впевнені, що працюєте в одному середовищі.

Я рекомендую перевірити Vagrant, щоб ви, принаймні, знали про наявні варіанти, коли справа стосується розробки та роботи з VM.

Я працюю над старим проектом, що стосується 5 машин, кожен з яких має роль в обчислювальному трубопроводі (машина 1 надсилає запит на машину 2, що, в свою чергу, надсилатиме запит на машину 3 тощо). Розгортання налаштувань на віртуальній машині заощадило нам ВЕЛИЧЕЗНИЙ час: 1. Система була невідповідною, оскільки диски ліниві / не встигли включити тестування в дизайн. 2. Занадто багато розгорнуто, і мені потрібно було витрачати час на їх упорядкування.

Зараз я цим користуюся, бо працюю надто багато проектів одночасно. Основна проблема, яку я маю зараз, полягає в тому, що: 1. ВМ витрачають занадто багато часу на підтримку. 2. Відеомагнітофони споживають величезну кількість пам'яті для запуску

Цей вид робить відеомагнітофони важкими у використанні, коли ви намагаєтесь використовувати їх для порядку. Зберігайте одну головну машину з електронною поштою та текстом, розробляйте на виділених VM. Підтримує ваше життя акуратним та чистим за ціною.

Як зазначають інші, це дійсно залежить від того, яку проблему ви намагаєтеся вирішити за допомогою VM Desktops, а потім зважуйте переваги вирішення цієї проблеми проти недоліків, які матиме середовище VM.

Ми рухаємось до гібридного середовища, де всі наші розробники на березі моря матимуть традиційні фізичні машини, але офшорні розробники (зараз працюють з невеликою аутсорсинговою компанією) будуть використовувати віртуальні настільні комп’ютери. Проблеми, які ми намагаємося вирішити за допомогою віддалених настільних комп’ютерів, пов’язані із безпекою та продуктивністю. Віртуальне середовище, очевидно, забезпечить нам більший контроль з точки зору безпеки, і для продуктивності ми будемо переносити лише "змінені пікселі", а не повний вихідний код та потребувати реалізації проксі-серверів тощо.

Досі не впевнений, чи це правильний шлях, але ми куди прямуємо.