Комментарии
29
Чисто из любопытства: учитывая, что инфраструктура в Azure, рассматривали вариант использования AzureRM Template'ов? У них есть существенные преимущества над TF, например, неразрушающие апгрейды, возможность экспорта ресурсов нативными средствами и, наконец, таки работающий плагин к VSCode с поддержкой Go to definition и всего такого.
Мы изначально выбирали именно решение с возможностью работы с несколькими cloud providers. Есть у нас сервисы не только в ажуре, причем в основном именно наши, инфраструктурные.
Про поддержку плагинов — мы частично используем плагин от Jetbrains и соответственно Rider.
Про поддержку плагинов — мы частично используем плагин от Jetbrains и соответственно Rider.
Мы изначально выбирали именно решение с возможностью работы с несколькими cloud providers.
Вот каждый раз читаю такое и удивляюсь, почему компании пытаются играть в независимость от поставщика услуг? Ведь риск того, что Azure/AWS/Google и другие исчезнут — на несколько порядков ниже, чем риски вашего бизнеса.
Я еще пойму, что риски работы в России накладывают определенные ограничения, тут уж ничего не поделать, но «возможность работы с несколькими cloud providers»… хоть убейте, не могу понять.
Исчезнут — ладно, но могут резко изменить ценовую политику, или быстро не просто задепрекейтить что-то в текущей версии, но и перестать поддерживать в следующей. Отсутствие вендор-лока это ещё постоянная готовность к обновлению на новую версию текущего.
Ценовая политика может быть определенным аргументом в зависимости от типа компании, но что вы предлагаете, покупать свое железо и строить свои дата-центры?
Ведь цены на те же EC2 по вашей логике могут поменяться.
Вот есть несколько больших игроков на рынке такие как Google/Azure/AWS и ценовая политика зависит не от желания этих компаний, а от их конкуренции.
Вот это точно не аргумент, это просто работа. Нам постоянно приходится следить за обновлениями в ОС, языках программирования, библиотеках и фреймворках которые используем, различных 3rd party сервисах. Тут скорее наоборот, используя какой-либо сервис cloud provider'а количество подвижных частей уменьшается, т.к. он предоставляет некую абстракцию.
Ведь цены на те же EC2 по вашей логике могут поменяться.
Вот есть несколько больших игроков на рынке такие как Google/Azure/AWS и ценовая политика зависит не от желания этих компаний, а от их конкуренции.
задепрекейтить что-то в текущей версии, но и перестать поддерживать в следующей
Вот это точно не аргумент, это просто работа. Нам постоянно приходится следить за обновлениями в ОС, языках программирования, библиотеках и фреймворках которые используем, различных 3rd party сервисах. Тут скорее наоборот, используя какой-либо сервис cloud provider'а количество подвижных частей уменьшается, т.к. он предоставляет некую абстракцию.
Я еще пойму, что риски работы в России накладывают определенные ограничения
Такой риск существует и это одна из причин.
Также, как я уже говорил, часть функций находится в других облаках. Например, на google functions у нас бот для ScaleFT или бот, создающий карточки при инциденте.
Еще один риск — это ценовая политика. Деньги в клауде могут улететь очень быстро, а цены могут отличаться в разы.
Кстати да. Еще забавно, когда облако не особо виновато, просто курс изменился раза в 2.
А ещё у каждого клауд провайдера бывают глобальные аутеджи. У того же ажура была недавно история, когда DNS на managed базы лежал час. Или нетворк между датацентрами 6 часов лежал без предсказания, когда поднимется.
Это происходит очень редко, но в такие моменты или уже должна быть готова инфраструктура на другом облаке, либо должна быть возможность, инструкции и подготовленный плацдарм, чтобы быстро развернуться на другом облаке и переключить на него трафик.
Это происходит очень редко, но в такие моменты или уже должна быть готова инфраструктура на другом облаке, либо должна быть возможность, инструкции и подготовленный плацдарм, чтобы быстро развернуться на другом облаке и переключить на него трафик.
Ну так историю этих аутеджей можно посмотреть и спланировать стратегию для своего сервиса.
Большой вопрос что для вашего сервиса это значит, если это критическая часть системы, то что поделать, возможно нельзя использовать managed db, возможно разделить read/write модели, возможно добавить кеширование. Но решение как поступить оно только ваше, т.к. никто кроме вас специфики не знает.
Тоже самое, возможно мой сервис в одном датацентре. А если в нескольких, то тут же очевидно, что хоть с клаудом, хоть без него должна быть стратегия как сервис будет работать и восстанавливаться при отключении одного из датацентров или потери связи между ними. Ничего нового клауд в этом смысле не привнес.
DNS на managed базы лежал час
Большой вопрос что для вашего сервиса это значит, если это критическая часть системы, то что поделать, возможно нельзя использовать managed db, возможно разделить read/write модели, возможно добавить кеширование. Но решение как поступить оно только ваше, т.к. никто кроме вас специфики не знает.
Или нетворк между датацентрами 6 часов лежал без предсказания, когда поднимется.
Тоже самое, возможно мой сервис в одном датацентре. А если в нескольких, то тут же очевидно, что хоть с клаудом, хоть без него должна быть стратегия как сервис будет работать и восстанавливаться при отключении одного из датацентров или потери связи между ними. Ничего нового клауд в этом смысле не привнес.
> Ну так историю этих аутеджей можно посмотреть и спланировать стратегию для своего сервиса.
Смысл аутеджей, в том, что их сложно предсказывать. Мы же говорим не про плановую поддержку.
Ну и да, мы сделали как вы советуете: спланировали, что в перспективе должны иметь план в виде второго облака / независимого ДЦ. (Это не только из-за отказов облаков, но и из-за правовых причин)
> возможно нельзя использовать managed db
on-premise машины тоже будут падать, сеть до них тоже будет теряться. Естественно, если это критический путь в системе, он должен быть достаточно надёжен, чтобы самовосстановиться и продолжить работать. Мы так и делаем.
Второй ДЦ берётся не из воздуха, а из попытки достичь большего количества «девяток», чем может предложить одно облако. Объяснять бизнесу, что ажур (амазон, гугл) сломался во всём мире и мы ничего не можем с этим поделать – слабая позиция.
> Ничего нового клауд в этом смысле не привнес.
Согласен
Смысл аутеджей, в том, что их сложно предсказывать. Мы же говорим не про плановую поддержку.
Ну и да, мы сделали как вы советуете: спланировали, что в перспективе должны иметь план в виде второго облака / независимого ДЦ. (Это не только из-за отказов облаков, но и из-за правовых причин)
> возможно нельзя использовать managed db
on-premise машины тоже будут падать, сеть до них тоже будет теряться. Естественно, если это критический путь в системе, он должен быть достаточно надёжен, чтобы самовосстановиться и продолжить работать. Мы так и делаем.
Второй ДЦ берётся не из воздуха, а из попытки достичь большего количества «девяток», чем может предложить одно облако. Объяснять бизнесу, что ажур (амазон, гугл) сломался во всём мире и мы ничего не можем с этим поделать – слабая позиция.
> Ничего нового клауд в этом смысле не привнес.
Согласен
В какой-то момент прошлого (прошлого же?) года из России исчезла заметная часть AWS, а часть Digital Ocean вовсе до сих пор не вернулась. Вот в ситуации, когда "А-ааа, РКН опять!" очень пригодятся затраты на то, чтобы не сильно зависеть от конкретного облачного провайдера.
Я бы не стал примешивать политику в обсуждение зависимости от поставщиков.
Мы же не все в России живем, да и я согласен, что законы принимаемые в России это весомый аргумент для бизнеса.
Мне интересно было бы обсудить реальные аргументы против зависимости от поставщиков, ведь по логике, вендор заинтересован предоставить лучший сервис т.к. он же не в вакууме живет, а также как и другие бизнесы находится в конкурентной среде, даже в высоко-конкурентной, другими словами он деньгами заинтересован бороться за минимальные цены, повышать SLA, делать обратно совместимые изменения.
Мы же не все в России живем, да и я согласен, что законы принимаемые в России это весомый аргумент для бизнеса.
Мне интересно было бы обсудить реальные аргументы против зависимости от поставщиков, ведь по логике, вендор заинтересован предоставить лучший сервис т.к. он же не в вакууме живет, а также как и другие бизнесы находится в конкурентной среде, даже в высоко-конкурентной, другими словами он деньгами заинтересован бороться за минимальные цены, повышать SLA, делать обратно совместимые изменения.
Если вендор уверен, что большинство его клиентов залочено на него, то он может себя вести в отношении них как будто конкурентов у него особо нет.
Зачем? Чтобы новые клиенты со 100%-ой вероятностью выбрали конкурента, а старые начали думать о миграции?
Тут скорее про то, что вот есть разработчики(мы) и нас надо подготовить к дежурствам в инфраструктуре, в которых мы не знаем как вести себя, не обладаем изначально нужными знаниями.
При дежурствах ты становишься уже первой линией, должен первым реагировать на инциденты и если необходимо, то уже подключать аналитиков или непосредственно разработчиков, которые и ответственны за сервис.
При дежурствах ты становишься уже первой линией, должен первым реагировать на инциденты и если необходимо, то уже подключать аналитиков или непосредственно разработчиков, которые и ответственны за сервис.
т.е. непосредственно тебе идут оповещения от системы мониторинга?
Сейчас мы в процессе онбординга, но уже скоро пойдут. В этом одна из целей — чтобы увеличить пул дежурных.
т.е. если я разработчик и у меня крепкий сон, так что я не услышу звонок, полстраны лишаться пиццы?
Разработчик в команде инфраструктуры должен дежурить, быть на пейджере. Есть расписание, есть процесс дневных вечерних дежурств. Кстати, можно было бы и рассказать про то, как это подробно работает.
Обычные разработчики не дежурят(за исключением некоторых праздников).
А как мотивировали разработчиков во всё это вникать?
Изначально в группу обучения вступили все равно те разработчики, кто занимался близкой тематикой последнее время. К примеру я до этого 2 года занимался так или иначе техническими задачами, а они непременно связаны. Остальные примерно так же.
Еще участие добровольное и те, кто не захотят остаться в инфраструктуре могут выйти.
Плюс прорекламирую непосредственно доклад на эту тему еще от одного члена команды. devopsconf.io/moscow/2019/abstracts/5575
Еще участие добровольное и те, кто не захотят остаться в инфраструктуре могут выйти.
Плюс прорекламирую непосредственно доклад на эту тему еще от одного члена команды. devopsconf.io/moscow/2019/abstracts/5575
Спасибо за актуальную статью! Тесты пишутся со временем, в том же ансибл, в dev контуре для инфраструктуры.
Спасибо! В итоге мы стали писать тесты, поднимающие отдельный терраформ модуль, проверяющие, что там все поднялось корректно и все данные на машине прошли. Мы стали использовать питон, т.к. на нем пишутся скрипты-склейки, так что он уже был в части инфраструктуры.
И пока полет нормальный. Вот что прям не вызывает проблем — так это тесты на питоне и сам питон
И пока полет нормальный. Вот что прям не вызывает проблем — так это тесты на питоне и сам питон
Я давно и кровавыми слезами плачу от всей существующей инфраструктуры для iaac. Сверхленивая типизация, UB как нормальное состояние (что именно делает UB проверяют тесты, и если поведение похоже на нужное, то это принимается), отсутствие нормальных интерфейсов...
Остро хочется системы управления конфигурациями, которая бы знала всё (т.е. не пришли и что-то там подфигачили, а runtime, который знает всё — от ip-адресов до номеров прерываний), и которая бы на уровне системы типов могла надавать по ушам до запуска чего-либо.
Ансибл, кстати, в этой области сделал просто преступление, переведя всё на массив глобальных переменных. Coupling на максимальном уровне, переиспользования кода нет, попытка написать чистую функцию оставляет после себя perl на jinja, плюс бесконечное нарушение абстракций.
Пока вы льёте слёзы в виллобаджо уже нафигачили в баше и пьют пиво.
Это я к тому, что жить как-то надо и приходится работать с тем, что есть.
Это я к тому, что жить как-то надо и приходится работать с тем, что есть.
Работаем с чем есть, но для ansible и динамической типизации в iaac поставлено клеймо "плохо". Это означает, что есть большой стимул смотреть на следующую попытку сделать систему управления конфигурациями как только она появится.
Бывают инструменты для которых есть точное мнение "лучше не нужно". Пример — py.test, который лучшее, что есть я видел.
Так есть же специально обученный человек — System Engineer. Он привыкший к таким вещам как отсутствие:
Debugging.
Refactoring tool.
Auto completion.
Обнаружении ошибок при компиляции.
Какие объекты? зачем они нам если мы пол жизни провели в баше?
Его полностью устраивает весь тулинг. Зачем делать из ваших девов систем инженеров и забирать у нас наш хлеб? Я к тому что каждый должен делать свою работу, а не быть Крузенштерном фуллстаком. И кстати про неудобства — через полгода все может очень сильно поменяться. Сами написали про скорость развития этого направления.
Debugging.
Refactoring tool.
Auto completion.
Обнаружении ошибок при компиляции.
Какие объекты? зачем они нам если мы пол жизни провели в баше?
Его полностью устраивает весь тулинг. Зачем делать из ваших девов систем инженеров и забирать у нас наш хлеб? Я к тому что каждый должен делать свою работу, а не быть Крузенштерном фуллстаком. И кстати про неудобства — через полгода все может очень сильно поменяться. Сами написали про скорость развития этого направления.
так надо
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Infrastructure as Code: первое знакомство