DevOps в облаке
ИТ-специалисты и разработчики традиционно жили в двух совершенно разных мирах. Пользователям нужны оба. Разработчики (художники, ранее известные как программисты) — это те, кто создает программное обеспечение, которое они используют для выполнения своей работы, а также для его обновления и написания исправлений кода для исправления уязвимостей. ИТ-специалисты (также известные как администраторы, как в этом надоедливом сообщении «свяжитесь с вашим сетевым администратором», когда что-то пойдет не так) — это те, кто отвечает за установку, настройку и обслуживание этого программного обеспечения, а также применение этих исправлений и обновление систем, на которых оно работает.
Разработчики и специалисты по ИТ-операциям долгое время работали параллельно, чтобы обеспечить работу бизнес-компьютеров и сетей по всему миру. Эти двое, как правило, имеют разные наборы навыков и типы личности, поэтому неудивительно, что новая «гибкая» философия руководства, которая подталкивает их к своего рода непростому перекрестному обучению посредством появления новой роли, называемой DevOps, вызвала некоторый дискомфорт у сотрудников. обе стороны. Облако еще больше усложнило дело.
Тест на ловкость
В прежние времена (что в технологической индустрии может означать прошлый год) разработчики часто работали изолированно. Конечно, для создания современной операционной системы или сложного пакета приложений требуется целая деревня программистов, но люди традиционно работали над своими частями за закрытыми дверями, не отвлекаясь, чтобы они могли сосредоточиться на утомительных задачах составления тысяч строк. инструкций, которые в конечном итоге приведут в действие функции и особенности программ. От ИТ-специалиста ожидалось, что он будет «общественным», взаимодействующим с пользователями, поставщиками и менеджерами и в то же время пытающимся найти время для выполнения своих основных рабочих обязанностей.
Agile-движение и роль DevOps все меняют. Сейчас ИТ-специалистов вынуждают изучать некоторые навыки кодирования, хотят они того или нет — во многом благодаря отказу Microsoft от графического пользовательского интерфейса в своей серверной операционной системе. Установка ядра сервера и Windows PowerShell означают, что больше внимания уделяется сценариям, чем использованию инструментов на основе графического интерфейса.
В то же время разработчиков вынуждают к более прямому командному сотрудничеству. Планы открытого офиса объединяют всех в одной большой комнате, где им предлагается обмениваться идеями и устанавливать более тесные связи со своими коллегами. Эта тенденция распространилась в деловом мире в целом и в технологической отрасли в частности, хотя не все являются ее поклонниками.
Эти изменения в должностных инструкциях, роли, функциях и ожиданиях сами по себе достаточно разрушительны для ИТ-специалистов и разработчиков, которые годами или даже десятилетиями работали по-старому. Но чтобы добавить к этому, теперь есть облако.
Дивный новый «облачный» мир
Как будто тенденция Agile/DevOps не привела к достаточным изменениям в рабочей жизни ИТ-специалистов и разработчиков, теперь они также должны привыкнуть к идее переноса как разработки, так и операций в облако. Есть те, кто хочет, чтобы вы поверили, что переход в облако полностью прозрачен, и для многих случайных пользователей это (в основном) правда. Однако для разработчиков и ИТ-специалистов работа в облаке имеет свои отличия. Некоторые из них являются положительными — например, тот факт, что разработчики смогут получить доступ к своим файлам и инструментам разработки с любого компьютера, где бы они ни находились, а ИТ-администраторы смогут контролировать и управлять своими (виртуальными) серверами из любой точки мира. по всему миру, без факторов хлопот, которые иногда связаны с удаленным доступом к корпоративной сети.
Однако есть и недостатки в работе в Интернете. Возможно, самая серьезная из них является одновременно и самой очевидной, и самой упускаемой из виду: если у вас нет подключения к Интернету, вы вообще ничего не сможете сделать. Конечно, существует вероятность выхода из строя самой облачной сети. В марте 2015 года сервисы Microsoft Azure «Инфраструктура как услуга» (IaaS) и «Платформа как услуга» (PaaS) для клиентов в центральной части США были отключены на пару часов, а в прошлом месяце пострадали облачные сервисы Amazon AWS в Австралии. из-за сильных штормов, которые отключили их от сети на шесть или более часов.
К счастью, у поставщиков облачных услуг есть процессы для реагирования на такие события, и обычно они могут вернуть своих клиентов в онлайн в течение нескольких минут или часов, а не дней. Тем не менее, в сегодняшнем быстро меняющемся деловом мире (а «agile» — это все, что нужно делать быстрее, помните), несколько часов потерянной производительности могут иметь большое значение, приводя к срыву сроков и даже к потере бизнеса.
Неспособность выполнять свою работу разочаровывает, но на самом деле это может случиться независимо от того, работаете ли вы в облаке или нет. Сетевые администраторы в корпоративных центрах обработки данных знают, что критически важный сервер может выйти из строя или ваша локальная сеть может подвергнуться атаке типа «отказ в обслуживании» с такими же серьезными (для вас) последствиями, как серьезное отключение облака. Если вы разработчик, внезапный аппаратный сбой, который приводит к сбою вашей личной рабочей станции, может привести к полной остановке вашей работы, так как вам, возможно, придется ждать замены или, по крайней мере, получить новую систему, настроенную в соответствии с вашими рабочими предпочтениями. (правильные установленные программы, настроенные параметры и т. д.).
Ежедневные различия
Это больше практические повседневные различия между работой локально и работой в облаке, которые иногда требуют некоторой адаптации. Для ИТ-администраторов самой большой проблемой, вероятно, будет потеря полного контроля над вашей сетевой средой. Да, да — облачные провайдеры подчеркивают, что вы по-прежнему будете отвечать за свои виртуальные машины, даже если вы понятия не имеете, где в мире они физически расположены. Они уверяют вас, что ваши данные будут в безопасности, и это правда, что у них, скорее всего, гораздо больше денег и опыта, чтобы вложить их в механизмы и процессы безопасности, чем у вашей компании. У них также есть более комплексная система резервного копирования и более сложный план аварийного восстановления.
Тем не менее, трудно пройти мимо того факта, что серверы, на которых находятся все ваши контроллеры домена, почтовые серверы, веб-серверы и системы хранения, где находятся все файлы данных ваших пользователей, расположены где-то «там», в конечном итоге физически под кем-то чужой контроль. Администраторы, как правило, имеют хотя бы немного менталитета «помешанного на контроле» — вы должны это делать, чтобы хорошо выполнять свою работу, — и отказ от этого контроля не кажется естественным или правильным.
Разработчики находятся в несколько иной лодке. Их эволюция фактически началась со смены названия. Когда-то большинство кодеров назывались , но когда название должности превратилось в должностные обязанности расширились. Ожидалось, что программисты будут только писать код. Разработчики должны быть программного обеспечения, даже программного обеспечения или которые принимают решения на высоком уровне относительно того, как должны быть построены программы, и стандартов, которым они будут соответствовать.
Однако, кроме причудливых названий и расширенных обязанностей, кто-то еще должен писать код. Написание кода в лучшем случае — это творческий процесс. Многие талантливые разработчики относятся к своему коду так же, как романисты относятся к своим книгам — это их детище. Работа в облаке, особенно «гибкий» способ, обычно означает более тесное сотрудничество, большее командное взаимодействие и больший «совместный доступ» к вашему творению (что также включает разделение заслуг) на более ранних этапах.
Если оставить в стороне стереотипы, разработчики не могут сидеть в своих маленьких кабинках и работать в блаженном одиночестве, пока их части проекта не будут усовершенствованы, прежде чем представить его остальной команде разработчиков. Теперь, даже если вам посчастливилось иметь свой собственный офис или работать удаленно из дома, вы, скорее всего, будете работать в облаке, где ваши файлы будут мгновенно сохранены и доступны для других.
Стандартные инструменты разработки, такие как Microsoft Visual Studio, превратились в облачные службы (Visual Studio Team Services), которые объединяют сами инструменты среды разработки со службами для совместного использования кода и отслеживания работы. В некотором смысле, чем SharePoint является для тех, кто пишет документы, VSTS является для тех, кто пишет код. Разработка в облаке имеет преимущества с точки зрения затрат, а также (по крайней мере, теоретически) позволяет компаниям быстрее поставлять программное обеспечение.
Точно так же развертывание вашей ИТ-инфраструктуры и управление ею в облаке обеспечивает экономию средств и удобство, но есть несколько BOLO — Be On Lookout (вещи, о которых нужно знать обоим, прежде чем переходить на облако).
Список наблюдения за переходом в облако
Независимо от того, используете ли вы сетевую инфраструктуру или разрабатываете программное обеспечение, вы, вероятно, столкнетесь с некоторыми вещами, которые не работают в облаке точно так же, как в вашей предыдущей, необлачной среде.
Облако — это новая модель вычислений. Безопасность и надежность обычно являются главными задачами ИТ-администраторов, но еще одна проблема, с которой вы можете столкнуться, — обратная совместимость. У вас могут быть старые машины в вашем локальном центре обработки данных, на которых все еще работают устаревшие операционные системы и приложения, которые были специально созданы для вашей организации много лет назад и все еще необходимы. Облачные виртуальные машины могут не поддерживать это устаревшее программное обеспечение.
Разработчики могут обнаружить, что программное обеспечение, протестированное в облаке, не работает так идеально в «реальной жизни», как в более ограниченной облачной среде, из-за всей мешанины различного оборудования, программного обеспечения и конфигураций, которые должны быть в новых приложениях. играй красиво», когда он возвращается на землю.
Решением может быть гибридная среда, в которой у вас есть «лучшее из обоих миров» — подключение вашего локального центра обработки данных к облачной сети. Однако иногда интеграция внутренних приложений с приложениями в облаке может быть сложной.
И ИТ-специалисты, и разработчики могут столкнуться с ограничениями пропускной способности облака. Независимо от того, насколько быстрыми могут быть машины в центре обработки данных облачного провайдера, независимо от того, сколько миллионов они потратили на создание быстрой инфраструктуры, в конечном счете ваши данные передаются через Интернет, и их скорость равна скорости самого медленного канала, т.е. скорее всего, это ваше собственное подключение к Интернету (корпоративная сеть или личная, если вы работаете из дома). Хотя в наши дни есть несколько удивительно быстрых интернет-планов, доступных по разумной цене, они все же медленнее, чем в большинстве локальных сетей, где скорость измеряется в гигабайтах, а не в мегабайтах. И если вам нужно работать с мобильным соединением (4G), пропускная способность может очень быстро стать очень дорогой.
Чтобы завернуть…
Мы часто думаем о стремлении к облаку как о чем-то, что влияет только на ИТ-специалистов, а agile-движение — как о чем-то, что затрагивает только разработчиков программного обеспечения, но с новой тенденцией DevOps, которая направлена на объединение навыков двух в одну должность и название должности., оба этих монументальных изменения коснутся как администраторов, так и программистов. Разработка и работа в облаке — это будущее, нравится нам это или нет. Понимание проблем, которые оно принесет, дает нам возможность спланировать стратегию их преодоления, а понимание преимуществ, которые оно принесет, дает нам возможность использовать их в своих интересах.