Мысли о разработке с использованием виртуальных машин [закрыто]

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

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

Я надеялся, что у некоторых из вас могли бы быть аналогичные условия на вашем рабочем месте, и вы могли бы учитывать ваше мнение. Благодарю.

Что вы надеетесь сэкономить, как часть бюджета на разработку? Мне кажется, что вы беспокоитесь об эпсилоне. Стоимость машин для разработчиков составляет менее 5% от общей стоимости содержания разработчика. Поэтому единственный важный вопрос - это сэкономит время разработчиков? Это возможно, если им не придется тратить время на установку и обновление программного обеспечения для разработки. Или это может стоить времени, если сеть выходит из строя, или сервер выходит из строя, или, скорее всего, если скорость отклика в сети меньше всего не хватает. Современная разработка зависит от взаимодействия клавиш с IDE или, по крайней мере, от очень интеллектуального редактора. Задержка этого взаимодействия даже на несколько десятков миллисекунд снижает производительность разработчика. Разработчикам также стоит изучить этот новый способ работы.

Это не возражения против виртуальных машин, а потенциальные возражения против удаленной разработки.

Я думаю, что ты глупый и глупый.

Прежде всего, стоимость машины тривиальна по сравнению со стоимостью разработчика. Вы должны работать, чтобы максимизировать производительность, а не минимизировать стоимость машины.

Во-вторых, задержка (не пропускная способность) является ключом ко многим задачам программирования - особенно к редактированию текста. На каждый доллар / фунт / евро, который вы экономите на машинах для своих разработчиков, вы потратите как минимум десять на модернизацию сети, чтобы поддерживать даже видимость производительности - и даже тогда они, вероятно, будут более продуктивными, если вы сэкономите, поставляя их с Pentium III, которые вы нашли где-то в мусорном контейнере.

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

Как бы привлекательна ни звучала однородная среда с точки зрения поддержки и т. Д., Вы, как правило, должны поощрять как можно большее разнообразие машин разработчиков. В любом случае разработчикам редко нужна большая поддержка, и они сразу же узнают, когда у вас будет код, который может дать сбой с другим графическим чипом, процессором, сетевым адаптером и т. Д., Больше, чем окупают минимальные вложения.

Итог: если вы пишете код, предназначенный (по крайней мере, в первую очередь) для использования в виртуализированной серверной среде, вам просто необходимо предоставить его разработчикам. Если вы все равно делаете это для тестирования, это может (но не обязательно) иметь смысл и для разработки. Аналогичным образом, если вам в любом случае нужен (или, по крайней мере, имеется) сильно перегруженный сервер и сеть, возможно, имеет смысл воспользоваться этим, используя то, что у вас уже есть.

Однако в большинстве типичных обстоятельств мне кажется, что это может создать больше проблем, чем решить.

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

Преимущества будут:

• Сплошная резервная копия. Некоторые разработчики могут не захотеть регулярно создавать резервные копии своих настольных компьютеров, поэтому центральное решение будет более надежным,
• Возможность для каждого разработчика работать из любой точки мира. Под этим я также подразумеваю работу с любого ПК в компании. Допустим, утром разработчик хочет безмолвных условий работы. Он идет в свою комнату и работает там. Затем он хочет заняться парным программированием или работать в более социальной среде. Он просто выключает свой настольный ПК, идет в другую комнату, где есть десять компьютеров, и подключается оттуда. Нет "Я должен перезагрузить все свои приложения снова".

Ну, есть несколько серьезных проблем, которые заставляют меня думать, что я никогда не буду использовать подобные вещи в следующие годы.

• Специфика удаленных решений. А как насчет удаленной работы с использованием нескольких компьютерных экранов одновременно? Я имею в виду, это легко? Это очевидно? Используются ли ярлыки, которые я использую ежедневно, при удаленной работе? Я не совсем уверен. Что если я нажму Ctrl + Shift + Esc, чтобы увидеть список программ, запущенных в данный момент? О да, это не работает, так что теперь я должен помнить, что делал это по-другому.

• Хит производительности. Я не уверен, что не будет никакого снижения производительности вообще. И помните, программист, который использует медленный компьютер, - несчастный программист. И компания, которая делает своих программистов недовольными дрянными условиями, никогда не будет выпускать высококачественное программное обеспечение.

• Более высокое воздействие бедствия. Вы разместите решение на резервном сервере? У вас есть резервная сеть в вашей компании? Допустим, маршрутизатор отключается и не является избыточным. Это означает, что все разработчики сейчас не могут работать. Вообще. Потому что у них нет программного обеспечения, установленного локально. Потому что у них даже нет исходного кода: он на сервере. Таким образом, все останавливаются, и вы платите всем этим людям в час только за ожидание замены маршрутизатора.

• Аппаратные расходы. Если это один-единственный сервер, сколько это будет стоить? Если у вас, скажем, двадцать разработчиков, хватит ли 64 ГБ ОЗУ на сервере? Не уверен Будет ли достаточно четырехъядерного решения с двумя процессорами? Опять же, у меня есть некоторые сомнения. В противном случае, что вы думаете о? Какое-то облако? Или у вас есть масштабируемое решение, которое работает на нескольких серверах? Готовы ли вы оплатить стоимость Windows Server (если вы используете Windows) на машину?

• Стоимость электричества. Если вы работаете полностью удаленно, это означает, что вы тратите почти столько же энергии на стороне сервера, как если бы вы работали локально, плюс количество энергии, потраченное на локальную машину и сеть.

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

И снова подумайте обо всех расходах на управление, поддержку, развертывание, обслуживание. С таким решением, как это, оно может легко стать огромным, не считая того, что каждый раз, когда что-то выходит из строя, вы увидите, что каждый разработчик NOP вокруг, ожидая, чтобы иметь возможность продолжить свою работу.

Мы используем экземпляры amazon ec2 по требованию в качестве машин разработчика. Это не имеет никакого отношения к стоимости. У нас есть «пул разработчиков», работающий над несколькими проектами, и нам нужна способность быстро перемещаться между проектами.

Как правило, виртуальная машина экономит время начальной настройки. Но в долгосрочной перспективе это приводит к потере времени из-за потери производительности. Стоимость не является осью, потому что стоимость разработчика намного больше, чем стоимость машины.

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

В одном из наших проектов мы реорганизовали код, чтобы упростить начальную настройку, чтобы «загрузить код и запустить maven». С этим изменением для нового разработчика было просто начать работать над проектом - и теперь никто не использует образ виртуальной машины Amazon. Мы надеемся подражать этому и в других проектах, но это займет время. До этого у нас есть изображения ec2.

Будьте ОЧЕНЬ осторожны здесь. Недавно я был развернут на клиенте, где у всех в ИТ-отделе была виртуальная машина по одной и той же причине - чтобы они могли иметь более дешевые ПК на столе, а затем удаленно подключаться к виртуальной машине и выполнять свою обычную работу.

Опыт там был не очень. По крайней мере, раз в неделю мы бегали очень медленно по разным причинам. Как правило, мы можем сказать, когда кто-то в команде запускал набор процессорных служб SSIS. В конце концов они перевели некоторых из нас на разные серверы, что помогло некоторым, но производительность никогда не была правильной.

Я думаю, что если вы собираетесь это сделать - тщательно проанализируйте мощность сервера, свои потребности в обработке, количество машин, которые вы собираетесь обслуживать и т. Д. Это может сэкономить вам немного денег, но, если не будет правильно реализовано, может привести к LOTS головных болей.

Обратите внимание: это НЕ пламя архитектуры ВМ - просто предупреждение для людей, которые изучают ее - убедитесь, что у вас есть утки подряд перед внедрением.

Разработка на виртуальных машинах может работать довольно хорошо, но только если все сделано правильно:

• То, что использование виртуальных машин позволяет вам иметь один компьютер для всей команды, а не один на разработчика, не означает, что это хорошая идея
• Перезагрузка не должна требовать открытия заявки в службу поддержки с 24-часовым временем отклика
• Виртуальные виртуальные машины разработки не должны находиться в центре обработки данных за 5000 миль от разработчиков.
• Хотя виртуальные машины могут управляться разработчиками и, следовательно, не поддерживаться, это не означает, что они не должны иметь доступа к сетевым службам, таким как контроль источников.
• Подключение к удаленному рабочему столу должно быть стандартным, а не каким-либо настраиваемым апплетом «высокой степени безопасности», который преобразует любые кавычки, введенные в умляуты.
• Получение новой виртуальной машины или перестройка существующей занимает минуты, а не недели

Я видел все эти проблемы, и мне не особенно нравится работать с ними. Однако у меня дома также есть настройка виртуальной машины, которую я использую по своему выбору. Это выполняется быстрее, чем при локальной установке, и позволяет использовать такие вещи, как отдельные среды для разных проектов и быстрое восстановление, когда среда становится нестабильной.

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

Причина, по которой я использую виртуальные машины для разработки, заключается в том, что я должен поддерживать устаревшие проекты (например, VB6, .NET 1.1 и т. Д.), И я не хочу портить свою основную машину, устанавливая VS2003 / 2005 / vb6 / и т. Д. ... Все работает хорошо, но есть проблемы там и там.

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

Все, что вы собираетесь сэкономить с точки зрения денег, вы будете тратить впустую и больше на хлопоты, которые вы собираетесь навязать своей команде. Плюс, как кто-то здесь упомянул, нет поддержки нескольких экранов. Мне нужно как минимум 3 экрана, чтобы быть максимально продуктивным.

Правило № 1 в разработке заключается в том, чтобы ваши разработчики были довольны. Вы обнаружите, что это почти невозможно сделать с удаленными виртуальными машинами. Поддержка нескольких мониторов нечеткая, задержки в сети и проблемы с хлопотами, а экономия, как правило, минимальна.

Конечно, работайте на виртуальных машинах, но допускайте использование локальных виртуальных машин и превращайте физический компьютер в смехотворно быстрого зверя.

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

Я обычно просто раскручиваю различные образы VirtualBox и работаю с ними. Копирование нескольких сотен мегабайт по сети не требует слишком много времени, если вам нужен новый локально.

Моя команда успешно внедрила конфигурацию «медленный ПК / Fast VM server». Для команды из 20 разработчиков у нас был 8-процессорный сервер 256 ГБ ОЗУ, подключенный через оптоволокно к очень быстрой сети SAN. Это было дорого, но дешевле, чем давать каждому разработчику рабочую станцию ​​с аналогичной производительностью. Для небольшой команды (4 разработчика) я не уверен, что экономия от масштаба даст толчок и действительно спасет вас.

Стоит обратить внимание на виртуальные машины для разработки, но финансовые затраты - неправильная причина.

Это было кратко рассмотрено в Экспертной .NET Delivery Марка Холмса с использованием NAnt & CruiseControl.net - короче говоря, аргумент для разработки на ВМ заключается в том, что он препятствует тому, чтобы любой аспект работы становился зависимым от конкретной конфигурации разработчика. Вы запускаете свою виртуальную машину в начале каждого проекта, и если вам не нужен какой-то конкретный инструмент, он не работает. Это сводит к минимуму вероятность того, что сделанные вами изменения будут ломаться на чьей-либо машине, кроме вашей. Разработчики могут плакать из-за того, что их игрушки забирают, но, в конечном счете, опора на инструменты - это слабость, а все, что вы не можете сделать интуитивно в чистой среде, - это запах.

Обратите внимание, что я не обязательно верю аргументам, представленным выше. Я понимаю и в определенной степени согласен с ними, но я делаю их ради аргументов, чтобы вызвать дискуссию.

Потенциальные недостатки

• Если хост VM выходит из строя ... вы все спрятались. Если у вас когда-либо была команда из 20 человек, вы кричите "ГАХ! НЕ ОТВЕЧАЕТ !?" в унисон ... это не весело.
• Если вы разрешаете снимки ... они быстро съедают ресурсы. 20 человек * 10-20 снимков каждый создает много места на жестком диске (или, по крайней мере, достаточно, чтобы начать вызывать проблемы).
• Если у вас возникнут проблемы с использованием ресурсов на хосте, опять же, каждый испытывает боль.

IME, это хорошее решение, и оно работает, но вам нужно какое-то достойное оборудование на хосте, и когда случаются плохие вещи, они случаются со всеми.

Это не соответствует одному из самых важных критериев теста Джоэла.

Я удостоверяюсь, что все мои разработчики имеют по крайней мере ноутбук или настольный компьютер i3 или лучше с таким количеством оперативной памяти, которое он может вместить.

8GB - это то, к чему я стремлюсь.

Это делает их более продуктивными, и они могут фактически запускать Virtual Box на своих локальных машинах для разработки и тестирования, а не на дорогих в обслуживании серверах. Они могут делать снимки своих виртуальных коробок, устанавливать сумасшедшие вещи и тестировать различные браузеры и установщики и все остальное, и в считанные секунды вернуться к хорошо зарекомендовавшей себя конфигурации без необходимости обращаться в ИТ-службы.

Разработчикам нужны самые быстрые машины в компании с наибольшим количеством оперативной памяти и правами root на своих локальных машинах. Конец истории.

Ранее я работал над виртуальными машинами для разработки, как локальных (работающих на локальном ПК), так и удаленных. С местными было гораздо приятнее работать, чем с удаленными.

Удаленные виртуальные машины, к которым мы подключались через RDP, имели небольшую задержку между каждым нажатием клавиши и действием. В таких условиях можно развиваться в течение короткого времени, но изо дня в день это очень расстраивает.

Я с радостью разработал локальную виртуальную машину на VMWare, потому что мне нужно было запускать Flash Builder на компьютере с Linux, и я был вполне доволен этим, поскольку у него было достаточно памяти - он был вполне пригоден для использования.

Мы делаем это для наших удаленных машин, и это работает довольно хорошо. Чаще всего работают из дома (обычно только для экстренного исправления здесь и там), поэтому мы просто используем нетбуки с довольно низкой производительностью, удаленно подключенные к нашим быстрым настольным компьютерам в офисе. Они определенно все еще медленнее (вероятно, ограничены сетью больше всего), но время от времени работают на короткие задачи. Однако это было бы неприемлемо для рабочей лошади, работающей полный рабочий день, поскольку виртуальная машина часто может вызывать некоторую задержку, что даже с лучшим аппаратным обеспечением, IMHO, немного отвлекает.

На моей последней работе мы сделали именно это:

Мы использовали Windows Terminal Server, где у каждого разработчика была учетная запись. У разработчиков все еще были обычные ПК (потому что они уже были там), но ПК работали только с RDP-клиентом.

Мы занимались разработкой Java, поэтому программное обеспечение использовалось там, где компилятор Java + IDE (в основном Eclipse), а также веб-браузер, инструменты запросов к БД, клиент управления версиями и иногда Office SW (в нашем случае OpenOffice.org).

Мы не столкнулись с какими-либо реальными проблемами, и производительность была вполне приличной.

Единственная реальная проблема заключалась в том, что вам действительно нужно позаботиться о том, чтобы не мешать другим в некоторых ситуациях, потому что вы используете одну систему. Когда ИТ-операциям нужно было делать большие копии файлов или выполнять резервное копирование на сервере, производительность для всех снижалась. Когда мы определили и решили это (копирование с низким приоритетом или всю ночь), все работало хорошо.

Итак, предостережение: оцените производительность как можно скорее и соответствующим образом спланируйте свое оборудование и его использование.

TL; DR: я сделал это на нескольких работах, и теперь я предпочитаю это.

Стоимость это неправильная причина, чтобы сосредоточиться на. Вот несколько лучших.

Причины

• Согласованность платформы в различных средах (разработка, тестирование и производство).
  • Почему: Это полностью устраняет вектор дефектов, дефекты от различий платформ в различных средах.
• Позволяет системным изменениям, таким как обновления, происходить первыми в vms разработки, проверяться, проверяться, проверяться и запускаться в производство; все намного проще с разработкой (и тестированием) vms.
  • Почему: Контроль. Я могу делать снимки, выполнять откат, идентифицировать дельты, вносить изменения на одном сервере и распространять информацию об успехе, просто дублируя виртуальную машину и т. Д.
• Иногда системы, против которых вы разрабатываете, доступны только в защищенной сети. Кроме того, сервер, на котором будет работать ваше программное обеспечение, может иметь только ограниченный доступ или другие характеристики сети.
  • Почему: ВМ разработки может находиться в VLAN, которая имеет доступ к заблокированной системе или услуге. В качестве альтернативы, если у сервера dev такой же ограниченный доступ, что и у тестового и рабочего сервера, никогда не возникает вопрос о случайном кодировании требования к характеристикам сети или доступа, который будет недоступен.

проблемы

Задача номер один - это удаленная разработка, особенно если вам нужно пройти через шлюз или сервер перехода. Это усложняет задачу, особенно если разработчики не очень хорошо разбираются (у них есть знания в области системной инженерии, сетевых знаний и т. Д.).

Существует много вариантов удаленной разработки, но обычно они сводятся к двум основным различиям.

• Запустите инструменты разработки в удаленной среде и используйте протоколы, такие как клиенты RDP, удаленные клиенты X11 и т. Д.
• Запускайте средства разработки локально и используйте протоколы для прозрачной синхронизации или выполнения на удаленном сервере, часто используя ssh в качестве транспортного уровня.

инструменты

Существуют инструменты, которые помогут с удаленной разработкой, и есть IDE, которые способствуют этому. Вам придется выяснить, в какой степени он способен к удаленной разработке, многие не обходятся без запуска на том же сервере, на котором разрабатывается код. Однако есть и другие инструменты.

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

Несколько иначе - дали ли вы своим менеджерам / бухгалтерам электронную таблицу с указанием стоимости использования этих медленных машин? Укажите им, что решение виртуальной машины (если оно сделано неправильно, и это непросто) может просто поставить разработчиков и, следовательно, компанию в одну лодку.

Это будет зависеть от того, насколько вы обладаете административными полномочиями по сравнению с установкой VMware. Если вы попали в подпул с низким приоритетом, то у вас будут медленные машины в зависимости от активности других подпулов.

Оборудование дешевое, программисты дорогие.

Почему вы хотите, чтобы ваши программисты были разочарованы, предоставляя им медленные машины для разработки? Стоимость обновления оборудования меркнет по сравнению с выигрышем в производительности.

Спросите о лучших машинах. По крайней мере, попросите 4 ГБ оперативной памяти. Добавление еще 2 ГБ планшета будет возвращено менее чем за неделю.

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

Теперь они делают рок для тестирования / развертывания / игры, так что я не думаю, что они тоже должны упасть со стека.

Если у вас есть мэйнфрейм с 50 SSD-дисками в RAID10 и вы используете только 3-4 машины на этом мэйнфрейме, он может работать.

В противном случае они медлительны, действительно отстают (хотя в некоторых редких случаях моментальные снимки могут компенсировать это).

У меня есть приличный настольный компьютер в офисе, к которому я могу подключиться со своего ноутбука через VPN с помощью общего экрана.

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

Тем не менее, это разочаровывает, работать так долго. Иногда я ездил на работу на вторую половину дня, когда все, что держало меня дома, было убрано с дороги.

Латентность и экранная недвижимость - два убийцы для меня.

Я не думаю, что вы хотите использовать решение для удаленной виртуальной машины. Узким местом будет сетевое соединение, и даже при быстром соединении этого может быть достаточно, чтобы вызвать разочарование. Мы переходим от этой техники к использованию локальных сред разработки.

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

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

Я бы порекомендовал проверить Vagrant, чтобы вы, по крайней мере, знали о доступных вариантах, когда речь идет о разработке на виртуальных машинах и работе с ними.

Я работал над устаревшим проектом, касающимся 5 машин, каждая из которых играет определенную роль в конвейере вычислений (машина 1 отправляет запрос машине 2, которая, в свою очередь, отправляет запрос машине 3 и т. Д.). Однако развертывание настроек на виртуальной машине сэкономило нам ОГРОМНОЕ время: 1. Система была не отлаживаемой, поскольку разработчики были ленивы / не успели включить тестирование в проект. 2. Слишком много установок было развернуто, и мне нужно было потратить время на их размещение в группах.

Теперь я использую его, потому что работаю над слишком многими проектами одновременно. Основная проблема, с которой я столкнулся сейчас: 1. ВМ требуют слишком много времени для обслуживания. 2. Виртуальные машины потребляют огромное количество памяти для запуска

Это делает виртуальные машины сложными в использовании, когда вы пытаетесь использовать их для наведения порядка. Держите одну основную машину с вашей электронной почтой и текстом, развивайтесь на виртуальных машинах с предрасположенностью. Сохраняет вашу жизнь аккуратной и чистой по цене.

Как утверждают другие, это действительно зависит от того, какую проблему вы пытаетесь решить с помощью рабочих столов виртуальной машины, а затем взвешивает преимущества решения этой проблемы и недостатки, которые будет иметь среда виртуальной машины.

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

Все еще не уверен, что это правильный путь, но это то, куда мы направляемся.