Уважаемые читатели, доброго дня!
В данной статье Игорь Котенко, главный архитектор компании «Неофлекс», делится опытом развертывания платформы контейнеризации на инфраструктуре предприятия.
Причины, по которым компании обычно выбирают on-premise решение, зачастую не технологические, и часто связаны с финансированием. Кто-то пытается снижать операционные расходы (оплата внешних облаков) в пользу капитализации компании (покупка своих серверов), кто-то уже обладает солидными аппаратными ресурсами и хочет их использовать в микросервисной архитектуре.
Прежде, чем переходить к деталям внедрения, обратимся к терминам.
Термин «облака» считается очень перегруженным. Принято различать разные типы облачных решений:
При этом, ничего не мешает слоям базироваться друг на друге. Очевидно, что под платформой или софтом обязательно будет инфраструктура.
Существует некоторая путаница в термине «приватные облака». Иногда так называют облака, развернутые у себя — on-premise, иногда – развернутые на арендуемой инфраструктуре с полной изоляцией вашего сегмента сети. Встречалось даже упоминание о виртуальных машинах с шифрованием памяти и дисков, при этом, дамп памяти не даст провайдеру доступа к вашей информации. В этой статье мы будем обсуждать решения, разворачиваемые у себя — on-premise.
При внедрении приватных облаков ожидается, что они такие же, как публичные, только дешевле, безопаснее и надежнее. Потому многие считают, что приватные облака априори лучше. Зачастую, специалисты просто разворачивают выбранную версию Kubernetes или Openshift и считают, что на этом их работа завершена.
Что рассчитывают получить компании при внедрении on — premise облаков:
Как этого достигают в публичных облаках?
Как правило, за счет автоматизации процессов, эффекта масштаба (оптом дешевле) и совместного использования ресурсов между разными потребителями.
Рассмотрим эти обещания в разрезе частных облаков.
1. Низкая стоимость ресурсов по сравнению с обычной инфраструктурой.
На деле – это не так. На тех же машинах развернули тот же софт, но в контейнерах. Согласно нашему опыту, наоборот, тратится больше ресурсов.
2. Возможность крайне быстро увеличивать и уменьшать ресурсы.
Нет. Для расширения нужно либо держать горячий резерв железа и лицензий софта в простое, либо сначала выкинуть что-нибудь ненужное. Вывести ресурсы из использования можно, но тогда они будут простаивать.
3. Отказоустойчивость.
Да, но присутствует много нюансов. Допустим, вышел из строя сервер. Где же взять еще один? Как быстро развернуть и добавить его в кластер? Если вы не Amazon, то у вас нет бесконечных запасов ресурсов.
4. Низкая стоимость поддержки.
У нас добавился, как минимум, еще один слой (платформа контейнеризации), несколько новых систем. Нужны специалисты с новыми компетенциями. За счет чего возникнет экономия?
Разберем эти вопросы детальнее. Важно помнить, что частные облака должны сосуществовать с имеющимися легаси-системами. Организации вынуждены параллельно поддерживать инфраструктуру существующих систем, организуя гибридную IT-среду.
Естественно, в 99% система не строится с нуля. Как правило, еще до внедрения PAAS решения, существует комплекс процессов и автоматизаций для поддержки старой инфраструктуры. DevOps процессы, планирование и владение ресурсами, мониторинг, обновления софта, безопасность – все эти вопросы приходится согласовывать и изменять в процессе внедрения частного облака.
Обычно, до внедрения собственной PAAS, подход к построению DevOps основывается на использовании систем автоматизации конфигурирования, таких как Ansible или Chef. Они позволяют автоматизировать почти все рутинные процессы IT, часто используя готовые библиотеки скриптов. Однако, платформы контейнеризации продвигают альтернативный подход – “immutable infrastructure”. Его суть – не изменять существующую систему, а взять готовый виртуальный образ системы с новыми настройками и подменить старый образ новым. Новый подход не отрицает старый, но вытесняет автоматизацию конфигурирования в слой инфраструктуры. Безусловно, легаси-системы требуют сохранения старого подхода.
Стандартом де-факто в IT является использование виртуальной инфраструктуры. Как показывает практика, самый распространенный вариант – использование vSphere. Тому есть множество причин, однако существуют и последствия. В нашей практике частые проблемы с оversubscription по ресурсам (попытка сшить семь шапок из одной шкурки) усугублялись практически полным отсутствием контроля и влияния на этот процесс со стороны тех, кто отвечает за производительность решения. Разграничение зон ответственности в подразделениях компании, формализация процедур запросов ресурсов и разные цели руководства подразделений, приводили к проблемам в продуктовой среде и не консистентным нагрузочным тестированиям. В какой-то момент наш отдел разработки даже создал инструмент измерения производительности виртуального ядра, чтобы быстро диагностировать нехватку аппаратных ресурсов.
Очевидно, что попытка разместить на такой инфраструктуре платформу контейнеризации внесет новые краски в существующий хаос.
Вопрос, нужна ли для платформы контейнеризации on-premise виртуальная инфраструктура или лучше ставить ее bare-metal (на железные серверы), дискутируется давно и достаточно широко. Лоббируемые производителями систем виртуализации статьи утверждают, что потерь производительности практически нет, а преимущества слишком велики. С другой стороны, есть независимые результаты тестирования, которые говорят о потерях от 10% производительности. Не стоит забывать и о стоимости лицензий vSphere. Например, устанавливать бесплатную версию Kubernetes на недорогое железо именно для экономии и платить за vSphere? Спорное решение.
Нужно упомянуть об open source решении виртуализации инфраструктуры, например, Open Stack. В целом, о нем сложилось мнение как о решении, требующем серьезных инвестиций в команду. В сети есть статистика, по которой размер команды поддержки Open Stack составляет от 20 до 60 человек. И это отдельно от поддержки платформы контейнеризации! На рынке таких специалистов немного – что повышает их стоимость. Такие вложения обычно окупаются только на очень больших объемах ресурсов.
Важно учитывать наличие в компании специалистов с уникальными компетенциями. К сожалению, установка bare-metal Kubernetes, несмотря на преимущества в прозрачности и снижение расходов на лицензии, часто затруднена, например, отсутствием нормальных инструментов автоматизации установки. Надеемся, что будущее именно за этим подходом.
Еще одним аспектом, влияющим на выбор между виртуальной и bare-metal установкой, является организация железных серверов.
Обычно организация закупает сервера, следуя определенным целям. Можно арендовать сервера в ЦОД (из того, что они предлагают), можно стандартизовать и унифицировать номенклатуру (упрощая резервирование компонент), можно экономить на железе (много недорогих серверов), можно экономить место в стойках. Разные подходы в разных организациях. В целом — это либо мощные серверы с большим количеством ядер и памяти, либо сравнительно небольшие по объему, либо сборная солянка. Но, не стоит забывать о потребностях легаси-систем. В этот момент мы опять сталкиваемся с противоречием в концепциях. Идеология Kubernetes – много недорогого железа и готовность к его отказам. Упал сервер – не беда, ваши сервисы переехали на другой. Данные шардированы (дублированы), не привязаны к контейнеру. Легаси идеология – резервирование на уровне железа. RAID-массивы, дисковые стойки, несколько блоков питания на сервере, «горячая» замена. Упор на максимальную надежность. Ставить на такую инфраструктуру Kubernetes может быть неоправданно дорого.
Если в компании есть высокопроизводительные серверы с множеством ядер на борту, может возникнуть необходимость разделять их между разными потребителями. Тут без системы виртуализации будет не обойтись. При этом, нужно учесть возможность выхода сервера из строя или его остановку на обслуживание. Арифметика проста: если у вас два сервера, при выходе из строя одного, нужен 50% резерв мощности на каждом; если — 4 сервера, при выходе из строя одного, нужен 25% резерв. На первый взгляд все просто – необходимо бесконечное количество серверов, тогда выход из строя одного из них не скажется на общей мощности и ничего резервировать не нужно. Увы, размер ресурсов одного хоста нельзя сильно снижать. Как минимум, на нем должны умещаться все связанные компоненты, которые в терминологии Kubernetes называются “pod”. И, конечно, при дроблении на мелкие серверы, растут накладные расходы на сервисы самой платформы.
В практических целях, желательно унифицировать параметры хостов под платформу. В приближенных к жизни примерах, присутствует 2 ЦОД (поддержка сценария DR означает, как минимум, 50% резервирование ресурсов по мощности). Далее определяются потребности организации в ресурсах платформы контейнеризации и возможность размещения ее на типовых bare-metal, либо виртуальных хостах. Рекомендации Kubernetes – не более 110 pod-ов на одну ноду.
Таким образом, для определения размера ноды, нужно учесть следующее:
Такого рода особенности приходится учитывать в каждом аспекте архитектуры.
Централизованное логирование – как выбрать из нескольких вариантов?
Мониторинг — возможно ваша существующая система мониторинга не подойдет, держать две или мигрировать на новую?
Обновления платформы на новую версию – регулярно или только по крайней необходимости?
Отказоустойчивая балансировка между двумя ЦОД – как?
Архитектура безопасности, взаимодействие с легаси-системами – есть отличия от публичных облаков. Можно рекомендовать строить системы так, чтобы была возможность миграции в публичные облака, но это усложнит решение.
Вопросы планирования, распределения и владения ресурсами для публичных и приватных облаков отличаются мало. Основное отличие – ограниченный объем ресурсов. Если в публичных облаках можно в любой момент взять дополнительно необходимые ресурсы, например, под нагрузочное тестирование, то on-premise приходится тщательно планировать очередность их использования. Это означает, что у вас могут появится ночные запуски и, соответственно, увеличится работа сотрудников из 2-ой и 3-ей линии в неурочное время. Ничего нового для тех, кто работает на своих ресурсах, но горький вкус разочарования для ожидающих чудес от внедрения частных облаков.
Планируя внедрение платформы контейнеризации on-premise, в первую очередь, необходимы специалисты с уникальными компетенциями. На текущем рынке труда их явно недостаточно. Более того, не обладая опытом такого внедрения, тяжело даже составить список всех необходимых специалистов.
Например, для работы платформы необходимо выбрать и установить систему хранения данных. Какую бы систему вы не выбрали (CEPH или Portworx), она будет критична для платформы. Всем известно, что для поддержки базы данных требуется администратор. Так и для системы хранения данных нужен отдельный специалист. К сожалению, об этом никто не задумывается до внедрения системы! Отметим, что разница между администраторами для разных продуктов существенна – сравнима с разницей между Oracle DBA и MS SQL DBA. Потребуется, минимум, два человека на каждую роль: сотрудники ходят в отпуск, болеют и даже, боже упаси, увольняются. И так на каждую компетенцию, а список необходимых для поддержки решения компетенций внушителен.
Хочется сразу предостеречь от попыток скрестить все компетенции в некоторых универсальных солдатах. Их стоимость, редкость и риски потери превышают все разумные пределы.
Еще раз подчеркнём, что поддержка облаков — это сложный процесс. Облачные компании не даром едят свой хлеб: там, за облачным туманом скрыто множество технологий и вложенного труда.
Безусловно, использование консультационных услуг может серьезно ускорить внедрение платформы. Опытные партнеры помогут вам избежать многих ошибок, наладят процессы и обучат вашу команду. Однако, если вы размещаете на платформе критичные для вашего бизнеса сервисы, не менее важно обеспечить качественную поддержку и развитие. Более того, на текущий момент все существующие на рынке системы активно развиваются, появляются новые технологии, новые версии платформы могут требовать миграции сложных процессов и серьезного тестирования перед обновлением. Необходимо наличие сильной команды поддержки, способной обеспечить надежное функционирование системы. И такая команда потребуется вам на постоянной основе.
Когда же стоит рассматривать внедрение платформы контейнеризации on-premise?
В первую очередь, необходимо оценить соотношение между вложениями и отдачей, объемом затрат на железо и сотрудников. Должны быть или веские причины невозможности жить в публичных облаках, либо действительно серьезные потребности в ресурсах. То есть, если для организации достаточно порядка 100 Core и вы не готовы расширить команду поддержки на десятки человек – скорее всего, вам стоит сосредоточится на публичных облаках, либо на простых конфигурациях с серверами приложений. Существует минимальный размер команды, необходимый для поддержки платформы, и затраты на нее могут не окупаться. Однако, при масштабировании ресурсов и грамотной автоматизации всех процессов выгода частного решения может оказаться весьма значительной. Практически той же командой можно поддерживать многие сотни узлов.
Еще одним критерием выбора является вариативность потребностей в вычислительных ресурсах. Если в компании бизнес-процессы создают более-менее равномерную загрузку ресурсов – выгодней развивать собственную инфраструктуру. Если же необходимо использовать большие мощности, но редко – рассматривайте публичные, либо гибридные облака.
В любом случае, при выборе решений on-premise, настраивайтесь на серьезную и планомерную работу, готовьтесь к инвестициям в команду. Переходите от простого к сложному. Будьте внимательны к срокам внедрения, и особенно осторожны при обновлениях на новые версии платформы. Пользуйтесь опытом, полученным на чужих ошибках, а не на своих.
Спасибо за чтение данной статьи, надеемся, что информация окажется полезной.
В данной статье Игорь Котенко, главный архитектор компании «Неофлекс», делится опытом развертывания платформы контейнеризации на инфраструктуре предприятия.
Причины, по которым компании обычно выбирают on-premise решение, зачастую не технологические, и часто связаны с финансированием. Кто-то пытается снижать операционные расходы (оплата внешних облаков) в пользу капитализации компании (покупка своих серверов), кто-то уже обладает солидными аппаратными ресурсами и хочет их использовать в микросервисной архитектуре.
Прежде, чем переходить к деталям внедрения, обратимся к терминам.
Термин «облака» считается очень перегруженным. Принято различать разные типы облачных решений:
- Инфраструктура, как сервис (IAAS) – железо (как правило, виртуальное);
- Софт, как сервис (SAAS), например, DBAS – база данных как сервис;
- Платформа, как сервис (PAAS);
- Приложение, как сервис (AAAS).
При этом, ничего не мешает слоям базироваться друг на друге. Очевидно, что под платформой или софтом обязательно будет инфраструктура.
Существует некоторая путаница в термине «приватные облака». Иногда так называют облака, развернутые у себя — on-premise, иногда – развернутые на арендуемой инфраструктуре с полной изоляцией вашего сегмента сети. Встречалось даже упоминание о виртуальных машинах с шифрованием памяти и дисков, при этом, дамп памяти не даст провайдеру доступа к вашей информации. В этой статье мы будем обсуждать решения, разворачиваемые у себя — on-premise.
При внедрении приватных облаков ожидается, что они такие же, как публичные, только дешевле, безопаснее и надежнее. Потому многие считают, что приватные облака априори лучше. Зачастую, специалисты просто разворачивают выбранную версию Kubernetes или Openshift и считают, что на этом их работа завершена.
Что рассчитывают получить компании при внедрении on — premise облаков:
- Низкую стоимость ресурсов. Потому что платишь только за то, что используешь.
- Возможность максимально быстро добавлять и отдавать обратно ресурсы.
- Отказоустойчивость. Сервер упал, вместо него автоматически дали другой.
- Низкую стоимость поддержки.
Как этого достигают в публичных облаках?
Как правило, за счет автоматизации процессов, эффекта масштаба (оптом дешевле) и совместного использования ресурсов между разными потребителями.
Рассмотрим эти обещания в разрезе частных облаков.
1. Низкая стоимость ресурсов по сравнению с обычной инфраструктурой.
На деле – это не так. На тех же машинах развернули тот же софт, но в контейнерах. Согласно нашему опыту, наоборот, тратится больше ресурсов.
2. Возможность крайне быстро увеличивать и уменьшать ресурсы.
Нет. Для расширения нужно либо держать горячий резерв железа и лицензий софта в простое, либо сначала выкинуть что-нибудь ненужное. Вывести ресурсы из использования можно, но тогда они будут простаивать.
3. Отказоустойчивость.
Да, но присутствует много нюансов. Допустим, вышел из строя сервер. Где же взять еще один? Как быстро развернуть и добавить его в кластер? Если вы не Amazon, то у вас нет бесконечных запасов ресурсов.
4. Низкая стоимость поддержки.
У нас добавился, как минимум, еще один слой (платформа контейнеризации), несколько новых систем. Нужны специалисты с новыми компетенциями. За счет чего возникнет экономия?
Разберем эти вопросы детальнее. Важно помнить, что частные облака должны сосуществовать с имеющимися легаси-системами. Организации вынуждены параллельно поддерживать инфраструктуру существующих систем, организуя гибридную IT-среду.
Естественно, в 99% система не строится с нуля. Как правило, еще до внедрения PAAS решения, существует комплекс процессов и автоматизаций для поддержки старой инфраструктуры. DevOps процессы, планирование и владение ресурсами, мониторинг, обновления софта, безопасность – все эти вопросы приходится согласовывать и изменять в процессе внедрения частного облака.
Как меняются DevOps процессы
Обычно, до внедрения собственной PAAS, подход к построению DevOps основывается на использовании систем автоматизации конфигурирования, таких как Ansible или Chef. Они позволяют автоматизировать почти все рутинные процессы IT, часто используя готовые библиотеки скриптов. Однако, платформы контейнеризации продвигают альтернативный подход – “immutable infrastructure”. Его суть – не изменять существующую систему, а взять готовый виртуальный образ системы с новыми настройками и подменить старый образ новым. Новый подход не отрицает старый, но вытесняет автоматизацию конфигурирования в слой инфраструктуры. Безусловно, легаси-системы требуют сохранения старого подхода.
Поговорим об инфраструктурном слое
Стандартом де-факто в IT является использование виртуальной инфраструктуры. Как показывает практика, самый распространенный вариант – использование vSphere. Тому есть множество причин, однако существуют и последствия. В нашей практике частые проблемы с оversubscription по ресурсам (попытка сшить семь шапок из одной шкурки) усугублялись практически полным отсутствием контроля и влияния на этот процесс со стороны тех, кто отвечает за производительность решения. Разграничение зон ответственности в подразделениях компании, формализация процедур запросов ресурсов и разные цели руководства подразделений, приводили к проблемам в продуктовой среде и не консистентным нагрузочным тестированиям. В какой-то момент наш отдел разработки даже создал инструмент измерения производительности виртуального ядра, чтобы быстро диагностировать нехватку аппаратных ресурсов.
Очевидно, что попытка разместить на такой инфраструктуре платформу контейнеризации внесет новые краски в существующий хаос.
Вопрос, нужна ли для платформы контейнеризации on-premise виртуальная инфраструктура или лучше ставить ее bare-metal (на железные серверы), дискутируется давно и достаточно широко. Лоббируемые производителями систем виртуализации статьи утверждают, что потерь производительности практически нет, а преимущества слишком велики. С другой стороны, есть независимые результаты тестирования, которые говорят о потерях от 10% производительности. Не стоит забывать и о стоимости лицензий vSphere. Например, устанавливать бесплатную версию Kubernetes на недорогое железо именно для экономии и платить за vSphere? Спорное решение.
Нужно упомянуть об open source решении виртуализации инфраструктуры, например, Open Stack. В целом, о нем сложилось мнение как о решении, требующем серьезных инвестиций в команду. В сети есть статистика, по которой размер команды поддержки Open Stack составляет от 20 до 60 человек. И это отдельно от поддержки платформы контейнеризации! На рынке таких специалистов немного – что повышает их стоимость. Такие вложения обычно окупаются только на очень больших объемах ресурсов.
Важно учитывать наличие в компании специалистов с уникальными компетенциями. К сожалению, установка bare-metal Kubernetes, несмотря на преимущества в прозрачности и снижение расходов на лицензии, часто затруднена, например, отсутствием нормальных инструментов автоматизации установки. Надеемся, что будущее именно за этим подходом.
Еще одним аспектом, влияющим на выбор между виртуальной и bare-metal установкой, является организация железных серверов.
Обычно организация закупает сервера, следуя определенным целям. Можно арендовать сервера в ЦОД (из того, что они предлагают), можно стандартизовать и унифицировать номенклатуру (упрощая резервирование компонент), можно экономить на железе (много недорогих серверов), можно экономить место в стойках. Разные подходы в разных организациях. В целом — это либо мощные серверы с большим количеством ядер и памяти, либо сравнительно небольшие по объему, либо сборная солянка. Но, не стоит забывать о потребностях легаси-систем. В этот момент мы опять сталкиваемся с противоречием в концепциях. Идеология Kubernetes – много недорогого железа и готовность к его отказам. Упал сервер – не беда, ваши сервисы переехали на другой. Данные шардированы (дублированы), не привязаны к контейнеру. Легаси идеология – резервирование на уровне железа. RAID-массивы, дисковые стойки, несколько блоков питания на сервере, «горячая» замена. Упор на максимальную надежность. Ставить на такую инфраструктуру Kubernetes может быть неоправданно дорого.
Мы делили апельсин, много наших полегло…
Если в компании есть высокопроизводительные серверы с множеством ядер на борту, может возникнуть необходимость разделять их между разными потребителями. Тут без системы виртуализации будет не обойтись. При этом, нужно учесть возможность выхода сервера из строя или его остановку на обслуживание. Арифметика проста: если у вас два сервера, при выходе из строя одного, нужен 50% резерв мощности на каждом; если — 4 сервера, при выходе из строя одного, нужен 25% резерв. На первый взгляд все просто – необходимо бесконечное количество серверов, тогда выход из строя одного из них не скажется на общей мощности и ничего резервировать не нужно. Увы, размер ресурсов одного хоста нельзя сильно снижать. Как минимум, на нем должны умещаться все связанные компоненты, которые в терминологии Kubernetes называются “pod”. И, конечно, при дроблении на мелкие серверы, растут накладные расходы на сервисы самой платформы.
В практических целях, желательно унифицировать параметры хостов под платформу. В приближенных к жизни примерах, присутствует 2 ЦОД (поддержка сценария DR означает, как минимум, 50% резервирование ресурсов по мощности). Далее определяются потребности организации в ресурсах платформы контейнеризации и возможность размещения ее на типовых bare-metal, либо виртуальных хостах. Рекомендации Kubernetes – не более 110 pod-ов на одну ноду.
Таким образом, для определения размера ноды, нужно учесть следующее:
- Желательно делать ноды равными;
- Ноды должны умещаться на вашем железе (для виртуальных машин – кратно, N виртуальных на одну железку);
- При отказе одной ноды (для варианта с виртуальной инфраструктурой – одной железного сервера) у вас должно хватить ресурсов на оставшихся нодах для переезда pod-ов на них;
- На одной ноде не может быть слишком много (> 110) pod-ов;
- При прочих равных желательно делать ноды крупнее.
Такого рода особенности приходится учитывать в каждом аспекте архитектуры.
Централизованное логирование – как выбрать из нескольких вариантов?
Мониторинг — возможно ваша существующая система мониторинга не подойдет, держать две или мигрировать на новую?
Обновления платформы на новую версию – регулярно или только по крайней необходимости?
Отказоустойчивая балансировка между двумя ЦОД – как?
Архитектура безопасности, взаимодействие с легаси-системами – есть отличия от публичных облаков. Можно рекомендовать строить системы так, чтобы была возможность миграции в публичные облака, но это усложнит решение.
Вопросы планирования, распределения и владения ресурсами для публичных и приватных облаков отличаются мало. Основное отличие – ограниченный объем ресурсов. Если в публичных облаках можно в любой момент взять дополнительно необходимые ресурсы, например, под нагрузочное тестирование, то on-premise приходится тщательно планировать очередность их использования. Это означает, что у вас могут появится ночные запуски и, соответственно, увеличится работа сотрудников из 2-ой и 3-ей линии в неурочное время. Ничего нового для тех, кто работает на своих ресурсах, но горький вкус разочарования для ожидающих чудес от внедрения частных облаков.
«Кадры решают все»
Планируя внедрение платформы контейнеризации on-premise, в первую очередь, необходимы специалисты с уникальными компетенциями. На текущем рынке труда их явно недостаточно. Более того, не обладая опытом такого внедрения, тяжело даже составить список всех необходимых специалистов.
Например, для работы платформы необходимо выбрать и установить систему хранения данных. Какую бы систему вы не выбрали (CEPH или Portworx), она будет критична для платформы. Всем известно, что для поддержки базы данных требуется администратор. Так и для системы хранения данных нужен отдельный специалист. К сожалению, об этом никто не задумывается до внедрения системы! Отметим, что разница между администраторами для разных продуктов существенна – сравнима с разницей между Oracle DBA и MS SQL DBA. Потребуется, минимум, два человека на каждую роль: сотрудники ходят в отпуск, болеют и даже, боже упаси, увольняются. И так на каждую компетенцию, а список необходимых для поддержки решения компетенций внушителен.
Хочется сразу предостеречь от попыток скрестить все компетенции в некоторых универсальных солдатах. Их стоимость, редкость и риски потери превышают все разумные пределы.
Еще раз подчеркнём, что поддержка облаков — это сложный процесс. Облачные компании не даром едят свой хлеб: там, за облачным туманом скрыто множество технологий и вложенного труда.
Безусловно, использование консультационных услуг может серьезно ускорить внедрение платформы. Опытные партнеры помогут вам избежать многих ошибок, наладят процессы и обучат вашу команду. Однако, если вы размещаете на платформе критичные для вашего бизнеса сервисы, не менее важно обеспечить качественную поддержку и развитие. Более того, на текущий момент все существующие на рынке системы активно развиваются, появляются новые технологии, новые версии платформы могут требовать миграции сложных процессов и серьезного тестирования перед обновлением. Необходимо наличие сильной команды поддержки, способной обеспечить надежное функционирование системы. И такая команда потребуется вам на постоянной основе.
Когда же стоит рассматривать внедрение платформы контейнеризации on-premise?
В первую очередь, необходимо оценить соотношение между вложениями и отдачей, объемом затрат на железо и сотрудников. Должны быть или веские причины невозможности жить в публичных облаках, либо действительно серьезные потребности в ресурсах. То есть, если для организации достаточно порядка 100 Core и вы не готовы расширить команду поддержки на десятки человек – скорее всего, вам стоит сосредоточится на публичных облаках, либо на простых конфигурациях с серверами приложений. Существует минимальный размер команды, необходимый для поддержки платформы, и затраты на нее могут не окупаться. Однако, при масштабировании ресурсов и грамотной автоматизации всех процессов выгода частного решения может оказаться весьма значительной. Практически той же командой можно поддерживать многие сотни узлов.
Еще одним критерием выбора является вариативность потребностей в вычислительных ресурсах. Если в компании бизнес-процессы создают более-менее равномерную загрузку ресурсов – выгодней развивать собственную инфраструктуру. Если же необходимо использовать большие мощности, но редко – рассматривайте публичные, либо гибридные облака.
В любом случае, при выборе решений on-premise, настраивайтесь на серьезную и планомерную работу, готовьтесь к инвестициям в команду. Переходите от простого к сложному. Будьте внимательны к срокам внедрения, и особенно осторожны при обновлениях на новые версии платформы. Пользуйтесь опытом, полученным на чужих ошибках, а не на своих.
Спасибо за чтение данной статьи, надеемся, что информация окажется полезной.
build_your_web
То, что в статье называется AaaS обычно принято называть SaaS, а инфраструктурные сервисы (в т.ч. DBaaS) являются частью PaaS.