Comments 62
В чем поинт статьи?
Таки что не так с devops? Тему то не раскрыли.
Работы много еще там, многие этого не замечают или не хотят замечать
Так девопс — это не серебрянная пуля. Это идея автоматизации всего в округе, чтобы не приходилось админам вручную ручки крутить у разных окружений. Чтобы можно было обновлять\откатывать каждые пару минут и никто не умирал, и не было шансов сделать ошибку.
Оно вообще не о производительности, которую видимо меряли в статье.
Оно вообще не о производительности, которую видимо меряли в статье.
С одной стороны, да, много. Но с другой, очень много уже сделано.
Работы много по усложнению жизни жизни админов разработчиками? Или что? :-)
А когда благодаря автоматизации у devops работы снова станет мало, их припрягут к разгрузке фур и охране склада сутки через трое.
Проблема не в монолите, в скорости изменений. Можно ли монолит релизить несколько раз в день? Гипотетически да, но зачем так жить?
Второй момент — стоимость железа. Гектар оперативы стоит копейки и довольно часто баланс между скоростью разработки и стоимостью поддержки в деньгах чаще выражается в большей эффективности быстрой разработки.
Конечно, в отдельных отраслях это неразумно, но, я надеюсь, в них люди на хайп не байтятся.
Второй момент — стоимость железа. Гектар оперативы стоит копейки и довольно часто баланс между скоростью разработки и стоимостью поддержки в деньгах чаще выражается в большей эффективности быстрой разработки.
Конечно, в отдельных отраслях это неразумно, но, я надеюсь, в них люди на хайп не байтятся.
Монолит можно релизить несколько раз в день, и выкативаться монолитом на стейджинг десятки сотен раз в день тоже можно.
И даже если монолит разбить на N "микросервисов", это не значит что вы сможете релизиться в N раз чаще, накладные расходы на тестирование, синхронизацию и обучение людей писать в соответствии с таким подходом никто не отменял.
Верно, разбиение не даст возможность релизиться чаще. Даже наоборот, каждый отдельный микросервис будет релизиться реже (вплоть до N раз в идеальном случае), что как раз снижает накладные расходы.
Не могу понять логическую цепочку. Почему накладные расходы снижаются? Они как раз таки увеличиваются. Да и идея не в частоте релизов, а в том что бы релиз отдельной части системы не влиял на остальные. И нужно это очень малому проценту проектов.
Потому, что вместо релиза, скажем, Windows, происходит релиз только отдельного компонента и соответственно тестировать нужно меньше. И это можно сделать умнее, чем просто «тестим всё» при релизе монолита. Кроме того, если над каждым микросервисом работает отдельная команда, то одни могут релизиться каждую среду, другие — каждый четверг и т.д. В случае зависимости микросервисов релиз также будет завязан друг на друга, но в монолите по факту такое происходит каждый раз.
Опять же, зависит от количества команд. Чем больше, тем сложнее релизить монолит часто.
Опять же, зависит от количества команд. Чем больше, тем сложнее релизить монолит часто.
вместо релиза, скажем, Windows, происходит релиз только отдельного компонента и соответственно тестировать нужно меньше
Это очень спорное заявление.
Я отлично помню ситуацию, когда на win2k8 устанавливался языковой пакет для NetFramework35. Даже при отсутствующем установленном NetFramework35. Это приводило, в свою очередь, к тому, что ломалась вещь, никак с этим не связанная — консоли mmc, т.е. все оснастки становились недоступными. Ситуацию усугубляло то, что это только на неанглийских версиях системы было. Вещи вроде бы несвязанные, но к чему привело — я описал.
происходит релиз только отдельного компонента и соответственно тестировать нужно меньше.
Если тестировать нужно меньше, значит вы как-то изолировали влияние компонента на другие части системы. То есть у нас низкая связанность. Что вам мешает делать монолиты с низкой связанностью?
Кроме того, если над каждым микросервисом работает отдельная команда, то одни могут релизиться каждую среду, другие — каждый четверг и т.д.
а третьи могут релизить монолит целиком и полностью 10 раз в день. И что?
В случае зависимости микросервисов релиз также будет завязан друг на друга, но в монолите по факту такое происходит каждый раз.
Это управление зависимостями и в случае и микросервисов и монолитов все примерно одинаково. Другое дело, что скажем релиз одного компонента безболезненно происходит, а при изменениях другого надо проходить сертификацию к примеру. И тут выгодно разделить эти компоненты так, что бы у них был независимый цикл релизов.
Микросервисы сами по себе вообще ничего не дают. В сферическом вакууме уж точно. Это не благодать а вынужденная мера. Как думаете что будет с проектом на микросервисах, которые пилит команда, не в состоянии добиться низкой связанности компонентов в монолитном варианте?
Если тестировать нужно меньше, значит вы как-то изолировали влияние компонента на другие части системы. То есть у нас низкая связанность. Что вам мешает делать монолиты с низкой связанностью?
Верно, я не озвучил очевидное для меня допущение — релиз монолитного приложения по процессу занимает от часа до недели. В случае, если релиз приложения можно выкатить за минуту (и откатить за секунду), то, конечно, делить его смысла нет.
очевидное для меня допущение — релиз монолитного приложения по процессу занимает от часа до недели.
а можете пояснить, на основании чего было сделано подобное допущение? То есть мы говорим о проектах без адекватного уровня автоматизации доставки, а ни как не про монолит vs мифические микросервисы?
То есть мы говорим о проектах без адекватного уровня автоматизации доставки
Монолит за несколько лет своей эксплуатации вырос до размеров, что основная операционная база занимает несколько терабайт. И деплой изменений, затрагивающий миграции в основных таблицах, растягивается на недели, так как альтернатива связана с остановкой бд, деплоем бизнес-кода с новой логикой и поднятие бд. Практически без шансов на откат в случае, если что-то пошло не так. Поэтому маленькими шагами (т.е. с диким оверхедом к основным изменениям), чтобы максимально минимизировать даунтаймы и последствия от возможных неудач.
После этого понимание, что так быть не должно и надо что-то менять, приходит само.
Комментарий GreedyIvan примерно описывает что я понимаю под монолитом и его проблемами, с которыми в концепции DevOps разработчики борятся. ИМХО, адекватный уровень автоматизации доставки гораздо ближе к сферическим микросервисам в вакууме — при большой базе (кода и данных) приходится грамотно разделять компоненты и деплоить их по-одному или несколько (но не обязательно все сразу).
адекватный уровень автоматизации доставки гораздо ближе к сферическим микросервисам в вакууме
это подмена понятий и искажение терминологии. Причем очень грубое. Настолько грубое что невилирует какой либо смысл в термине "микросервис", уж слишком сильно его извратить успели.
при большой базе (кода и данных) приходится грамотно разделять компоненты и деплоить их по-одному или несколько (но не обязательно все сразу).
Грамотно разделять на компоненты — это всегда важно, зависимости, связанность и все такое. Но почему если у меня приложение жирное, и данных в базе много, это как-то влияет на деплоймент? Например, у меня есть миграция которая добавляет одно поле в табличку. Оно аффектит только одну табличку, добавляю я это поле безопасно (то есть никаких диких локов нет), обратная совместимость сохранена. В чем проблема релизить такие монолиты?
Или еще нюанс. Допустим мы добавили поле в табличку. И допустим миграция, заполняющая это поле будет отрабатывать пару часов. Как мне тут помогут микросервисы? Это же табличка принадлежащая конкретному компоненту. И в силу обратной совместимости я могу сделать эту миграцию независимо от деплоя.
Ну то есть тут больше вопрос архитектуры и процессов, нежели "микросервисы это ответ".
> теперь мы просто обязаны где-то зафиксировать способ восстанавливать ее с нуля
Наконец та жизнь начала реально давать админам по рукам и «доналить еще один сервер» стало быстро и просто, и событие типа «перезагрузили сервер и чо-то не заработало» теоретически должны уйти в прошлое, не будет «забытых» настроек и runtime костылей
Наконец та жизнь начала реально давать админам по рукам и «доналить еще один сервер» стало быстро и просто, и событие типа «перезагрузили сервер и чо-то не заработало» теоретически должны уйти в прошлое, не будет «забытых» настроек и runtime костылей
Немного вступлюсь за Kubernetes: там есть request и limit на cpu и память. Реквесты используются для размещения pod на нодах. Лимит по cpu — ограничение через cgroups. Лимит по памяти — прилетает OOM killer.
При этом не помню про blkio. Скорее всего нет. Но это из-за идеологии отсутствия локальных хранилищ.
Ещё интересны ограничения на трафик. Что-то на эту тему так же есть в k8s.
Если говорить про настройки хоста/ядра, то это тоже можно делать. Но это уже никакой не чёрный ящик.
При этом не помню про blkio. Скорее всего нет. Но это из-за идеологии отсутствия локальных хранилищ.
Ещё интересны ограничения на трафик. Что-то на эту тему так же есть в k8s.
Если говорить про настройки хоста/ядра, то это тоже можно делать. Но это уже никакой не чёрный ящик.
kubernetes естественно прокидываем лимиты в cgroups (в linux просто ничего другого нет), вот если бы он навязывал задавать лимиты (не давал запускать deployment без органичений на каждый под) — было бы совсем хорошо.
kubernetes умеет делать это с помощью limitRange, раздельно для cpu и memory:
kubernetes.io/docs/tasks/administer-cluster/memory-default-namespace
kubernetes.io/docs/tasks/administer-cluster/cpu-default-namespace
А если требуется более комлексная проверка k8s-спецификаций — то можно/нужно писать linter под свои нужды.
kubernetes.io/docs/tasks/administer-cluster/memory-default-namespace
kubernetes.io/docs/tasks/administer-cluster/cpu-default-namespace
А если требуется более комлексная проверка k8s-спецификаций — то можно/нужно писать linter под свои нужды.
И ещё можно/нужно задавать опции для kubelet'а, чтобы он знал о том, сколько доступно ресурсов ноды для нужд кластера, например:
kubelet --help 2>&1 | grep limit
...
--eviction-hard string A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. (default "memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%")
...
--system-reserved mapStringString A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi) pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none]
...
$ cat /proc/${kubelet_pid}/cmdline # мой тестовый стенд
...
--system-reserved=cpu=100m,memory=100Mi
--eviction-hard=imagefs.available<5%,memory.available<5%,nodefs.available<5%,nodefs.inodesFree<5
...
Как по мне статья годная. Как минимум интересная. Но по-моему автор упускает один момент: когда современный среднестатистический разработчик-мечтатель в своем кубернетисе или ECS столкнется с падением производительности системы, он действительно просто добавит под капот ресурсов и скорее всего не будет разбираться что там у него под капотом происходит и что там мешает его счастливой жизни. Даже если получит какой-то перебор по затратам. Но в подавляющем большинстве случаев это все равно дешевле, чем делать и поддерживать это все руками.
Вся история эволюции подходов и методов разработки и администрирования это история переходов на более высокие уровни абстракций ценой появления слишком уж большой сложности копания под капотом. Каждый следующий уровень абстракции позволяет нам решать проблему на уровне, который еще ближе к самОй проблемной области, а не заниматься дорогим и скучным низкоуровневым мазохизмом. Эта цена эволюции, и это все равно в перспективе дешевле в большинстве случаев.
P.S. AWS ECS не построен на кубернетисе в отличе от GCE. Это отдельная амазоновская система оркестрации контейнеров, которая из плюсов имеет только то, что она полностью управляется самим амазоном, и вы можете сразу начать с ней работать. Все остальное в ней по сравнению с K8s это боль имхо
Вся история эволюции подходов и методов разработки и администрирования это история переходов на более высокие уровни абстракций ценой появления слишком уж большой сложности копания под капотом. Каждый следующий уровень абстракции позволяет нам решать проблему на уровне, который еще ближе к самОй проблемной области, а не заниматься дорогим и скучным низкоуровневым мазохизмом. Эта цена эволюции, и это все равно в перспективе дешевле в большинстве случаев.
P.S. AWS ECS не построен на кубернетисе в отличе от GCE. Это отдельная амазоновская система оркестрации контейнеров, которая из плюсов имеет только то, что она полностью управляется самим амазоном, и вы можете сразу начать с ней работать. Все остальное в ней по сравнению с K8s это боль имхо
Верно подмечено.
Хотелось бы еще добавить, что контейнеры это классно, но сейчас все стремятся в AWS Lambda / Google Functions. И с ними вся головная боль контейнеров — на совести провайдеров. И с затратами все норм. Ну а если без контейнеров никак, то у амазона, например есть сервис Fargate, который позволяет арендовать контейнер, а не ес2 инстанс, напрямую. Т.е. ECS без головной боли.
Так что все движется в правильном направлении.
Хотелось бы еще добавить, что контейнеры это классно, но сейчас все стремятся в AWS Lambda / Google Functions. И с ними вся головная боль контейнеров — на совести провайдеров. И с затратами все норм. Ну а если без контейнеров никак, то у амазона, например есть сервис Fargate, который позволяет арендовать контейнер, а не ес2 инстанс, напрямую. Т.е. ECS без головной боли.
Так что все движется в правильном направлении.
Так и не понял, какие выводы из статьи. И да, DevOps — это не про производительность.
Выводы из статьи — высокооплачиваемый девопс легко может залипнуть на пару дней — неделю и получить выгоду… ну может 50баксов в месяц.
Где расчеты эффективности вашего залипания? Что в результате получила компания?
А вообще докер это класно, а потом упираемся в производительность чегото еще класного(типа rabbitmq) и приходится убирать докер, чтоб получить нужные 10-20% разницы на немаштабируемых участках(которые с завидной периодичностью почемуто появляются).
Та же база в докере на nvme — работает отвратительно.
Где расчеты эффективности вашего залипания? Что в результате получила компания?
А вообще докер это класно, а потом упираемся в производительность чегото еще класного(типа rabbitmq) и приходится убирать докер, чтоб получить нужные 10-20% разницы на немаштабируемых участках(которые с завидной периодичностью почемуто появляются).
Та же база в докере на nvme — работает отвратительно.
Высокооплачиваемый девопс может делать в рабочее время что угодно, если он при этом сможет обеспечить бизнесу работу сервиса с нужным SLA. У многих компаний это стабильно-низкое время ответа, например <100ms на запрос. Вот для таких случаев нужно очень хорошо ориентироваться в самом низком уровне.
Дочитал до тюнинга «scaling_governor» как решения и бросил. Не уверен как остальным читателям, но мне вот именно этот момент и показал проблему DevOps. ОС на сервере настроена как для desktop/laptop, и вы пытаетесь на этом показать производительность production? Смешно. Вот этот как раз и есть настоящая беда, когда люди рвутся везде использовать новейшие buzzword'ы, но при этом не знают как еще настроить сервер для production.
Не соглашусь с вами. "scaling_governor" в этом случае был не тюнинг, а объяснение конкретной аномалии на гистограмме. Не менее важно, что проблема была обнаружена по конкретным показателям (perf), после чего сразу было понятно, что и как нужно исправить. Поверьте, я достаточно много собеседовал админов и наслушался, как правильно настраивать серверы в production:) При этом человек естественно не понимал, что он крутит и зачем.
Это я к тому что при нормальной установке Linux на сервер соответствующие пакеты которые бы добавили соответствующие модули ядра (cpufrequtils на Debian, например) не установлены по-умолчанию, а это означает что ваши тесты были проведены, мягко говоря, не в совсем корректном окружении. Я так же собеседовал и собеседую людей на различные роли. И все рвутся мне рассказать как же правильно настроить kubernetes, хотя когда их спрашиваешь банальные вещи (как работает swap, разница между статической и динамической линковкой, для чего используется strace и мой любимый — как работает OOM) смотрят на меня «глазами полными ужаса»
Вся эта статья отталкивается от неоспоримой базы, что DevOps — это микро-сервисы. С какого фаллоса?
Я, конечно, восхищаюсь трудолюбием автора — написать такую объемную и аккуратную статью стоило ему труда. Но может было бы рациональнее пустить эти ресурсы на изучение термина DevOps и его смысловой нагрузки?
Я, конечно, восхищаюсь трудолюбием автора — написать такую объемную и аккуратную статью стоило ему труда. Но может было бы рациональнее пустить эти ресурсы на изучение термина DevOps и его смысловой нагрузки?
Ну раз ты такой умный — мы с удовольствием послушаем твое объяснение
- Я не говорил, что я умный
- Я не считаю уместным обсуждать здесь мою или чью-бы то ни было личность и интеллектуальные способности
- Чтобы я ни думал о DevOps, это не меняет факта того, что это не микро-сервисы
- Статья на Wiki содержит вполне исчерпывающую информацию на эту тему, чтобы осознать примитивность определения «DevOps=microservices»
UFO just landed and posted this here
А я почему-то думал диаметрально противоположным образом — что это хитрый план админов по перекладыванию части своей работы на разработчиков.
Вы оба не правы.
Админы со знанием DevOpv автоматически могут рассчитывать на зарплату в 1.5-3 раза больше, чем обычные админы.
Потому совершенно очевидно чей именно это хитрый план и с какими целями.
UFO just landed and posted this here
У вас так:
У меня так:
Для разработчиков знание технологии DevOps — уже скоро будет считаться базовым навыком, посему для разработчиков нет такого высокого коэффициента к зарплате.
А вот для админа — это знание означает переход на другую квалификационную ступеньку.
Разработчики со знанием DevOpv...
У меня так:
Админы со знанием DevOpv…
Для разработчиков знание технологии DevOps — уже скоро будет считаться базовым навыком, посему для разработчиков нет такого высокого коэффициента к зарплате.
А вот для админа — это знание означает переход на другую квалификационную ступеньку.
UFO just landed and posted this here
У меня например сведения совсем-совсем другие… Полностью ортогональные вашим.
Яснее пожалуйста.
Что касается того, где это будет являться базовым навыком… лично я считаю, что базовым навыком это должно являться именно у всевозможных администраторов.
От разработчиков требуются минимальные навыки.
Умение пушить корректно в git (иногда с тегами и т.п.)
Умение написать Dockerfile под свое приложение да работать с docker-compose.
Умение нормальный vendoring использовать.
И т.п. мелочи.
Это все шире и шире используют и при разработке «в одного»
У админов разделение все же шире.
Хорошо описано чем отличаются админы тут по соседству:
habrahabr.ru/company/okmeter/blog/349610/#comment_10683060
И если в предыдущей парадигме «старый добрый админ» является специалистом по настройке железа и сервисного ПО, а разработчик выдает код, который должен работать в этом конкретном окружении, то в новой парадигме, где разработчик отдаёт «код и описание окружения для его работы», потребовались «другие специалисты», которые будут принимать и обслуживать эти «контейнеры». Совершенно другие навыки, совершенно другой набор инструментов.
DevOps принципиально меняет мир с точки зрения администрирования.
Но слабо с точки зрения разработчиков — ну, среда отладки приближена к среде production. Это же хорошо, меньше багов.
От разработчиков требуются минимальные навыки.
Так как разработчики в системе DevOps являются, хоть квалифицированными, но именно что пользователями.
А админы — должны настроить для пользователей-разработчиков и поддерживать хозяйство.
Другое дело, что таких админов нужно меньше чем разработчиков.
Но мы же говорим о зарплате на 1 человека, а не об фонде оплаты труда (зарплата на 1 человека * количество потребных людей).
Раньше production окружение выглядело примерно так
монолитное приложение, работающее в гордом одиночестве на сервере или виртуалке
До появления более-менее приемлемой контейнерезации, которую можно применять в продакшн, перед разработчиками часто стояла непреодолимая стена в виде уже используемых технологий в монолите. И чем объемнее был монолит, тем более железобенной была эта стена.
Использование даже просто обновленной версии какой-либо библиотеки натыкалось на то, что нужно адское количество ресурсов (особенно в железе) затратить на то, чтобы поднять обновленный продакшен без даунтайма. А иметь равноценную продакшену тестовую среду — это была очень большая роскошь.
Микросервисы, но главным образом контейнеризация приложений, решила эту проблему. Разработчик теперь отдаёт приложение с готовым описанием окружения, в котором это приложение как разрабатывается, так и эксплуатируется. А раз разработчик стал давать другой продукт на выходе, то потребовались «другие люди» для работы с этим другим продуктом.
И если в предыдущей парадигме «старый добрый админ» является специалистом по настройке железа и сервисного ПО, а разработчик выдает код, который должен работать в этом конкретном окружении, то в новой парадигме, где разработчик отдаёт «код и описание окружения для его работы», потребовались «другие специалисты», которые будут принимать и обслуживать эти «контейнеры». Совершенно другие навыки, совершенно другой набор инструментов.
И попробовав раз, понимаешь, что мир ИТ эволюционировал. И прошлым мастадонтам уготован лишь очень небольшой и чисто функциональный кусок по поднятию общей облачной инфраструктуры. А на сцене начинают доминировать совершенно другие технологии и навыки. На сцене, для которой вопрос о том, какую выбрать ос для сервера (порождавшем ожесточенные споры), выглядить далеко не первостепенным, если не вообще существенным.
На сцене, для которой вопрос о том, какую выбрать ос для сервера (порождавшем ожесточенные споры), выглядить далеко не первостепенным, если не вообще существенным.
Когда же ОС вообще умрут?
Контейнеры все же используют ядро ОС. А вот когда совсем…
Справедливости ради, каждый человек разбирающийся в докере, с которым я общался, возводил глаза к нему в немом горе при фразе «windows контейнеры». Так что как правило, выбор ОС все же неплохо определяется контейнерами. Другой вопрос, что даже для C# разработчика уже не так очевидно, под какой ОС будет работать его программа.
На КДПВ чернокожие товарищи не поддерживают контейнер — они держаться за него. Что как бы намекает, что и заголовок статьи спорный.
Sign up to leave a comment.
DevOps придумали разработчики, чтобы админы больше работали