Реально ли виртуализировать машины разработчика?
Это бюджетное время, и Корпоративный компенсирует ценой замены машины коллеги, которая ему нужна, нуждается в ней и заслуживает ее.
Наша группа - это небольшой ISV/SAAS, который существует как подразделение более крупной медиа-группы. Мы не центр затрат, мы зарабатываем деньги даже в этом году. Мы являемся владельцем медиагруппы среднего размера, чья бизнес-модель совершенно иная, и, похоже, движет она только за счет сокращения расходов.
Наш программный стек - это Visual Studio 2008, SQL 2008, на Windows Server 2008 (так что несколько корневых веб-сайтов могут быть размещены и отлажены на каждом компьютере разработчика). Наше целевое оборудование - это четырехъядерная рабочая станция 3 ГГц, 4 ГБ ОЗУ и зеркальные жесткие диски RAID 1, поэтому мы защищены от потери производительности при потере жесткого диска разработчика.
Корпорация хочет предоставить нам пару мощных, но изнурительных, списанных серверов, и тогда у каждого разработчика будет виртуальная рабочая станция на этом сервере. Компьютеры, сидящие на наших настольных компьютерах, будут тупыми терминалами по 400-500 долларов каждый.
Я пытаюсь быть нейтральным, но я сомневаюсь, что трудно различить мою предвзятость. Я хотел бы увидеть реакцию реального разработчика на это, и я думаю, что это лучшее место, чтобы получить это.
Пожалуйста, включите аргументы за или против, доказательства того, видели ли вы эту попытку и насколько хорошо (или нет) она прошла.
10 ответов
Это звучит как благие намерения, но:
По моему опыту, вам нужны несколько ядер, много памяти и быстрые диски для продуктивной работы в современных современных IDE. Я не вижу, чтобы это происходило в виртуальной среде с какой-либо экономикой. Индивидуальные ящики еще лучше.
Это также вопрос контроля. В виртуальной среде я могу представить все виды ограничений. Сможете ли вы, например, установить собственные инструменты?
В конечном счете, это ошибочно. Если эта идея значительно увеличит время сборки, любая экономия на оборудовании будет быстро стерта из-за потери производительности. И наоборот, деньги, которые тратятся на достойных отдельных машинах для разработчиков, быстро окупятся снова и снова за сокращенное время сборки.
Хорошее качество отдельных машин - это инвестиция, а не стоимость.
Разработка связана с диском, то есть вы тратите свое время на ожидание сборок, которые большую часть времени являются процессом, связанным с диском. Если вы все делитесь машиной, то время сборки станет намного хуже.
Помимо всех данных (производительность, дисковое пространство и т. Д.):
Я был бы в порядке с этим, пока у меня все еще была поддержка нескольких мониторов.
Без этого это не пойдет.
Основная неспособность понять, что на самом деле делает ящик разработчика:
При сборке его разжевывают через процессор и диск - особенно диск. При тестировании вы говорите о работе одного или нескольких экземпляров Visual Studio (как только вы пройдете две вещи, которые начинают становиться интересными), сервер баз данных, веб-сайт / сервисы и все остальное (браузеры с множеством открытых вкладок, блокнот). программное обеспечение, и только бог знает, что еще) все распространяются на несколько мониторов (по крайней мере, два). Много ядер, много памяти, пожалуйста!
Я вполне могу согласиться с тем, что есть аргумент для виртуализации - хороший блок разработки должен иметь возможность размещать несколько одновременно работающих виртуальных машин, чтобы изолировать некоторые из вышеперечисленных и обеспечить "чистые" среды для тестирования. Обратите внимание, что это один из способов для ОДНОГО разработчика, размещающего несколько виртуальных машин исключительно в интересах этого одного разработчика...
Наша команда разрабатывает на удаленном сервере (без графического интерфейса, просто старый vim) в течение достаточно долгого времени без проблем. Конечно, для этого требуется довольно мощный сервер, а иногда он начинает работать медленно, если все начинают компилировать одновременно.
Но в качестве бонуса вы очень мобильны с точки зрения того, с чего вы можете развиваться (у всех нас есть ноутбуки), будь то офис, дом, солнечный пляж (последний, вероятно, был завышен).
Но, да, конечно, это может не очень хорошо работать для графических приложений.
Похоже, что ваша группа не предлагает решения, которые вы рассматривали в хорошо документированном формате, в противном случае корпоративные решения не будут отталкивать вас в горло. Если у вас есть документированный процесс разработки, корпорация может захотеть обсудить изменение процесса с вами, но как только вы скажете: "это изменение нарушит наш процесс, и нам придется переоснастить наш рабочий процесс разработки", они почувствуют боль $$ в переработке процесса и, скорее всего, отступить. Тем не менее, как только ваш процесс задокументирован, вы должны внутренне быть безжалостными, пытаясь сделать его более эффективным и рентабельным, а также непредвзято относиться к предложениям корпорации.
Я делаю много вещей, которые привязывают мой процессор на 100%. Компиляции, безусловно, достигают этого. Теперь представьте, что вам нужно поделиться этим процессором с 10 другими разработчиками. Потеря производительности станет вполне очевидной. Если у вас многоядерный ПК, это будет не так больно. Получите Intel i7, и вы, вероятно, даже не заметите его, когда в систему войдут 8 человек. Большинство программ (включая мой компилятор) в любом случае не могут использовать более 1 процессора.
Тем не менее, это жизнеспособное решение для снижения затрат. Раньше я работал в компании, которая с тех пор перешла на эти тупые терминалы. Работает нормально. В моем университете были машины HP UNIX, которые были тупыми терминалами. Они вошли на сервер, который разделил владение процессором между тем количеством людей, которые вошли в систему. Люди должны были войти на сервер и проверить число людей, вошедших в систему. Если их было слишком много, они искали бы следующее один, потому что время сборки заметно медленнее. Я никогда не войду в легко запоминающиеся имена серверов. знак равно
Это определенно работает, но также снижает производительность из-за более продолжительного времени сборки, особенно когда несколько человек строят одновременно. Поскольку производительность - это такая трудная вещь, которую можно измерить количественно, может быть трудно оспорить вашу точку зрения.
Я предполагаю, что у вас уже есть машины для SVN / TRAC, ваш сервер непрерывной интеграции, демонстрации продуктов, тестирование и т. Д., И что ваша команда может использовать эти серверы только для личных виртуальных машин.
Независимо от производительности, в моей компании мы переходим на ноутбуки в качестве машин разработчиков. Основное преимущество заключается в том, что разработчики могут приносить свои компьютеры на собрания, конференции и т. Д. Также очень важно иметь возможность сидеть рядом с коллегой, когда вы помогаете ему решить проблему, и иметь собственную среду разработки.
Графическое ускорение также может быть проблемой, если вам нужно что-то делать с анимацией, видео или редактированием изображений. Вы не можете реально протестировать воспроизведение видео в сеансе RDP, поскольку частота кадров и / или глубина цвета недостаточно высоки.