Как это с шифрованием трафика связано? И с проверкой того, что трафик пришел от того же домена, который указан в адресной строке?
Проблемы скама это совершенно никак не транспортный уровень. Многие браузеры реализуют предупреждения о том, что данный сайт "плохой", а яндекс браузер (насколько читал) прям какой-то серьезный инструмент для этого реализовал. Ставьте своим пользователям пожилого возраста яндеск браузер или поставьте фаервол с фильтрацией по белым спискам, но при чем тут сертификаты их валидация?
Это как пытаться решить проблему вопровства тем, что не выдавать ворам паспорт, чтобы они не могли на него симку зарегистрировать. Вот только нужно как-то понять, что человек вор, на момент выдачи паспорта - но это же не наша проблема, правда?
Интересно было бы почитать, как с технической точки зрения это было реализовано "с нуля" + нюансы законодательств и платежных систем, через которые пришлось пройти.
Обучение этих людей идёт туго, ведь ИТ с высокими зарплатами так разрекламировано, что учиться эти люди не особо стремятся, им интересные проекты подавай и чтобы всё с нуля, чтобы распоследние технологии.
Ну такое всегда было и всегда будет. Есть просто разные люди: кто-то самостоятелен и замотивирован, кто-то нет. В итоге и карьера у них складывается по-разному.
В остальном не увидел принципиальных разногласий с моими аргументами. Начинающие разработчики знают недостаточно и поверхностно, вне зависимости от инфраструктуры. Опытные инженеры знают глубоко и широко, опять же, вне зависимости от инфраструктуры.
Отличие одно - уровень работы с инфраструктуры становится все выше и выше (от голого железа до условных "функций" или вообще какого-то декларативного кода). Уровень поднимается за счет появления новых абстракций - ОС, контейнеры, оркестратоты, сервисмеши и т.п.
Сначала они неустойчивые и сложные, потом обрастают сообществом, становятся лучше и надежнее, и со временем переходят в разряд стандартов. И уже поверх них начинают пилиться новые ненадежные абстракции. Кубер уже перешел в категорию стандартов, сервисмеши пока в пути, прочие навороты пока только на горизонте.
---
Кстати, это очень хорошо можно увидеть, посмотрев InfoQ Trends Report, в котором очень четко видно, как с годами технологии переходят из разряда новых идей в разряд корпоративных стандартов.
те самые дорогущие программисты всё меньше понимают, как эта балалайка работает
И не должны понимать, в этом и смысл изменений. Когда-то программист должен был понимать, как программировать под конкретное железо, пока не появился POSIX с набором сисколов. Потом появились более высокоуровневые ЯП, которые и работу с сисколами заменили абстракциями. Все это делается ради того, чтобы программист мог больше своего времени тратить на реализацию бизнес-логики и меньше - на интеграцию в конкретную инфраструктуру.
Понимает ли программист, как работает сискол под капотом? Если да, то не каджый. Надо ли ему это? Если не пишет дрова или микроконтроллеры - нет.
То же самое и с кубом. Сейчас подавляющее большинство Go, Java и еще что там разработчиков приходит на собеседования со знанием контейнеров, докера, кубера, пониманием CI/CD и прочего. Это тот уровень абстракции, на котором работает сегодняшний программист (ну скажем, 80% программистов). Завтрашний работает на уровне примитивов Istio и Knative, послезавтрашний - на основе примитивов девелопера в рамках ролевой модели Dapr.
Плохо ли это? Да в общем нет - компании не нужно, чтобы все знали обо всем. Достаточно нанять пару "экспертов в технологии X (например DevOps для технологии Kubernetes), которые и будут решать задачи, где нужно знание "как эта балалайка работает". Остальные же будут работать с абстракциями, позволяющими деливерить продукты быстрее и лучше. И масштабировать обычно нужно команду разработчиков, а не "экспертов в X", а проще масштабировать команду людей, умеющих работать поверх абстракции, нежели экспертов в узкой области.
В итоге на вхождение человека в проект тратятся месяцы
Докер и кубер создали общую абстракцию, за которую убрано очень много инфраструктурных нюансов - ОС, диск, сеть, логирование и скейлинг, перезапуск умерших сервисов и так далее. Это приводит к тому, что отдельному разработчику не нужно париться над этими задачами и выдумывать велосипеды/использовать зоопарк библиотек для их решения. То есть область, в которой работает разработчик, сужается до фактически написания бизнес-логики, остальное улетает за абстракции.
Это приводит к тому, что люди приходят с хорошим знанием одной общей абстракции (докер, куб, деплоймент, сервис, блю/грин, стейтфулсет), и эта абстракция примерно одна и та же от компании к компании. Нюансы конечно есть, но например поработав в одной компании с Nginx в качестве ingress, а в другой с Istio в том же качестве, разницы в коде приложения я никакого не увидел.
У каждого проекта свой набор свистелок
Такие решения как раз позволяют иметь меньше "свистелок" в проекте. Условный Dapr абстрагирует pub/sub и key-value за единый интерфейс. Нужно асинхронно слать эвент - берешь dapr pub/sub api, нужно закешировать данные - берешь dapr kv api. Решение требует минут вместо часов и дней, как было раньше, и въехать в код приложения быстрее и проще. А что там за имплементация pub/sub и key-value уже будет самый опытный инженер в команде думать, исходя из требований проекта.
но то количество знаний, что необходимо держать в голове с трудом туда помещается
Знаний, которые нужно держать в голове архитектору/техлиду, всегда было много, просто одни устаревают, а другие появляются. От этого никуда не уйти.
Знаний же в головах начинающих инженеров нужно даже меньше, чем раньше - уметь писать на своем ЯП, понимать особенности работы в контейнере (стейтлесс, грейсфул шатдаун, параллельная работа нескольких реплик), ну и неизменные вещи вроде ACID транзакций и лучших практик программирования.
Прошу простить за простыню текста, хотелось ответить подробно и с примерами.
Ничего необычного, железо дешевеет, разработка дорожает. Все идет по пути упрощения написания программ с момента возникновения программирования. Kubernetes был просто очередным шагом, Service Mesh - следующий шаг, а Knative и Dapr - уже следующий шаг.
Что-то следующее будет уже внутри них реализовано, например какой-нибудь хитрый акторный распределенный фреймворк, общающийся через брокера и работающий с KV. Возможно, описывать программу на этом шаге станет можно на декларативном ЯП, к чему все давно идет.
При всех минусах, в системах мониторинга сотрудников есть один неоспоримый плюс: увидев такую систему на испытательном (а в идеале еще до подписания договора) можно с уверенностью идти к другому работодателю.
Спасибо за статью. Сам испытываю проблемы с обработкой ошибочных сообщений из кафки, хотел прикрутить retry topic. У меня ситуация немного другая — кафка используется для асинхронного request-reply, т.е. есть, куда ответить об ошибке. Но с "плохими" сообщениями это дела не меняет.
Описанный подход выглядит логичным решением проблемы, разве что нужен механизм повторной публикации сообщений из отстойника.
Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?
В том же GCP, насколько знаю, биллинговые данные попадают в bigquery, оттуда можно как-то мониторить. Ну и тот же cloud pub/sub с уведомлениями — но опять же, насколько вовремя они туда попадают?
Вообще выглядит все так (особенно после прочтения статьи по ссылке) не стоит пользоваться сервисами, у которых возможности явно указать верхний лимит по апскейлу (если вы не мегакорпорация, которая готова платить миллионы за обработку скачкообразной нагрузки).
Те же кубы и виртуалки вполне себе легко посчитать + явно задаются лимиты автоскейлинга. А вот эти модно-молодежные лямбды и фаербейзы — работа "по волшебству" имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.
"избранные комментарии" - формат, которого мне так не хватало на хабре.
Просто "гибкий".
эй, Петя, вы по гибкому работаете?
не, у нас водопад!
Как это с шифрованием трафика связано? И с проверкой того, что трафик пришел от того же домена, который указан в адресной строке?
Проблемы скама это совершенно никак не транспортный уровень. Многие браузеры реализуют предупреждения о том, что данный сайт "плохой", а яндекс браузер (насколько читал) прям какой-то серьезный инструмент для этого реализовал. Ставьте своим пользователям пожилого возраста яндеск браузер или поставьте фаервол с фильтрацией по белым спискам, но при чем тут сертификаты их валидация?
Это как пытаться решить проблему вопровства тем, что не выдавать ворам паспорт, чтобы они не могли на него симку зарегистрировать. Вот только нужно как-то понять, что человек вор, на момент выдачи паспорта - но это же не наша проблема, правда?
Просто ощущения при печати более приятные, особенно, когда нужно много печатать. Ну и звук приятный.
Это пересказ выпуска "запуск завтра"?
Выглядит супер!
Так менеджеры это самые большие работяги - вы бы хоть конфлюенс открыли, прежде чем такое говотить!
Да, релиз запланирован на 13 августа. Но мы то знаем...
Мои поздравления, конечно.
Интересно было бы почитать, как с технической точки зрения это было реализовано "с нуля" + нюансы законодательств и платежных систем, через которые пришлось пройти.
Ну такое всегда было и всегда будет. Есть просто разные люди: кто-то самостоятелен и замотивирован, кто-то нет. В итоге и карьера у них складывается по-разному.
В остальном не увидел принципиальных разногласий с моими аргументами. Начинающие разработчики знают недостаточно и поверхностно, вне зависимости от инфраструктуры. Опытные инженеры знают глубоко и широко, опять же, вне зависимости от инфраструктуры.
Отличие одно - уровень работы с инфраструктуры становится все выше и выше (от голого железа до условных "функций" или вообще какого-то декларативного кода). Уровень поднимается за счет появления новых абстракций - ОС, контейнеры, оркестратоты, сервисмеши и т.п.
Сначала они неустойчивые и сложные, потом обрастают сообществом, становятся лучше и надежнее, и со временем переходят в разряд стандартов. И уже поверх них начинают пилиться новые ненадежные абстракции. Кубер уже перешел в категорию стандартов, сервисмеши пока в пути, прочие навороты пока только на горизонте.
---
Кстати, это очень хорошо можно увидеть, посмотрев InfoQ Trends Report, в котором очень четко видно, как с годами технологии переходят из разряда новых идей в разряд корпоративных стандартов.
Отвечу по пунктам.
И не должны понимать, в этом и смысл изменений. Когда-то программист должен был понимать, как программировать под конкретное железо, пока не появился POSIX с набором сисколов. Потом появились более высокоуровневые ЯП, которые и работу с сисколами заменили абстракциями. Все это делается ради того, чтобы программист мог больше своего времени тратить на реализацию бизнес-логики и меньше - на интеграцию в конкретную инфраструктуру.
Понимает ли программист, как работает сискол под капотом? Если да, то не каджый. Надо ли ему это? Если не пишет дрова или микроконтроллеры - нет.
То же самое и с кубом. Сейчас подавляющее большинство Go, Java и еще что там разработчиков приходит на собеседования со знанием контейнеров, докера, кубера, пониманием CI/CD и прочего. Это тот уровень абстракции, на котором работает сегодняшний программист (ну скажем, 80% программистов). Завтрашний работает на уровне примитивов Istio и Knative, послезавтрашний - на основе примитивов девелопера в рамках ролевой модели Dapr.
Плохо ли это? Да в общем нет - компании не нужно, чтобы все знали обо всем. Достаточно нанять пару "экспертов в технологии X (например DevOps для технологии Kubernetes), которые и будут решать задачи, где нужно знание "как эта балалайка работает". Остальные же будут работать с абстракциями, позволяющими деливерить продукты быстрее и лучше. И масштабировать обычно нужно команду разработчиков, а не "экспертов в X", а проще масштабировать команду людей, умеющих работать поверх абстракции, нежели экспертов в узкой области.
Докер и кубер создали общую абстракцию, за которую убрано очень много инфраструктурных нюансов - ОС, диск, сеть, логирование и скейлинг, перезапуск умерших сервисов и так далее. Это приводит к тому, что отдельному разработчику не нужно париться над этими задачами и выдумывать велосипеды/использовать зоопарк библиотек для их решения. То есть область, в которой работает разработчик, сужается до фактически написания бизнес-логики, остальное улетает за абстракции.
Это приводит к тому, что люди приходят с хорошим знанием одной общей абстракции (докер, куб, деплоймент, сервис, блю/грин, стейтфулсет), и эта абстракция примерно одна и та же от компании к компании. Нюансы конечно есть, но например поработав в одной компании с Nginx в качестве ingress, а в другой с Istio в том же качестве, разницы в коде приложения я никакого не увидел.
Такие решения как раз позволяют иметь меньше "свистелок" в проекте. Условный Dapr абстрагирует pub/sub и key-value за единый интерфейс. Нужно асинхронно слать эвент - берешь dapr pub/sub api, нужно закешировать данные - берешь dapr kv api. Решение требует минут вместо часов и дней, как было раньше, и въехать в код приложения быстрее и проще. А что там за имплементация pub/sub и key-value уже будет самый опытный инженер в команде думать, исходя из требований проекта.
Знаний, которые нужно держать в голове архитектору/техлиду, всегда было много, просто одни устаревают, а другие появляются. От этого никуда не уйти.
Знаний же в головах начинающих инженеров нужно даже меньше, чем раньше - уметь писать на своем ЯП, понимать особенности работы в контейнере (стейтлесс, грейсфул шатдаун, параллельная работа нескольких реплик), ну и неизменные вещи вроде ACID транзакций и лучших практик программирования.
Прошу простить за простыню текста, хотелось ответить подробно и с примерами.
Ничего необычного, железо дешевеет, разработка дорожает. Все идет по пути упрощения написания программ с момента возникновения программирования. Kubernetes был просто очередным шагом, Service Mesh - следующий шаг, а Knative и Dapr - уже следующий шаг.
Что-то следующее будет уже внутри них реализовано, например какой-нибудь хитрый акторный распределенный фреймворк, общающийся через брокера и работающий с KV. Возможно, описывать программу на этом шаге станет можно на декларативном ЯП, к чему все давно идет.
Ох уж эта американская система мер.
Вы в целом все верно говорите, нюанс только в том, что для вирусов с их скоростью мутации древний предок - это год-два назад.
Придумали коммунизм — закончили массовыми репрессиями.
Придумали новый путь в Индию — закончили геноцидом индейцев.
Придумали аджайл — закончили скрамом.
Американского автора выдает представление, что в мире есть 2 расы/цвета кожи.
А кем вы работали, позвольте спросить?
При всех минусах, в системах мониторинга сотрудников есть один неоспоримый плюс: увидев такую систему на испытательном (а в идеале еще до подписания договора) можно с уверенностью идти к другому работодателю.
Спасибо за статью. Сам испытываю проблемы с обработкой ошибочных сообщений из кафки, хотел прикрутить retry topic. У меня ситуация немного другая — кафка используется для асинхронного request-reply, т.е. есть, куда ответить об ошибке. Но с "плохими" сообщениями это дела не меняет.
Описанный подход выглядит логичным решением проблемы, разве что нужен механизм повторной публикации сообщений из отстойника.
Интересно, есть ли уже какие-то решения, которые отслеживают биллинг/провиженинг в реальном времени, чтобы если не остановить сервисы, то хотя бы уведомить клиента?
В том же GCP, насколько знаю, биллинговые данные попадают в bigquery, оттуда можно как-то мониторить. Ну и тот же cloud pub/sub с уведомлениями — но опять же, насколько вовремя они туда попадают?
Вообще выглядит все так (особенно после прочтения статьи по ссылке) не стоит пользоваться сервисами, у которых возможности явно указать верхний лимит по апскейлу (если вы не мегакорпорация, которая готова платить миллионы за обработку скачкообразной нагрузки).
Те же кубы и виртуалки вполне себе легко посчитать + явно задаются лимиты автоскейлинга. А вот эти модно-молодежные лямбды и фаербейзы — работа "по волшебству" имеет две стороны медали — нужно меньше Ops, но и не понятно, когда сколько реального потребления и сколько придется заплатить.