Article: Platform-as-a-Product: Declarative Infrastructure for Developer Velocity
Declarative infrastructure config hides complexity, enabling developers to focus on application code. Unified YAML per service allows early cost validation, while independent CI with centralized CD balances team autonomy and deployment consistency. This standardized approach scales across organizations, making infrastructure invisible and operations automatic.
By Avinash Sabat
Read: https://www.infoq.com/articles/platform-golden-path-approach/
@devo_pes | Другие наши каналы
Declarative infrastructure config hides complexity, enabling developers to focus on application code. Unified YAML per service allows early cost validation, while independent CI with centralized CD balances team autonomy and deployment consistency. This standardized approach scales across organizations, making infrastructure invisible and operations automatic.
By Avinash Sabat
Read: https://www.infoq.com/articles/platform-golden-path-approach/
@devo_pes | Другие наши каналы
В NGINX появилась встроенная поддержка ACME — теперь HTTPS настраивается без Certbot и лишних утилит
NGINX получил встроенную поддержку ACME, позволяющую автоматически выпускать и обновлять HTTPS-сертификаты без сторонних утилит
Читать: «В NGINX появилась встроенная поддержка ACME — теперь HTTPS настраивается без Certbot и лишних утилит»
#ru
@devo_pes | Другие наши каналы
NGINX получил встроенную поддержку ACME, позволяющую автоматически выпускать и обновлять HTTPS-сертификаты без сторонних утилит
Читать: «В NGINX появилась встроенная поддержка ACME — теперь HTTPS настраивается без Certbot и лишних утилит»
#ru
@devo_pes | Другие наши каналы
👍2✍1
«Нам нужен Kubernetes 2.0»: инженер предложил переосмысление всей платформы
Инженер предложил Kubernetes 2.0: меньше YAML, новый пакетный менеджер, IPv6 по умолчанию и модульное хранилище вместо etcd
Читать: ««Нам нужен Kubernetes 2.0»: инженер предложил переосмысление всей платформы»
#ru
@devo_pes | Другие наши каналы
Инженер предложил Kubernetes 2.0: меньше YAML, новый пакетный менеджер, IPv6 по умолчанию и модульное хранилище вместо etcd
Читать: ««Нам нужен Kubernetes 2.0»: инженер предложил переосмысление всей платформы»
#ru
@devo_pes | Другие наши каналы
n8n: установка, настройка и интеграция с Python, Node.JS и PHP
Подробный туториал по установке и настройки n8n. Примеры интеграции с Python, Node.JS и PHP и взаимодействия с LLM Mistral AI.
Читать: «n8n: установка, настройка и интеграция с Python, Node.JS и PHP»
#ru
@devo_pes | Другие наши каналы
Подробный туториал по установке и настройки n8n. Примеры интеграции с Python, Node.JS и PHP и взаимодействия с LLM Mistral AI.
Читать: «n8n: установка, настройка и интеграция с Python, Node.JS и PHP»
#ru
@devo_pes | Другие наши каналы
werf как альтернатива Kaniko для сборки образов в Kubernetes в вашей системе CI
Публичный репозиторий Kaniko перевели в архив — теперь он доступен только для чтения. Изучили подобные инструменты и выбрали больше, чем просто альтернативу. Рассказываем, чем уникальна утилита werf и почему её стоит попробовать.
Читать: «werf как альтернатива Kaniko для сборки образов в Kubernetes в вашей системе CI»
#ru
@devo_pes | Другие наши каналы
Публичный репозиторий Kaniko перевели в архив — теперь он доступен только для чтения. Изучили подобные инструменты и выбрали больше, чем просто альтернативу. Рассказываем, чем уникальна утилита werf и почему её стоит попробовать.
Читать: «werf как альтернатива Kaniko для сборки образов в Kubernetes в вашей системе CI»
#ru
@devo_pes | Другие наши каналы
«SQL хорош для данных, но плох для логики» — почему все больше разработчиков выносят бизнес-логику из базы
SQL отлично справляется с данными, но неудобен для бизнес-логики: разработчики выносят её в код ради гибкости, скорости и независимости
Читать: ««SQL хорош для данных, но плох для логики» — почему все больше разработчиков выносят бизнес-логику из базы»
#ru
@devo_pes | Другие наши каналы
SQL отлично справляется с данными, но неудобен для бизнес-логики: разработчики выносят её в код ради гибкости, скорости и независимости
Читать: ««SQL хорош для данных, но плох для логики» — почему все больше разработчиков выносят бизнес-логику из базы»
#ru
@devo_pes | Другие наши каналы
Forwarded from Типичный программист
Что такое импортозамещение на практике? Это сборка инфраструктурного пазла из кусочков разных вендоров, которые с трудом мэтчатся друг с другом. Другими словами — головная боль.
На помощь российским компаниям пришел ПАК виртуализации, где и аппаратная, и программная части созданы, производятся и сопровождаются одной компанией. И о нем наш пятничный кейс.
У команды получилось решение, где архитектура изначально спроектирована так, что добавление нового сервера автоматически увеличивает и вычислительную мощность, и объём хранилища, и отказоустойчивость.
А мы уже ушли серчить следующий кейс 👀
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Типичный программист
Когда конференции превращаются в дорогие маркетинговые шоу, где найти место для чистого обмена опытом?
В комьюнити, которое создается профессионалами для профессионалов. В этой истории команда из 10 человек за 3 месяца создала то, чего не хватало сообществу — бесплатную, независимую техническую конференцию для K8s-сообщества.
Так возник Kuber Community Day, в котором сообщество продолжило жить после финального доклада.
Продолжаем отыскивать любопытные артефакты. Вечером будут уже знакомые ребята, но с новым кейсом. Узнаете в 19 часов!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Типичный программист
Артефакт №5. Категория: «Мониторинг»
Мониторинг сотен серверов и рабочих станций обычно означает агентов на каждом устройстве, лаги в данных и десяток разных консолей. А если обойтись без этого, получать данные в реальном времени и управлять всем из одного интерфейса?
Нужна система, которая дает полную observability через стандартные интерфейсы управления, и она есть у нас. Она подключается к оборудованию по протоколам — Redfish, IPMI, SNMP, Prometheus — и не требует установки софта на целевые хосты.
🤩 Техническая сторона артефакта 🤩
🤩 Отказ от агентов.
🤩 Данные в реальном времени.
🤩 Гибкие алерты на PromQL вместо примитивных пороговых значений.
🤩 KVM через браузер с обходом ограничений CORS для прямого доступа к консоли сервера на аппаратном уровне.
Что скрывает этот артефакт?
Лучше читайте сами.
Ваши предположения, какой будет тематика следующего артефакта?
Мониторинг сотен серверов и рабочих станций обычно означает агентов на каждом устройстве, лаги в данных и десяток разных консолей. А если обойтись без этого, получать данные в реальном времени и управлять всем из одного интерфейса?
Нужна система, которая дает полную observability через стандартные интерфейсы управления, и она есть у нас. Она подключается к оборудованию по протоколам — Redfish, IPMI, SNMP, Prometheus — и не требует установки софта на целевые хосты.
Что скрывает этот артефакт?
Лучше читайте сами.
Ваши предположения, какой будет тематика следующего артефакта?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Типичный программист
Победителями премии Тпрогер 🐀 становятся...
Здесь играет барабанная дробь и интригующая музыка... Вам нужно только выждать драматическую паузу перед объявлением победителей — в каждой номинации он один, и определяется большинством голосов. Готовы?
В номинации «Продукт года» золотая мышь достается компании:
🐀 NetVision за платформу интеллектуального мониторинга СИМ .
В номинации «Облачный продукт года» побеждает компания:
🐀 Гравитон с паком виртуализации «Гелиус»
Звание «IT-ивент года» вручается компании:
🐀 Островок! за О!Хакатон
И в категории «Дизайн года» первое место занимает компания:
🐀 AcademiaDev за интерактивную инсталляцию .
Каждый ваш лайк, голос влияли на исход премии. Давайте поддержим всех — ставьте 🏆участникам, которые хоть и не заняли призового места, но точно остались в сердечке.
И 🔥, если хотите аналогичных активностей и готовы выбирать еще!
Здесь играет барабанная дробь и интригующая музыка... Вам нужно только выждать драматическую паузу перед объявлением победителей — в каждой номинации он один, и определяется большинством голосов. Готовы?
В номинации «Продукт года» золотая мышь достается компании:
В номинации «Облачный продукт года» побеждает компания:
Звание «IT-ивент года» вручается компании:
И в категории «Дизайн года» первое место занимает компания:
Каждый ваш лайк, голос влияли на исход премии. Давайте поддержим всех — ставьте 🏆участникам, которые хоть и не заняли призового места, но точно остались в сердечке.
И 🔥, если хотите аналогичных активностей и готовы выбирать еще!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Что сейчас происходит в сфере антифрода
К 2026 году мошенники тоже освоили генеративный ИИ. Вместо физических подделок они синтезируют изображения на основе утекших данных пользователей, заваливая банки тысячами фальшивых документов разного качества, авось прокатит. И в ряде случаев действительно прокатывает, потому что системы защиты тоже несовершенны.
Рынок пытается справиться с этими бедами: у нас на сайте вышел емкий разбор современных трендов антифрода. В статье разбирают, как эволюционировали подделки документов, из-за чего тормозится разработка средств защиты, а также какие модели считаются одними из самых прогрессивных.
Если хотите чек-лист антифрода 2026, вам сюда: https://tprg.ru/NCku
К 2026 году мошенники тоже освоили генеративный ИИ. Вместо физических подделок они синтезируют изображения на основе утекших данных пользователей, заваливая банки тысячами фальшивых документов разного качества, авось прокатит. И в ряде случаев действительно прокатывает, потому что системы защиты тоже несовершенны.
Рынок пытается справиться с этими бедами: у нас на сайте вышел емкий разбор современных трендов антифрода. В статье разбирают, как эволюционировали подделки документов, из-за чего тормозится разработка средств защиты, а также какие модели считаются одними из самых прогрессивных.
Если хотите чек-лист антифрода 2026, вам сюда: https://tprg.ru/NCku
Как ML помогает тестировать то, что нельзя предсказать вручную?
В новом материале — кейс о том, как спроектировать систему динамической генерации тестовых сценариев для транспортного проекта. За основу взято имитационное моделирование с элементами ML.
В статье подробное описание архитектуры решения:
— пайплайн из Great Expectations, Evidently AI, DVC и Airflow;
— три слоя данных: продовые срезы, обезличенные профили и «мутации» аномалий от ML;
— а еще швейцарский сыр.
Как он там оказался, читайте в статье.
В новом материале — кейс о том, как спроектировать систему динамической генерации тестовых сценариев для транспортного проекта. За основу взято имитационное моделирование с элементами ML.
В статье подробное описание архитектуры решения:
— пайплайн из Great Expectations, Evidently AI, DVC и Airflow;
— три слоя данных: продовые срезы, обезличенные профили и «мутации» аномалий от ML;
— а еще швейцарский сыр.
Как он там оказался, читайте в статье.
Реддитор проанализировал 1.6 миллиона Git-событий и показал, как бесконтрольное использование ИИ в разработке ломает привычные процессы и замедляет поставку продукта.
Основные выводы:
— ИИ увеличивает общий объем написанного кода примерно на 55%.
— Без расширения штата QA чистая скорость доставки падает до 0,85 от изначальной, то есть команда работает медленнее, чем до внедрения ИИ.
— Добавление всего одного выделенного тестировщика возвращает скорость к отметке 1,32 с окупаемостью 18 к 1.
— Юнит-тесты показали самую низкую эффективность, так как ИИ часто просто переписывает их под свои же баги.
Математическая модель автора показывает, что качество любого этапа проверки падает экспоненциально при росте объема кода. Когда на ревьюера сваливается постоянный поток пулл-реквестов, вдумчивая проверка быстро сменяется автоматическим одобрением, что в комментариях метко назвали ✨вероятностным продакшеном✨.
Проблема сильно усугубляется отложенным эффектом. На первых этапах менеджмент видит только рост числа слитых веток и считает внедрение успешным, пока баги незаметно накапливаются в системе. Со временем исправление ошибок начинает отнимать абсолютно все ресурсы разработчиков, и проект сталкивается с серьезными сбоями под нагрузкой.
Один из комментаторов поделился рабочим решением:
— Сделать CI-пайплайн первым и главным ревьюером.
— Внедрить property-based тесты и мутационное тестирование на критичных участках.
— Добавить строгий статический анализ, который автоматически отклоняет пулл-реквесты со слишком большим охватом изменений.
Такой подход отсеивает большую часть проблемного ИИ-кода до того, как он попадет к живому человеку. В результате объем ручной проверки снижается примерно на 60%, что позволяет ревьюерам сохранить фокус на сложной бизнес-логике и спасает от выгорания.
Ссылка на обсуждение: https://www.reddit.com/r/devops/comments/1rrrj0v/i_analyzed_16m_git_events_to_measure_what_happens/
Само исследование с воспроизводимыми скриптами: https://zenodo.org/records/18971198
Основные выводы:
— ИИ увеличивает общий объем написанного кода примерно на 55%.
— Без расширения штата QA чистая скорость доставки падает до 0,85 от изначальной, то есть команда работает медленнее, чем до внедрения ИИ.
— Добавление всего одного выделенного тестировщика возвращает скорость к отметке 1,32 с окупаемостью 18 к 1.
— Юнит-тесты показали самую низкую эффективность, так как ИИ часто просто переписывает их под свои же баги.
Математическая модель автора показывает, что качество любого этапа проверки падает экспоненциально при росте объема кода. Когда на ревьюера сваливается постоянный поток пулл-реквестов, вдумчивая проверка быстро сменяется автоматическим одобрением, что в комментариях метко назвали ✨вероятностным продакшеном✨.
Проблема сильно усугубляется отложенным эффектом. На первых этапах менеджмент видит только рост числа слитых веток и считает внедрение успешным, пока баги незаметно накапливаются в системе. Со временем исправление ошибок начинает отнимать абсолютно все ресурсы разработчиков, и проект сталкивается с серьезными сбоями под нагрузкой.
Один из комментаторов поделился рабочим решением:
— Сделать CI-пайплайн первым и главным ревьюером.
— Внедрить property-based тесты и мутационное тестирование на критичных участках.
— Добавить строгий статический анализ, который автоматически отклоняет пулл-реквесты со слишком большим охватом изменений.
Такой подход отсеивает большую часть проблемного ИИ-кода до того, как он попадет к живому человеку. В результате объем ручной проверки снижается примерно на 60%, что позволяет ревьюерам сохранить фокус на сложной бизнес-логике и спасает от выгорания.
Ссылка на обсуждение: https://www.reddit.com/r/devops/comments/1rrrj0v/i_analyzed_16m_git_events_to_measure_what_happens/
Само исследование с воспроизводимыми скриптами: https://zenodo.org/records/18971198
❤1👍1🔥1
Оказывается, людей всё ещё просят инвертировать бинарные деревья на доске при найме на позиции DevOps или Platform Engineer. Видимо, мы в 2026 должны уметь поисковики с нуля писать. Хотя куда показательнее попросить написать скрипт для парсинга логов или сортировки тысяч файлов в S3 по бакетам.
Уважаемые HR и нанимающие менеджеры, если хочется проверить экспертизу, обсуждайте архитектуру и траблшутинг:
— Базовые принципы CAMS
— Метрики DORA вроде Deployment Frequency и Change Failure Rate
— Понимание подкапотной магии Ansible, Jenkins и Helm
— Практичные паттерны: GitOps, Policy-as-code, стратегии релизов
И вообще, в моём мире адекватное техническое интервью больше похоже на совместный разбор инцидента, а не на экзамен по академическому Computer Science.
Уважаемые HR и нанимающие менеджеры, если хочется проверить экспертизу, обсуждайте архитектуру и траблшутинг:
— Базовые принципы CAMS
— Метрики DORA вроде Deployment Frequency и Change Failure Rate
— Понимание подкапотной магии Ansible, Jenkins и Helm
— Практичные паттерны: GitOps, Policy-as-code, стратегии релизов
И вообще, в моём мире адекватное техническое интервью больше похоже на совместный разбор инцидента, а не на экзамен по академическому Computer Science.
💯4🤔1
Тут снова всплыла та самая статья про исход из облаков от создателя Ruby on Rails. Если не читали, основная мысль сводится к тому, что для компаний среднего размера со стабильным ростом аренда чужих серверов обходится неоправданно дорого.
По логике Дэвида облако незаменимо только в двух случаях:
— либо ты делаешь стартап с нулевой базой и тебе критически важна скорость запуска без возни с инфраструктурой;
— либо у тебя случаются дикие непредсказуемые скачки нагрузки, как у них было на старте HEY с наплывом сотен тысяч пользователей.
В остальных ситуациях компания просто оплачивает маржинальность провайдера в районе тридцати процентов, покупая «страховку от землетрясения» в регионе, где их никогда не бывает, и продолжает поддерживать штат своих инженеров.
Дак вот, статья продолжает всплывать на протяжении 3+ лет, потому что проблемы-то никуда не делись. Конечно, никто не хоронит облака окончательно, но как будто бы иллюзия того, что передача инфраструктуры на аутсорс решит все технические проблемы, развеивается для всё большего количества людей.
По логике Дэвида облако незаменимо только в двух случаях:
— либо ты делаешь стартап с нулевой базой и тебе критически важна скорость запуска без возни с инфраструктурой;
— либо у тебя случаются дикие непредсказуемые скачки нагрузки, как у них было на старте HEY с наплывом сотен тысяч пользователей.
В остальных ситуациях компания просто оплачивает маржинальность провайдера в районе тридцати процентов, покупая «страховку от землетрясения» в регионе, где их никогда не бывает, и продолжает поддерживать штат своих инженеров.
Дак вот, статья продолжает всплывать на протяжении 3+ лет, потому что проблемы-то никуда не делись. Конечно, никто не хоронит облака окончательно, но как будто бы иллюзия того, что передача инфраструктуры на аутсорс решит все технические проблемы, развеивается для всё большего количества людей.
Hey
Why we're leaving the cloud
Basecamp has had one foot in the cloud for well over a decade, and HEY has been running there exclusively since it was launched two years ago. We've run extensively in both Amazon's cloud and Google's cloud. We've run on bare virtual machines, we've run on…
❤2🆒1
Линуксоид с гигантским стажем решил волевым усилием поломать свои привычки и заменить coreutils на фэнси тулзы. В комментарии набежали холиварить про надёжность vs эргономичность, но сначала вот пять замен, которые коллективно сочли достойными:
Дальше на ночь пятничная сказка про холивар.
Базовый набор GNU coreutils создавался в эпоху, когда деревья в файловых системах были маленькими,а ресурсов не хватало ни на что лишнее. Синтаксис классического find до сих пор вызывает нервный тик, а чтение логов через cat без подсветки пора признать формой легкого мазохизма. Современный подход предлагает инструменты, которые написаны преимущественно на Rust и делают ровно то же самое, но с человеческим лицом. А ещё они работают быстрее и прямо из коробки понимают правила .gitignore.
В подобных обсуждениях всегда появляется Суровый Системный Администратор Старой Школы и настаивает, что все эти цветастые игрушки абсолютно бесполезны при заходе по SSH на боевой сервер. Там тебя встретит голый bash и девственно чистый vi. В ответ на это в него кидаются терраформами и ансиблами и спрашивают, а зачем мол вообще в наше время ходить на продакшен по ssh?
cat → bat ибо встроенная подсветка синтаксиса, нумерация строк и адекватный пейджинг;ls → eza, потому что позволь себе уже полюбить цветовое кодирование и иконки;find → fd за интуитивный синтаксис и быструю выдачу;grep → ripgrep опять же из-за скорости;top → btop для комплексного мониторинга ресурсов, хоть btop и перегружен визуально.Дальше на ночь пятничная сказка про холивар.
Базовый набор GNU coreutils создавался в эпоху, когда деревья в файловых системах были маленькими,
В подобных обсуждениях всегда появляется Суровый Системный Администратор Старой Школы и настаивает, что все эти цветастые игрушки абсолютно бесполезны при заходе по SSH на боевой сервер. Там тебя встретит голый bash и девственно чистый vi. В ответ на это в него кидаются терраформами и ансиблами и спрашивают, а зачем мол вообще в наше время ходить на продакшен по ssh?
Пожалуй, единственное здравое правило, которое можно вынести из этого противостояния: как только дело доходит до автоматизации и bash-скриптов, надо возвращаться к POSIX-совместимым конструкциям и классическим coreutils, иначе автоматизация сломается на первой же машине.
❤10