То что вы описываете проблемы менеджмента, а не инфраструктуры. У нас сертификаты обновляет cert-manager. Мы вообще его на let's encrypt настроили и ничего не платим за сертификаты- все хорошо уже 2 года. Это решение спокойно маштабируется на все кластера централизованно или в виде шаблона.
Но повторюсь - 200 автономных команд на базе платформы которой все равно управляет инфраструктурная команда - вполне способны работать. Никто не говорит, что оно само заработает. Да много чего надо допиливать.
Но я опровергал ваше заявление о том что ваш солюшен дешевле облачных решений. По практическому опыту- самопилные вещи всегда дороже. Да иногда это оправданно, но не дешевле чем взять готовое и допилить.
@makc9I да я пишу в 2014 год )) Вы в курсе что во всем мире перерабатывается только около 3% батареек- их переработку трудно автоматизировать, и это делает ее невыгодной.
так а почему знакомые и гугл должны помогать? Это какой-то ложный посыл- раз гугл и знакомые не помогли, то виноват не я. Вы не справились, никто не виноват кроме вас.
[1] постоянно этим занимаемся, это вполне нормальные сроки, если приложений много, не вижу вообще ничего плохого в том, чтобы не ломая ничего переехать постепенно. Просто новые проекты не разрешают создавать по старому и все за 2 года максимум переезжает.
[2] Контроль это вообще административное понятие, у вас же руководители способны контролировать инженеров? Надеюсь что да. Вот до руководителей доноситься это правило, они доносят до инжинеров. Со второй стороны это как раз вашей структурой и должно контролироваться- в виде ассесмента/валидации КАЖДОГО нового сервиса. У нас это поставлено на поток, если ты поставил сервис в прод без валидации и добавления его в backstage- это равносильно запуску биткойн генератора по последствиям.
[3] ИБ не религия, с ними всегда можно договориться исходя из реалий бизнеса. Нужно вам получить определенный сертификат в этой области- смотрите что не попадает - идете к ИБ и к клауд провайдеру и разговариваете. Все эти стороны заинтересованы договориться. Да клауд провайдер может пилить сервис в нужную вам сторону дольше чем вы- например год. Но вы не единственные клиенты которые сталкиваются с такой проблемой, а провайдер держит нос по ветру и критичные вещи он должен быстро исправлять, ведь он то сам как то это сертификат получил ))
[4] Смотря что понимать под доступностью. В общем случае - использовать не один регион а 2-3, реплики БД, запасной провайдер. 3 региона у Яндекса уже надежнее ваших двух датацентров. Их тупо 3, а может быть 10 за совсем небольшие деньги.
Ну и люди всегда будут ругать любой солюшен, какой бы он не был. Просто когда он сделан по канонам, гораздо больше людей понимает почему так, и не нужно тратить время на обьяснения
Так это не обязательно должно быть через клауд, графана и ELK которую вы крутите как сервис - вполне справятся. Большая часть тут должна быть не на вас а на командах которые отвечают за сервис, вы только предоставляете платформу.
Прелесть не теряется- вы допиливаете только небольшие части. У нас сами команды допиливают мелкие opensource сервисы никто никаких заявок в инфра подразделение не пишет. Зачем кудато писать если большинство сервисов это docker image? Поменял код - запустил и дальше работаешь.
Я ответил выше в треде, но про провайдер специфик штучки скажу так - очень сильно стоит подумать, а так ли нужны они? Вспомните MongoDB- в период популярности на его базе че только не пилили, а сейчас я даже встречал lock на использование монго на уровне дизайна.
Например вот без секьюрити фич вам не обойтись, у каждого провайдера нетворк и секьюрити свой. Но опять же, снаружи можно сделать все по дефолту, а внутри кластера Кубернетес использовать его инструменты, и это обычно везде работает. Если вы не решите использовать AWS EKS Pod security group конечно.
Cloud Agnostic это подход который позволяет минимизировать боль при миграции между клауд провайдерами. Он не пропагандирует воздержание от использования любых фич провайдеров, а предлагает всегда учитывать что возможно солюшен/инфраструктура будет переезжать к другому провайдеру.
Например лоад балансеры придется использовать, nginx ingress не во всех сценариях поможет. Но лоад балансеры в том или ином виде есть везде- и это можно смигрировать. А вот напримир AWS Aurora проприетарное решение и смигрировать оттуда БД гораздо больнее. Поэтому решение не использовать Aurora а использовать Postgress может быть принято в том числе исходя и из этого аргумента.
Вы лукавите. Облачный провайдер не идеален не разу- но закрывает сразу широкий спектр сервисов, которые ВАМ не надо пилить. И это будет один вендор с бесшовной интеграцией этих сервисов. И вы можете в любой момент встать и уйти, да сейчас в РФ не так много альтернатив, но эта ситуация не статична. И как я писал выше - расширить функционал готового солюшена гораздо проще чем пилить свою вундервафлю.
Не знаю как в Я но в AWS варианты управления политиками и секьюрити группами на любой вкус.
И к вашему кейсу как нельзя лучше подходят слова Безоса: > В 1900 году чтобы открыть магазин вам надо было построить электростанцию рядом. В 2000х никому и в голову не придет строить свою электростанцию- все просто покупают электроэнергию у электрокомпаний. Вот вы занимаетесь тем что мастерите электростанцию. Да возможно неплохую, да сильно кастомизированную, но не факт что вашему бизнесу от этого лучше. Вам интересно - это как раз понятно.
на мой скромный взгляд для 200 команд проще каждой было дать аккаунт в Yandex + настроить кубернетес кластер в этом аккаунте. Вопросы ИБ и прочего решаются политиками и рулами.
И уж после миграции заниматься тюнингом и зажиманием гаек, естественно это не быстро и каждый проект может требовать индивидуального подхода.
Ну так вы сегодня есть, а завтра вас сбил автобус, и документация не особо поможет. Про яндекс я не знаю- есть ли там бюджеты, в AWS нет проблем с любой гранулярностью бюджеты считать, опять же проще по тегам свою тулу для расчета сделать, чем свое облако :)
Да я читал, но это общие слова. Можно как угодно посчитать, чтобы доказать что наш солюшен дешевле. Про скидки от клауд провайдера вы например промолчали.
И ваш подход избегать Vendor Lock он контр продуктивный- я тоже раньше верил в то что быть независимым можно, и что OpenSource это спасение, но увы.
Вы сами, с Mirantis, добровольно в этот капкан попали.
На мой скромный взгляд более правильно использовать подход Cloud Agnostic - при кажущейся одинаковости, он отличается от VendorLock. Мы используем каких-то провайдеров, но всегда держим в голове тот момент, что нам может понадобиться его поменять и наш солюшен должен быть максимально независимым.
Отсюда как раз и вытекает что выгоднее взять ОДНОГО провайдера, например, Yandex у которого и бакеты и базы данных и бекапы и Кубернетес уже есть. Да вы будете привязаны к этим сервисам, но только одного вендора и мигрировать будет легче. И у вас не будет головняка поддерживать десяток сервисов от разных провайдеров - что намного затратнее.
Не клауд агностик это например использовать в AWS - Aurora. У других вендоров ее нет.
Волнует еще такой вопрос- вы пишете что основной прирост идет за счет таких специалистов как SRE- но я в вакансиях кроме Системных администраторов больше никаких релятивных позиций не увидел. Думаю если бы у вас было побольше современных специалистов, а не старой гвардии- они бы вам в ваших дискусиях указали на все эти моменты.
Не хочу быть скептиком без знания деталей, но как считается - "дешевле практически по всем сервисам любого публичного облака в РФ"? Я том плане что затраты на разработку облака и его текущий мейнтенанс учитываются? Учитываются ли скидки от Яндекса которые для организаций вашего размера могли бы достигать 30-40 процентов?
Как по мне разумнее всегда не изобретать велосипед, взять готовое и нормально - и ехать на чужом, допиливая свое. Я прекрасно представляю сколько нужно усилий и времени чтобы поддерживать такое решение в работоспособном состоянии- а может эти ресурсы могли бы делать что то более полезное.
Здесь была невнятная статься от Flant где они запилили всего лишь замену Опсджини но на вопрос чем это лучше так и не смогли ответить(ну кроме того что это написано не нами(С)). Не смотря на разницу масштабов и затрат мне почему-то видится что кейсы похожие.
[для большей ясности приведу пример] у вас на сайте есть раздел Вакансии. Вы не выдумывали своего, а просто поставили там редирект на HH. И это вполне зрело и мудро - у вас единая точка правды, вы не тратите бабки на запиливание собственной вундервафли для поиска персонала и количество показов ваших вакансий на HH просто несравнимо с тем что было бы если бы вы шли только со своим решением по публикации вакансий.
Чето ходят слухи что Бетельгейзе все таки поплахело
Это когда капитализация влияла на умственные способности директоров? Ну чтобы их мнения возводить в императив?
Ну резковато, но по делу
а где я говорил, что там что-то не так?
То что вы описываете проблемы менеджмента, а не инфраструктуры. У нас сертификаты обновляет cert-manager. Мы вообще его на let's encrypt настроили и ничего не платим за сертификаты- все хорошо уже 2 года. Это решение спокойно маштабируется на все кластера централизованно или в виде шаблона.
Но повторюсь - 200 автономных команд на базе платформы которой все равно управляет инфраструктурная команда - вполне способны работать. Никто не говорит, что оно само заработает. Да много чего надо допиливать.
Но я опровергал ваше заявление о том что ваш солюшен дешевле облачных решений. По практическому опыту- самопилные вещи всегда дороже.
Да иногда это оправданно, но не дешевле чем взять готовое и допилить.
@makc9I да я пишу в 2014 год )) Вы в курсе что во всем мире перерабатывается только около 3% батареек- их переработку трудно автоматизировать, и это делает ее невыгодной.
https://www.adobe.com/products/photoshop/online.html
так а почему знакомые и гугл должны помогать? Это какой-то ложный посыл- раз гугл и знакомые не помогли, то виноват не я. Вы не справились, никто не виноват кроме вас.
может стоит освоить Ansible?
[1] постоянно этим занимаемся, это вполне нормальные сроки, если приложений много, не вижу вообще ничего плохого в том, чтобы не ломая ничего переехать постепенно. Просто новые проекты не разрешают создавать по старому и все за 2 года максимум переезжает.
[2] Контроль это вообще административное понятие, у вас же руководители способны контролировать инженеров? Надеюсь что да. Вот до руководителей доноситься это правило, они доносят до инжинеров.
Со второй стороны это как раз вашей структурой и должно контролироваться- в виде ассесмента/валидации КАЖДОГО нового сервиса. У нас это поставлено на поток, если ты поставил сервис в прод без валидации и добавления его в backstage- это равносильно запуску биткойн генератора по последствиям.
[3] ИБ не религия, с ними всегда можно договориться исходя из реалий бизнеса. Нужно вам получить определенный сертификат в этой области- смотрите что не попадает - идете к ИБ и к клауд провайдеру и разговариваете. Все эти стороны заинтересованы договориться. Да клауд провайдер может пилить сервис в нужную вам сторону дольше чем вы- например год. Но вы не единственные клиенты которые сталкиваются с такой проблемой, а провайдер держит нос по ветру и критичные вещи он должен быстро исправлять, ведь он то сам как то это сертификат получил ))
[4] Смотря что понимать под доступностью. В общем случае - использовать не один регион а 2-3, реплики БД, запасной провайдер. 3 региона у Яндекса уже надежнее ваших двух датацентров. Их тупо 3, а может быть 10 за совсем небольшие деньги.
[5]
https://cloud.yandex.ru/services/managed-redis
https://cloud.vk.com/databases/redis/
Ну и люди всегда будут ругать любой солюшен, какой бы он не был. Просто когда он сделан по канонам, гораздо больше людей понимает почему так, и не нужно тратить время на обьяснения
Так это не обязательно должно быть через клауд, графана и ELK которую вы крутите как сервис - вполне справятся.
Большая часть тут должна быть не на вас а на командах которые отвечают за сервис, вы только предоставляете платформу.
Прелесть не теряется- вы допиливаете только небольшие части.
У нас сами команды допиливают мелкие opensource сервисы никто никаких заявок в инфра подразделение не пишет.
Зачем кудато писать если большинство сервисов это docker image?
Поменял код - запустил и дальше работаешь.
Я ответил выше в треде, но про провайдер специфик штучки скажу так - очень сильно стоит подумать, а так ли нужны они?
Вспомните MongoDB- в период популярности на его базе че только не пилили, а сейчас я даже встречал lock на использование монго на уровне дизайна.
Например вот без секьюрити фич вам не обойтись, у каждого провайдера нетворк и секьюрити свой. Но опять же, снаружи можно сделать все по дефолту, а внутри кластера Кубернетес использовать его инструменты, и это обычно везде работает. Если вы не решите использовать AWS EKS Pod security group конечно.
Каждый сам себе злобный буратино.
Cloud Agnostic это подход который позволяет минимизировать боль при миграции между клауд провайдерами. Он не пропагандирует воздержание от использования любых фич провайдеров, а предлагает всегда учитывать что возможно солюшен/инфраструктура будет переезжать к другому провайдеру.
Например лоад балансеры придется использовать, nginx ingress не во всех сценариях поможет. Но лоад балансеры в том или ином виде есть везде- и это можно смигрировать. А вот напримир AWS Aurora проприетарное решение и смигрировать оттуда БД гораздо больнее. Поэтому решение не использовать Aurora а использовать Postgress может быть принято в том числе исходя и из этого аргумента.
Вы лукавите. Облачный провайдер не идеален не разу- но закрывает сразу широкий спектр сервисов, которые ВАМ не надо пилить. И это будет один вендор с бесшовной интеграцией этих сервисов. И вы можете в любой момент встать и уйти, да сейчас в РФ не так много альтернатив, но эта ситуация не статична.
И как я писал выше - расширить функционал готового солюшена гораздо проще чем пилить свою вундервафлю.
Не знаю как в Я но в AWS варианты управления политиками и секьюрити группами на любой вкус.
И к вашему кейсу как нельзя лучше подходят слова Безоса:
> В 1900 году чтобы открыть магазин вам надо было построить электростанцию рядом. В 2000х никому и в голову не придет строить свою электростанцию- все просто покупают электроэнергию у электрокомпаний. Вот вы занимаетесь тем что мастерите электростанцию. Да возможно неплохую, да сильно кастомизированную, но не факт что вашему бизнесу от этого лучше. Вам интересно - это как раз понятно.
на мой скромный взгляд для 200 команд проще каждой было дать аккаунт в Yandex + настроить кубернетес кластер в этом аккаунте. Вопросы ИБ и прочего решаются политиками и рулами.
И уж после миграции заниматься тюнингом и зажиманием гаек, естественно это не быстро и каждый проект может требовать индивидуального подхода.
Ну так вы сегодня есть, а завтра вас сбил автобус, и документация не особо поможет.
Про яндекс я не знаю- есть ли там бюджеты, в AWS нет проблем с любой гранулярностью бюджеты считать, опять же проще по тегам свою тулу для расчета сделать, чем свое облако :)
Да я читал, но это общие слова.
Можно как угодно посчитать, чтобы доказать что наш солюшен дешевле. Про скидки от клауд провайдера вы например промолчали.
И ваш подход избегать Vendor Lock он контр продуктивный- я тоже раньше верил в то что быть независимым можно, и что OpenSource это спасение, но увы.
Вы сами, с Mirantis, добровольно в этот капкан попали.
На мой скромный взгляд более правильно использовать подход Cloud Agnostic - при кажущейся одинаковости, он отличается от VendorLock.
Мы используем каких-то провайдеров, но всегда держим в голове тот момент, что нам может понадобиться его поменять и наш солюшен должен быть максимально независимым.
Отсюда как раз и вытекает что выгоднее взять ОДНОГО провайдера, например, Yandex у которого и бакеты и базы данных и бекапы и Кубернетес уже есть. Да вы будете привязаны к этим сервисам, но только одного вендора и мигрировать будет легче. И у вас не будет головняка поддерживать десяток сервисов от разных провайдеров - что намного затратнее.
Не клауд агностик это например использовать в AWS - Aurora. У других вендоров ее нет.
Волнует еще такой вопрос- вы пишете что основной прирост идет за счет таких специалистов как SRE- но я в вакансиях кроме Системных администраторов больше никаких релятивных позиций не увидел.
Думаю если бы у вас было побольше современных специалистов, а не старой гвардии- они бы вам в ваших дискусиях указали на все эти моменты.
Не хочу быть скептиком без знания деталей, но как считается - "дешевле практически по всем сервисам любого публичного облака в РФ"? Я том плане что затраты на разработку облака и его текущий мейнтенанс учитываются? Учитываются ли скидки от Яндекса которые для организаций вашего размера могли бы достигать 30-40 процентов?
Как по мне разумнее всегда не изобретать велосипед, взять готовое и нормально - и ехать на чужом, допиливая свое. Я прекрасно представляю сколько нужно усилий и времени чтобы поддерживать такое решение в работоспособном состоянии- а может эти ресурсы могли бы делать что то более полезное.
Здесь была невнятная статься от Flant где они запилили всего лишь замену Опсджини но на вопрос чем это лучше так и не смогли ответить(ну кроме того что это написано не нами(С)). Не смотря на разницу масштабов и затрат мне почему-то видится что кейсы похожие.
[для большей ясности приведу пример] у вас на сайте есть раздел Вакансии. Вы не выдумывали своего, а просто поставили там редирект на HH. И это вполне зрело и мудро - у вас единая точка правды, вы не тратите бабки на запиливание собственной вундервафли для поиска персонала и количество показов ваших вакансий на HH просто несравнимо с тем что было бы если бы вы шли только со своим решением по публикации вакансий.
А ручник что же?
Торможение юзом?
ну посыл та там очевидно другой- все на древних паровозах, ужос ужос. И цифр нет- сколько устаревших тепловозов. Просто апелляция к эмоциям.
Да вас вот не смутила фраза > Вернемся к мудрому.
Это очевидно творчество чата гпт который не так хорош в русском языке