Виртуализированные среды разработки в корпоративных сетях

Мы пытаемся внедрить среду разработки с использованием виртуализации для небольшой группы из 4 разработчиков в корпоративной организации. Это позволило бы нам настроить отдельные среды разработки, тестирования и промежуточной среды, а также предоставить доступ к новым операционным системам, которые являются требованиями к системам или инструментам, которые мы оцениваем. Мы переделали существующую машину класса рабочей станции, добавили 24 ГБ ОЗУ и RAID-10 и работали нормально, пока не попытались добавить машину в домен.

Теперь мы начинаем войну, которую с самого начала должны были вести все корпоративные разработчики - борьба за локальное управление средой разработки и тестирования. Сетевые и ИТ-администраторы выражают обеспокоенность в диапазоне от «ESX Server является стандартом предприятия» до «серверы не разрешены в клиентских виртуальных локальных сетях» до «[заполнить пустое]» - это не набор навыков, которыми в настоящее время обладают в локальной сети. или предприятие ИТ организации ".

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

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

1. Какие стратегии и аргументы помогли вам победить инфраструктурных (IT & Network) людей, чтобы эти типы хранилищ существовали на предприятиях, которые имеют стандартные сетевые политики и политики безопасности, которые обычно (и по понятным причинам) исключают этот тип ( централизованно) -управляемая инфраструктура?
2. Считаете ли вы, что это вопрос технического обоснования или, скорее, политической борьбы за контроль и собственность?
3. Если у вас появилась среда разработки, управляемая ИТ, насколько серьезным препятствием для повседневной разработки и тестирования?
4. Кто-нибудь закончил тем, что перенес свою среду разработки в отключенную VLAN или в совершенно отдельную сеть, чтобы избежать этой проблемы с доступом к сети?

Кроме того, это не священная война Hyper-V против ESX (нам было бы неплохо и то, и другое - но Hyper-V был выбран, поскольку он «бесплатный» с MSDN для этих целей [да, у VMWare тоже есть бесплатные инструменты - но хороших инструментов управления, как правило, нет], и ими будет легче управлять местными разработчиками в «магазине Microsoft»), поэтому аргументы за или против любого из них выходят за рамки этого вопроса.

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

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

Вы вышли из резервации и пытаетесь это оправдать.

Это не о виртуализации; Речь идет о контроле и ответственности. ИТ-отдел несет ответственность за безопасность и надежность систем компании. Чтобы убедиться, что они работают, IT держит их под своим контролем. Вы создали систему, не контролируемую ИТ, и теперь это становится проблемой.

По моему опыту, обычные причины, по которым программисты хотят иметь свои собственные системы:

• ЭТО не отзывчиво. Требуются недели, чтобы получить новую среду, но она вам нужна сейчас.
• Вам нужен контроль; Вам это не дадут. Вы должны иметь возможность устанавливать разрешения, устанавливать компоненты и т. Д. ЭТО не позволит вам.

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

• Заводить друзей. познакомиться с некоторыми людьми в сфере ИТ; Поговорите с ними лицом к лицу. Объясните свою ситуацию и спросите их, что можно сделать. Вы можете получить права администратора для сервера разработки, просто спросив.
• Запустите Local. Если вы можете запускать части приложения на своих локальных машинах, вам может не понадобиться сервер, или вы можете избежать использования заблокированного экземпляра БД.
• Получить спонсора. Ничто не заставляет его двигаться, как вступает вице-президент и говорит: «Почему вы блокируете мой проект?» Используйте влияние вашего спонсора проекта.
• К облаку! Если ваш бюджет проекта покроет его, просто разместите на EC2 - вы обойдете весь ИТ-отдел. Риски могут быть взломаны и уволены за то, что они пропустили информацию компании за брандмауэр.
• Запустите длинную игру. Своевременно отправляйте запросы на правильно авторизованные и администрируемые серверы. Когда вы получаете жалобы о своем домашнем пиве, говорите, что вы все еще ждете на официальных серверах.
• Предварительно выделить. Запросите серверы, которые, по вашему мнению, могут вам понадобиться в будущем. Затем измените их назначение, когда у вас есть реальные потребности.

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

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

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

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

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

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

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

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

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

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

Михали

У ИТ-отдела на самом деле есть смысл.

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

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

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

Программисты должны программировать, пусть ребята из ИТ-инфраструктуры предоставляют инфраструктуру, а ребята из сети настраивают сети - это то, как работают корпорации!

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

Вам придется довести дело до руководства, что:

1. Наличие виртуальной среды удовлетворяет одному или нескольким из специально заявленных требований компании (таких как гибкость поддержки нескольких платформ), и

2. Вы можете реализовать его более своевременно, с меньшими затратами, чем ИТ, и

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

4. Вы можете решить проблемы безопасности и обслуживания ИТ, а также

5. На производительность программиста это не повлияет.

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

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