Поделиться
Как выбрать облачного провайдера? [Ход мыслей конечного клиента]
Рассуждениями о выборе облачного провайдера с редакцией CNews делятся Илья Садовенко, директор по информационным технологиям, Европейский регион Mary Kay, и Алексей Вещиков, руководитель группы эксплуатации инфраструктуры Mary Kay.
Вместо предисловия
Цифровую трансформацию компания пережила в конце нулевых, когда бизнес полностью ушел в онлайн. Естественно, на ту пору думать об облаках было слишком рано, поэтому за многие годы была построена развесистая, хорошо виртуализованная собственная инфраструктура, в которой проблема пиковой загрузки была решена поддержанием избыточного уровня мощности. Мощность эта, разумеется, большую часть времени простаивала. При этом был накоплен достаточный опыт автоматизации процессов управления инфраструктурой, что со временем позволило гордо говорить о приверженности принципам DevOps. К концу второго десятилетия 21 века стало очевидно, что груз «железа» мешает компании двигаться дальше и были предприняты попытки оценить, насколько современные подходы к организации инфраструктуры могут быть применимы в условиях накопленного архитектурного наследия. Ниже приведены некоторые мысли, посещавшие головы ответственных сотрудников в процессе этой оценки.
Зачем нужно облако?
Ответов на этот вопрос великое множество. В прикладном отношении нужны ответы на следующие вопросы:
1) Зачем нужно облако вашему менеджменту? Нередко ответ можно сформулировать только в духе: «Это отраслевой тренд» или «потому что так сказал CIO». В конечном счете, именно менеджмент будет оценивать успешность проекта и решать, поднять в итоге вам зарплату, повысить или уволить.
2) Особенно если ответ на предыдущий вопрос неконкретен, зачем нужно облако вам как эксплуатации? Люди, работающие с техникой, ценят конкретику и факты. Если их не будет, никто в проект не поверит, а это вернее многих других проблем обречет его на провал.
Очень популярный, но ошибочный ответ — «чтобы сократить TCO». Если считать чисто расходы на эксплуатацию, то этого сокращения не будет. Многие эксперты именно поэтому делают упор на «повышенную скорость развертывания» и прочие трудно формализуемые плюсы, но не объясняют, насколько эта скорость повышается и как это влияет на TCO.
При этом TCO посчитать все равно стоит, особенно если этого раньше никогда не делалось. Как минимум, одно открытие точно произойдет — либо окажется, что малозначительный компонент, на самом деле, съедает немалую долю стоимости владения, либо, наоборот, что-то, казавшееся очень дорогим, на самом деле стоит намного меньше.
Насколько это важный проект?
Важный не в плане слайдов в презентациях или докладов на общих собраниях, а в количестве выделяемых ресурсов. Если миграция в облако есть часть продуманной глобальной стратегии, то там и ресурсов выделят — да и настоящую статью читать большого смысла нет.
Чаще бывает, что миграция в облако по факту становится проектом группы эксплуатации (как ее ни назови — системных администраторов, SRE и т.п.), и отталкиваться приходится от имеющихся, и без того достаточно скудных, рублей и человеко-часов. И в этой ситуации на первый план выходят издержки переключения.
Как ехать?
Иногда проект миграции в облако совмещают с «наведением порядка в инфраструктуре», «инвентаризацией приложений» и прочей деятельностью, которая должна бы превратить управляемый или неуправляемый хаос в серверной в красивую организованную систему, о которой не стыдно рассказать на re:Invent или чем-то подобном. В реальности, увы, все эти инициативы требуют изрядной вовлеченности смежных групп, а они завалены своими задачами, и никакого энтузиазма не проявляют. Как следствие, такие инициативы могут еле двигаться годами, и все заканчивается тем, что проект тянется два-три года, а «воз и ныне там».
Поэтому, если весь проект лежит на широких плечах эксплуатации, то самый примитивный подход воспроизводства в облаке того, что есть в серверной, то, что называется по-английски «lift & shift» или «forklift move» — вот этот подход имеет намного больше шансов на успех.
Но тогда, присматриваясь к провайдерам, надо искать стек технологий, максимально близкий к тому, что есть у вас — в идеале, чтобы виртуальные машины даже не надо было конвертировать. Бонусом к этому будет то, что ваш доморощенный набор утилит, который помогает вам сейчас в эксплуатации, удастся продолжить использовать с минимальной доработкой или вообще без таковой.
Провайдеры и технологии
«В вопросе о том, где граница между SMB (Small & medium business) и Enterprise, сломано немало копий, не в последнюю очередь потому, что всем нам хочется работать в «большом энтерпрайзе». С точки зрения эксплуатации, на самом деле, все определяется «числом серверов на админа». За счет закона Мура, виртуализации и автоматизации это число за последние лет двадцать выросло от нескольких десятков до нескольких сотен (а при хорошей организации — тысяч). Поэтому примем тысячу виртуальных машин за некий верхний порог сегмента SMB».
А.В. Вещиков
Если у вас среднестатистическая инфраструктура, то у вас vSphere с небольшой iSCSI- или FC-СХД с отчетливым преобладанием Windows-машин. Любая экзотика в виде SPARC — это уже совсем отдельный разговор и отдельные сложности.
К счастью, большая часть провайдеров предлагает именно vSphere. По поводу OpenStack и прочих альтернатив — если вы знаете, зачем вам это надо, то вам не нужна настоящая статья, а вот если не знаете — то оставайтесь на vSphere, целее будете.
Изначальный список провайдеров легко получить из обзоров Market.CNews или поискать по хабру. Если вы в Москве или Петербурге, стоит для упрощения выбирать провайдера из своего города, в обоих случаях это сохранит достаточно широкий выбор. В прочем же стоит помнить про две простых вещи:
1) Вы не Gartner, вам не платят за сравнительный обзор полутора-двух десятков провайдеров. Ограничьтесь тремя-пятью.
2) Если только у вас нет экзотики вроде упомянутого выше SPARC, большинство провайдеров вам подойдут. Почти у всех примерно одинаковые сервера (велика ли разница между Dell, HP и Lenovo?), сеть (Cisco, Arista, Juniper) и так далее. И даже vCloud Director один и тот же.
Очевидные вопросы
1) Сколько техплощадок (желательно от двух)?
Техплощадки редко, но падают; лучше иметь возможность если не полноценного DR, то хотя бы относительно быстро поднять все упавшее.
2) От «уважаемого производителя» ли оборудование?
Если мы не говорим о провайдерах масштаба AWS, техподдержка оборудования остается на стороне производителя, и в этом контексте связка Lenovo + Arista выглядит надежнее (и будет чиниться быстрее), чем, скажем, SuperMicro + D-Link.
3) Каковы оргмоменты масштабирования нагрузки в вариантах Reservation Pool и Allocation Pool?
Обычно это занимает от нескольких часов до нескольких дней, и этого достаточно – но могут быть нюансы.
4) Отдают ли в комплекте с GUI также и API?
В подавляющем большинстве случаев, естественно, отдают, но спросить стоит. Скорее всего, некоторая (возможно, подавляющая) часть задач уже как-то автоматизирована, и возвращаться к «накликиванию мышкой» нет никакого смысла.
Неочевидные вопросы
Если вы ведете бизнес в России, вас касается ФЗ-152. Практически всегда у вас будет система, обрабатывающая персональные данные, которую в варианте миграции в облако надо размещать в сегменте, соответствующем требованиям этого закона — и таковой обязан быть у вашего провайдера.
Если у вас есть отдельный отдел ИБ, который нередко бывает «королевством в королевстве», надо подключать его в самом начале и дать ему высказать все возможные требования. Во-первых, не просто так этот отдел существует. Во-вторых, какую-либо сугубо эксплуатационно-техническую проблему вы сможете как-нибудь решить, обойти или подставить костыль, а вот с вето от отдела ИБ вы ничего подобного не сделаете.
Надо быть готовым к долгому и вдумчивому общению с финансистами и юристами. Процесс согласования может легко затянуться на месяцы. В том случае, если миграция в облако (см. выше) не приносит существенного сокращения расходов, а вовсе наоборот, надо будет выдерживать долгую баталию с финансами. В процессе этой баталии стоит помнить, что, с одной стороны, любое сокращения бюджета финансы воспримут благотворно, что приблизит их одобрение, а с другой стороны, вам в этот бюджет вписываться.
Прочие соображения
Особенно в вопросе сроков миграции стоит не забывать о суровой правде жизни в серверной. Если половина вашего оборудования относительно молода, то мигрировать можно постепенно и неторопливо — заодно не придется отвечать на неудобный вопрос, что делать с серверами, в которых есть еще пара лет жизни, а задач для них нет. А вот если, что в условиях суровой экономии на всем в последние годы встречается сплошь и рядом, добрая половина парка техники свои пять или даже семь лет выработала, то при составлении планов миграции следует учитывать, что десятилетняя СХД может в любой момент безвозвратно выйти из строя, а потому нагрузку с нее снять надо бы побыстрее.
Вопрос цены
В конечном счете, из списка в три-пять провайдеров останется два-три, которые будут нравиться всем. И вот на этом этапе, «при прочих равных», как раз и стоит положиться на цену как на основной ориентир. В конце концов, эксплуатация — это безусловно расходная статья бюджета, а сокращение издержек радует всех.
И о людях
Миграция в облако на самом деле угрожает только людям, значительную часть работы которых состояла в обслуживании физического оборудования (если у вас меньше пары десятков стоек, вряд ли есть хоть один такой человек), а также людям, по каким-то причинам «руками» администрировавшим компоненты инфраструктуры, которые в облаке легко настраиваются через API. Но сейчас практически в каждой организации средней руки есть свой набор утилит, покупных или самописных, которые на уровне полуавтоматики или автоматики решают большую часть текущих задач. А в этом случае на локальном оборудовании дергаются одни API, в облаке – другие.
Поэтому, если локальное хозяйство худо-бедно идет в ногу со временем, то массовые увольнения группе или отделу эксплуатации не грозят – но и сэкономить на расходах на персонал тоже существенно не получится. Во многих случаях «экономия» на личном составе будет сопоставима с годовой текучкой кадров – в этом случае сокращение штатов достигается ликвидацией «клеточки» в штатном расписании, на которой стоял уволившийся.
О компании Mary Kay®️
Более 56 лет назад Мэри Кэй Эш разрушила «стеклянный потолок» карьерных ограничений для женщин и создала компанию, исполнив свою мечту: предоставила неограниченные возможности для женщин, создала производство великолепной косметической продукции и сделала мир лучше. Мечта переросла в многомиллиардную корпорацию с миллионами Независимых Консультантов по красоте в почти 40 странах мира. Mary Kay®️ предлагает новейшие разработки в области ухода за кожей, декоративной косметики и парфюмерии. Mary Kay®️ стремится к расширению возможностей для женщин и их семей, сотрудничая с организациями со всего мира, уделяя особое внимание поддержке исследований онкологических заболеваний, защите жертв домашнего насилия и помощи детям.
Короткая ссылка
