Именно так. Надо считать, надо проверять, смотреть альтернативы. И снова считать экономику. Именно об этом я говорю - сначала бизнес цели, бизнес показатели, а техническая архитектура строится на основании бизнес требований. И никак не наоборот.
Это не жалоба, а комментарий по поводу использования OpenShift. При традиционном для девопсов деплое "как бог на душу положит" лицензирование OpenShift может превысить стоимость ВСЕГО остального софта на проекте.
Соответственно бездумный подход для коммерческих дистрибутивов не катит.
Ну вы еще мне расскажите про цепочку поставок и спеццены с условиями.
Я говорю только о чисто техническом утаптывании по условиям лицензирования + оптимизацией самого лицензирования через подбор размеров виртуальных воркеров без каких либо дополнительных телодвижений по спецусловиям.
OpenShift - это такая сборка, которая по стоимости может перекрыть весь остальной софт на проекте. Проверено лично. Лично же РедХат ронял в 5 раз по цене за счет лицензирования.
Повлиять на то, как девопсы наго... задеплоили контейнеры не мог, а то уверен, что еще раз в несколько бы смог.
Каких только вариантов я не наслушался. Основной, конечно, что роутер - это домашняя хрень для интернета, а маршрутизатор - это то, что в корпоративе используют.
Основная беда не в том, что из сисадминов. В конце концов DevOps = Dev + Ops. Т.е. специалистов и в разработке, и в эксплуатации. Просто вы разработчик и смотрите на сисадминов традиционно как на чужих людей и даже врагов.
Беда в том, что из плохих и безграмотных сисадминов, которые не смогли вырасти в Ops, и тем более не смогли вырасти из эксплуатации в дизайн и архитектуру (ЗП сравнимы со средними по девопсерии).
В конечном итоге получается, что эти девопсы не умеют НИ в дев НИ в опс.
Пару лет назад хотел взять себе пару админов в офис на очень хорошие деньги (для админов) на немного хелпдеска, немного того, немного этого - и под руководством работы в ЦОДе и рост во всякое. При очень высокой, повторюсь, для админов зп. Так то, что ко мне приходило, иногда с 15-20 лет "опыта" сисадмином, я бы отправил двор мести. Ладно студент пришел ничего не знает, дам стипендию для начала и буду учить. Но если ничего не знает человек с 15 лет админства? Если он не знает чем vlan отличается от подсети, а роутер от маршрутизатора - что он в девопсии то сможет? А меж тем все без исключения говорили, что вот еще полгодика, надо доучиться и пойду в девопсы, там больше платят.
>Как мне кажется, ops инженер должен иметь основные знания и представления в области разработки
Как мне кажется, ops инженер должен для начала иметь основные знания и представления в области эксплуатации. Поэтому он называется ops. И только после получения знания и представлений в области разработки у него есть шанс стать devops - инженером, сочетающем знания и умения эксплуатации и разработки, чтобы создавать неразрывный конвейер.
Не так давно было бурное обсуждение тестирования импортозамещенных серверов, в рамках которого многие универсальные эксперты были уверены, что сервер - это процессор. Не верите - откройте обсуждения, почитайте.
Не так давно было бурное обсуждение тестирования импортозамещенных серверов, для которых пункты 1-5 составили непреодолимую преграду и сюрприз.
Как скажете, OVH - нормальный ЦОД?
41-43 после 1-5 просто потому что это же статья в соцсети, а не справочник. Пунктов много, но какой смысл их перечислять? Все, что в итоге получится - это долгое обмусоливание зачем вообще этот пункт в матрице функциональных тестов, а аффтар что так, что так ничего не понимает.
Что в конечном итоге и было вами написано. Автор 20 лет в ойти, из которых 12 проектирует и строит ЦОДы - в том числе можно можно посмотреть и на другие мои публикации, что не вызывают бурного комментирования. По общей теории проектирования. И выступления на самых разных конференциях. А так да - наверное копирайтер за буквы.
И возможность ловить несовместимости и потенциальные проблемы из-за неподдерживаемой системы. Когда инженер начинает экономить там, где его об этом никто не просил.
Нет времени объяснять, давайте делать колхоз из веток и известной субстанции. DataCore, Strawind и еще с десяток решений нервно курят в сторонке. Некоторые продаются дестяками лет, а DataCore и вовсе занимает верхние позиции в SPC1
А вы данные свои оценивали, чтобы можно было утверждать что продукт Х дорого / не дорого?
Интересно, сколько нужно времени, чтобы "обнаружить" специализированные дедуплицирующие СХД для резервного копирования типа DataDomain или StoreOnce?
Или например СРК (системы резервного копирования) с встроенной дедупликацией, как например Veeam?
Уровень аргументации зашкаливает. Меняем на зеркальный "ох уж этот страх и ужас перед монолитом". И вообще ничего не меняется по сути.
Именно так. Надо считать, надо проверять, смотреть альтернативы. И снова считать экономику.
Именно об этом я говорю - сначала бизнес цели, бизнес показатели, а техническая архитектура строится на основании бизнес требований. И никак не наоборот.
Это не жалоба, а комментарий по поводу использования OpenShift. При традиционном для девопсов деплое "как бог на душу положит" лицензирование OpenShift может превысить стоимость ВСЕГО остального софта на проекте.
Соответственно бездумный подход для коммерческих дистрибутивов не катит.
Ну вы еще мне расскажите про цепочку поставок и спеццены с условиями.
Я говорю только о чисто техническом утаптывании по условиям лицензирования + оптимизацией самого лицензирования через подбор размеров виртуальных воркеров без каких либо дополнительных телодвижений по спецусловиям.
OpenShift - это такая сборка, которая по стоимости может перекрыть весь остальной софт на проекте. Проверено лично.
Лично же РедХат ронял в 5 раз по цене за счет лицензирования.
Повлиять на то, как девопсы наго... задеплоили контейнеры не мог, а то уверен, что еще раз в несколько бы смог.
Решает ли он эти задачи? Не надуманы ли эти задачи? А что вообще для решения этих задач рассматривалось кроме кубера.
Я пока ни разу не получил нормального развернутого ответа.
Кубер-кубер-кубер!
Изоляция и деплой работают в системных виртуальных машинах, например.
М. Мастерство монтажа.
>Коннектор SCHUKO имеет 2 контакта
Это ничего, что даже на фото у вас 3 контакта? Два - вилка и плюс контакт земли комбинированный на разъем E (Франция) / F (Германия)
Каких только вариантов я не наслушался. Основной, конечно, что роутер - это домашняя хрень для интернета, а маршрутизатор - это то, что в корпоративе используют.
Основная беда не в том, что из сисадминов. В конце концов DevOps = Dev + Ops. Т.е. специалистов и в разработке, и в эксплуатации. Просто вы разработчик и смотрите на сисадминов традиционно как на чужих людей и даже врагов.
Беда в том, что из плохих и безграмотных сисадминов, которые не смогли вырасти в Ops, и тем более не смогли вырасти из эксплуатации в дизайн и архитектуру (ЗП сравнимы со средними по девопсерии).
В конечном итоге получается, что эти девопсы не умеют НИ в дев НИ в опс.
Пару лет назад хотел взять себе пару админов в офис на очень хорошие деньги (для админов) на немного хелпдеска, немного того, немного этого - и под руководством работы в ЦОДе и рост во всякое. При очень высокой, повторюсь, для админов зп.
Так то, что ко мне приходило, иногда с 15-20 лет "опыта" сисадмином, я бы отправил двор мести. Ладно студент пришел ничего не знает, дам стипендию для начала и буду учить. Но если ничего не знает человек с 15 лет админства? Если он не знает чем vlan отличается от подсети, а роутер от маршрутизатора - что он в девопсии то сможет?
А меж тем все без исключения говорили, что вот еще полгодика, надо доучиться и пойду в девопсы, там больше платят.
>Как мне кажется, ops инженер должен иметь основные знания и представления в области разработки
Как мне кажется, ops инженер должен для начала иметь основные знания и представления в области эксплуатации. Поэтому он называется ops.
И только после получения знания и представлений в области разработки у него есть шанс стать devops - инженером, сочетающем знания и умения эксплуатации и разработки, чтобы создавать неразрывный конвейер.
Не так давно было бурное обсуждение тестирования импортозамещенных серверов, в рамках которого многие универсальные эксперты были уверены, что сервер - это процессор. Не верите - откройте обсуждения, почитайте.
Да, найдутся. Если надо поддерживать 2-3 сервера в ИП Пупукин, торгующем носками.
В случае крупного корпоратива с 2-3 тыс серверов - нет, не найдется.
Не так давно было бурное обсуждение тестирования импортозамещенных серверов, для которых пункты 1-5 составили непреодолимую преграду и сюрприз.
Как скажете, OVH - нормальный ЦОД?
41-43 после 1-5 просто потому что это же статья в соцсети, а не справочник. Пунктов много, но какой смысл их перечислять? Все, что в итоге получится - это долгое обмусоливание зачем вообще этот пункт в матрице функциональных тестов, а аффтар что так, что так ничего не понимает.
Что в конечном итоге и было вами написано. Автор 20 лет в ойти, из которых 12 проектирует и строит ЦОДы - в том числе можно можно посмотреть и на другие мои публикации, что не вызывают бурного комментирования. По общей теории проектирования. И выступления на самых разных конференциях. А так да - наверное копирайтер за буквы.
И возможность ловить несовместимости и потенциальные проблемы из-за неподдерживаемой системы.
Когда инженер начинает экономить там, где его об этом никто не просил.
В чем смысл использования VirtualBox для облака VMware? Экономия на Workstation?
Нет времени объяснять, давайте делать колхоз из веток и известной субстанции. DataCore, Strawind и еще с десяток решений нервно курят в сторонке. Некоторые продаются дестяками лет, а DataCore и вовсе занимает верхние позиции в SPC1