Здравствуйте! Вообще, спасибо за внимание к деталям! Я так сформулировал «текстовые файлы» чтобы написать в простом смысле и чтобы подчеркнуть, что cookie — это именно текстовые данные, а не бинарныефайлы или исполняемый код. Писал формулировку с целью донести концепцию до широкого читателя, которые вообще не понимают о чем конкретно речь.Я согласен, что с точки зрения современнрй технической реализации в движках браузеров, эти данные хранятся в оптимизированной бд (например, SQLite), а не как отдельные файлы на диске. Возможно, стоило написать «фрагменты данных/текста» вместо «текстовые файлы» для большей точности.
Спасибо за комментарий. В статье имел в виду, что DNS используется не напрямую. Браузер для поиска отправляет запрос в поисковую систему. Однако для самой системы, как и для любого сайта, сначала обязательно выполняется DNS-запрос (как вы и сказали). То есть да, DNS всегда задействован, просто он работает за ширмой или как любят говорить под капотом.
Спасибо, что заметили. Li-Pol-аккумы и правда более чувствительны к проколам и сильному давлению, это может вызвать полный выход из строя, может даже вздутие. Но в то же время гибкость в форме дает Li-Pol относительную «механическую стабильность». Поясняю: лучше виброустойчивость и также имеют пониженный (но не нулевой) риск возгорания. Внутри статьи убрал путаницу, чтобы не было вопросов.
Здравствуйте, спасибо за уточнение, я имел ввиду не конкретно аэродинамический эффект. Вернее было сказать: Морской радар излучает радиоволны и фиксирует их отражения от объектов. Экранопланы, летя на низкой высоте над водой, менее заметны, так как отражения радиоволн от морской поверхности создают помехи и затрудняют радиолокационное обнаружение. (в том числе)
Невидимость низколетящей цели для радиолокатора, установленного на поверхности суши/моря, зависит от высоты полета над поверхностью. Чем ниже летит самолет и чем ниже установлен радиолокатор, тем короче будет радиогоризонт.
Я дополнил текст статьи исходя из вашего комментария.
Радары обнаруживают объекты по отражённым радиоволнам.
Экранопланы, летя очень низко над поверхностью воды, менее заметны, так как отражение радиоволн от воды создают сложные помехи и снижают точность обнаружения. Тот самый эффект экрана.
Внутри статьи тоже поправил, неправильно выразился, спасибо что заметили!
Пока еще, массовости оно не набирает, даже с такими большими инвестициями. Хоть и есть некоторые кейсы успешной работы, но это скорее исключение. В будущем скорее всего мы покатаемся на беспилотных бомбилах такси, но пока имеем то что имеем.
Заголовок исправил, чтобы не вводил в заблуждение.
Понимаю ваше замечание. В статье такой акцент тк на это смотрит большинство пользователей и сценариев использования, особенно когда речь о больших объёмах данных. Да, технология хранения не сводится только к цене, особенно надёжность и срок хранения важны в этом контексте, и это справедливо. Кроме того, ёмкость SSD растёт, но для многих корп. архивов HDD остаются главным благодаря долговечности и простоте восстановления данных, опять таки да Так что в любом случае, важно все в совокупности)
Тут скорее закладывался двойной смысл, первый смысл, который еще можно понять по обложке, оранжевым имульсом показана кардиограмма HDD, которая все еще бьется то бишь используется в 2025, и еще конечно второй смысл в том самом звуке)
Это образное выражение, чтобы передать, как при работе бумажная лента, как бы мелькала и шевелилась вместе с щелчками механики. Зрительно, сама передача данных не просто нули и единицы, а реально живой процесс.
Речь скорее о крупных производствах, где CVшную аналитику выполняют прямо на линии или в локальной сети, а облако привлекают для глобальной агрегации, тренировки моделей и CI/CD-управления. Ниже — реальные кейсы для наглядности:
Есть заводская площадка Siemens Electronics в Амберге, внедряющая Industrial Edge + MindSphere на AWS. Edge-приложения фильтруют и агрегируют данные в реальном времени, а в облаке тренируют цифровые двойники и строят сквозную аналитику. В результате удалось повысить общую эффективность оборуд.(OEE) до 85% и сократить простои примерно на 20%.
Подразделение GE Power, которое на Predix в AWS через Kinesis и EMR обрабатывая до 20 миллиардов тегов сенсорных данных. Облачные ML-модели им снизили расходы порядком, скорее всего в несколько млн зеленых.
BMW Group как автопроизводитель использует AWS IoT Hub и SageMaker для обработки 10 ТБ данных ежедневно от 1,2 миллиона автомобилей, тренировки ML-моделей. Теперь у них инсайты в реальном времени.
ExxonMobil — компания в нефтегазе, стримит данные буровых колонн в AWS IoT Core. Облачные симуляции оптимизируют режимы бурения и теперь новые скважины на 40 % быстрей строят. по этому примеру информация кнш ограничена но тут похожее есть
Вот и получается, что облако в этих сценариях в роли большого брата отвечает за долгосрочную агрегацию, тренировку ML-моделей и CI/CD-управление fleet-ом edge-устройств, чтобы у нас была одна «истина» и масштаб.
Пока edge-устройства не получили спец ускорители, такие как NPU или TPU, они часто перегреваются, потребляют много энергии и не так хороши, как о них говорят, но все впереди. Это часть гибридной архитектуры.(часть команды, часть корабля)
И опять таки, дедлайновые операции — на краю, тяжёлые вычисления — в облаке. Иначе рискуем получить не умный дом, а дом психическим расстройством..
В статье как раз и был акцент на том, что edge без облака не тянет: не хватает одного, прозрачно-наблюдаемо-гибкого масштабирования. GitOps + ArgoCD тут не идеал конечно, но дает держать desired state в гите и катить изменения без ручной рутины.
Все упирается в баланс — push-подход с Prometheus — ок, но на больших кластерах становится шумным, особенно без нормальной агрегации на краю. Можно получить телеметрию вида «что-то где-то сломалось, но метрики на месте»
Что до зомби-багов — тут помогает фичефлагинг и канареечные релизы с rollout-хуками по SLA. А по поводу где отрубать — ориентир простой: если реакция важнее консистентности, значит логика должна оставаться на краю. Все остальное — в облако, на повторное использование и контроль.
Ну и да, если у вас все всегда стабильно — скорее всего, оно просто давно не обновлялось)
Да, в случае с гигантом, как кола, абсолютные цифры в долларах выглядят конечно ничтожно маленькими, особенно в публичных отчётах. Но тут я хотел показать не столько размер экономии, сколько сам вектор — миграция с legacy-архитектуры на serverless в принципе. Это даёт гибкость, быстрее выпускать новые фичи, меньше времени тратить на поддержку. Особенно в системах с высокой и непредсказуемой нагрузкой, как у Coca-Cola с их полумиллионом заказов в день, может они что то потом и придумали, как оптимизировать :)
Что касается вашего примера — классический кейс "облака ради галочки", к сожалению (ну или для кого то к счастью), такое действительно часто случается. Но всё же хочется верить, что культура использования облака эволюционирует. Хотя, конечно, без «освоения бюджета» и маркетинговых побед в духе «мы теперь в serverless» пока никуда..
Спасибо, что обратили внимание на защиту функций. В дополнение к сказанному, из интересных практик, которые попадались, для минимизации привилегий использовали IAM Access Analyzer в связке с CloudTrail: то естть, на основе реальных вызовов формируются максимально узкие политики, и это снижает поверхность атаки. Да, подход не новый, но рабочий.
Для валидации данных часто отталкиваются от OWASP Serverless Top 10 — проверка полей по whitelist, плюс экранирование всего, что может привести к инъекциям, до передачи в базу или внешние API.
От DDoS и перебора помогает rate-limiting в API Gateway, иногда подключают AWS WAF с rate-based правилами — тоже довольно эффективная связка.
Ну и про наблюдаемость, как бы ни хотелось «делегировать всё провайдеру», без нормального мониторинга врядли что то получится. Lambda Insights и Anomaly Detection в CloudWatch здесь выручают — не пропустят аномалии и дадут реакцию.
Спасибо за поднятую тему о конфликте SRP. После изучения практик крупных тех-гигантов, могу сказать, что архитектурные и инфраструктурные оптимизации приносят куда больше эффекта, чем попытка «почистить» каждый метод в отдельности.
Напримерр, в Java-сервисе Netflix (GS2) при переносе с m5.4xlarge на m5.12xlarge ожидаемый линейный рост не подтвердился — фактическое улучшение оказалось существенно ниже. При микроархитектурном анализе выяснилось, что имеет место false sharing : соседние поля в объекте конкурировали за одну кеш-линию, генерируя постоянные инвалидации и просадки throughput. Добавиление 56-байтный padding – и voilа: ≈3.5× рост RPS и заметное снижение как средней, так и 99-го процентиля задержки.
Тут хорошо видно, как локальные проблемы на уровне железа могут полностью «съесть» масштабируемость, даже при честном соблюдении принципов проектирования.
Другой пример — AWS Local Zones. Netflix перенёс часть latency-sensitive логики ближе к студиям аниматоров, и теперь художники получают однозначные миллисекундные задержки при интерактивном рендеринге графики — чего невозможно добиться при кросс-региональном вызове. При этом внутри объединённых процессов соблюдаются чёткие DDD-bounded contexts и event-driven обмен, так что поддерживаемость и масштабируемость не страдают.
и снова видно, что инфрастр. решение зачастую даёт больший выигрыш, чем идеальная SRP-архитектура, особенно в условиях real-time.
Так что именно такой микс «умных» границ и продуманных инженерных приёмов зачастую сильнее тысячи правок Code Smells. Этот ответ подпитан свежей кружкой кофе и старыми добрыми статьями тех-блогов :)
Здравствуйте!
Вообще, спасибо за внимание к деталям! Я так сформулировал «текстовые файлы» чтобы написать в простом смысле и чтобы подчеркнуть, что cookie — это именно текстовые данные, а не бинарныефайлы или исполняемый код. Писал формулировку с целью донести концепцию до широкого читателя, которые вообще не понимают о чем конкретно речь.Я согласен, что с точки зрения современнрй технической реализации в движках браузеров, эти данные хранятся в оптимизированной бд (например, SQLite), а не как отдельные файлы на диске. Возможно, стоило написать «фрагменты данных/текста» вместо «текстовые файлы» для большей точности.
Добрый вечер!
Спасибо за комментарий. В статье имел в виду, что DNS используется не напрямую. Браузер для поиска отправляет запрос в поисковую систему. Однако для самой системы, как и для любого сайта, сначала обязательно выполняется DNS-запрос (как вы и сказали). То есть да, DNS всегда задействован, просто он работает за ширмой или как любят говорить под капотом.
Спасибо, что заметили. Li-Pol-аккумы и правда более чувствительны к проколам и сильному давлению, это может вызвать полный выход из строя, может даже вздутие. Но в то же время гибкость в форме дает Li-Pol относительную «механическую стабильность». Поясняю: лучше виброустойчивость и также имеют пониженный (но не нулевой) риск возгорания.
Внутри статьи убрал путаницу, чтобы не было вопросов.
Здравствуйте, спасибо за уточнение, я имел ввиду не конкретно аэродинамический эффект. Вернее было сказать: Морской радар излучает радиоволны и фиксирует их отражения от объектов. Экранопланы, летя на низкой высоте над водой, менее заметны, так как отражения радиоволн от морской поверхности создают помехи и затрудняют радиолокационное обнаружение. (в том числе)
Невидимость низколетящей цели для радиолокатора, установленного на поверхности суши/моря, зависит от высоты полета над поверхностью. Чем ниже летит самолет и чем ниже установлен радиолокатор, тем короче будет радиогоризонт.
Я дополнил текст статьи исходя из вашего комментария.
Радары обнаруживают объекты по отражённым радиоволнам.
Экранопланы, летя очень низко над поверхностью воды, менее заметны, так как отражение радиоволн от воды создают сложные помехи и снижают точность обнаружения. Тот самый эффект экрана.
Внутри статьи тоже поправил, неправильно выразился, спасибо что заметили!
Не все так гладко, нашел новость вот такую про упомянутых вами «Waymo».
Дтп и отзыв авто, не особо коннектиться с развитием здесь и сейчас.
Пока еще, массовости оно не набирает, даже с такими большими инвестициями. Хоть и есть некоторые кейсы успешной работы, но это скорее исключение. В будущем скорее всего мы покатаемся на беспилотных
бомбилахтакси, но пока имеем то что имеем.Заголовок исправил, чтобы не вводил в заблуждение.
Понимаю ваше замечание. В статье такой акцент тк на это смотрит большинство пользователей и сценариев использования, особенно когда речь о больших объёмах данных. Да, технология хранения не сводится только к цене, особенно надёжность и срок хранения важны в этом контексте, и это справедливо.
Кроме того, ёмкость SSD растёт, но для многих корп. архивов HDD остаются главным благодаря долговечности и простоте восстановления данных, опять таки да
Так что в любом случае, важно все в совокупности)
Здравствуйте!
Тут скорее закладывался двойной смысл, первый смысл, который еще можно понять по обложке, оранжевым имульсом показана кардиограмма HDD, которая все еще бьется то бишь используется в 2025, и еще конечно второй смысл в том самом звуке)
Это образное выражение, чтобы передать, как при работе бумажная лента, как бы мелькала и шевелилась вместе с щелчками механики. Зрительно, сама передача данных не просто нули и единицы, а реально живой процесс.
Здравствуйте, натыкался на пост о том что, Sony анонсировала аксессуар для консоли. Который как раз и будет контроллером с 8-дюймовым экраном.
Речь скорее о крупных производствах, где CVшную аналитику выполняют прямо на линии или в локальной сети, а облако привлекают для глобальной агрегации, тренировки моделей и CI/CD-управления. Ниже — реальные кейсы для наглядности:
Есть заводская площадка Siemens Electronics в Амберге, внедряющая Industrial Edge + MindSphere на AWS. Edge-приложения фильтруют и агрегируют данные в реальном времени, а в облаке тренируют цифровые двойники и строят сквозную аналитику. В результате удалось повысить общую эффективность оборуд.(OEE) до 85% и сократить простои примерно на 20%.
Подразделение GE Power, которое на Predix в AWS через Kinesis и EMR обрабатывая до 20 миллиардов тегов сенсорных данных. Облачные ML-модели им снизили расходы порядком, скорее всего в несколько млн зеленых.
BMW Group как автопроизводитель использует AWS IoT Hub и SageMaker для обработки 10 ТБ данных ежедневно от 1,2 миллиона автомобилей, тренировки ML-моделей. Теперь у них инсайты в реальном времени.
ExxonMobil — компания в нефтегазе, стримит данные буровых колонн в AWS IoT Core. Облачные симуляции оптимизируют режимы бурения и теперь новые скважины на 40 % быстрей строят. по этому примеру информация кнш ограничена но тут похожее есть
Вот и получается, что облако в этих сценариях
в роли большого братаотвечает за долгосрочную агрегацию, тренировку ML-моделей и CI/CD-управление fleet-ом edge-устройств, чтобы у нас была одна «истина» и масштаб.Пока edge-устройства не получили спец ускорители, такие как NPU или TPU, они часто перегреваются, потребляют много энергии и не так хороши, как о них говорят, но все впереди. Это часть гибридной архитектуры.(часть команды, часть корабля)
И опять таки, дедлайновые операции — на краю, тяжёлые вычисления — в облаке. Иначе рискуем получить не умный дом, а дом психическим расстройством..
В статье как раз и был акцент на том, что edge без облака не тянет: не хватает одного, прозрачно-наблюдаемо-гибкого масштабирования. GitOps + ArgoCD тут не идеал конечно, но дает держать desired state в гите и катить изменения без ручной рутины.
Все упирается в баланс — push-подход с Prometheus — ок, но на больших кластерах становится шумным, особенно без нормальной агрегации на краю. Можно получить телеметрию вида «что-то где-то сломалось, но метрики на месте»
Что до зомби-багов — тут помогает фичефлагинг и канареечные релизы с rollout-хуками по SLA. А по поводу где отрубать — ориентир простой: если реакция важнее консистентности, значит логика должна оставаться на краю. Все остальное — в облако, на повторное использование и контроль.
Ну и да, если у вас все всегда стабильно — скорее всего, оно просто давно не обновлялось)
Да, в случае с гигантом, как кола, абсолютные цифры в долларах выглядят конечно ничтожно маленькими, особенно в публичных отчётах. Но тут я хотел показать не столько размер экономии, сколько сам вектор — миграция с legacy-архитектуры на serverless в принципе. Это даёт гибкость, быстрее выпускать новые фичи, меньше времени тратить на поддержку. Особенно в системах с высокой и непредсказуемой нагрузкой, как у Coca-Cola с их полумиллионом заказов в день, может они что то потом и придумали, как оптимизировать :)
Что касается вашего примера — классический кейс "облака ради галочки", к сожалению (ну или для кого то к счастью), такое действительно часто случается. Но всё же хочется верить, что культура использования облака эволюционирует. Хотя, конечно, без «освоения бюджета» и маркетинговых побед в духе «мы теперь в serverless» пока никуда..
Спасибо, что обратили внимание на защиту функций. В дополнение к сказанному, из интересных практик, которые попадались, для минимизации привилегий использовали IAM Access Analyzer в связке с CloudTrail: то естть, на основе реальных вызовов формируются максимально узкие политики, и это снижает поверхность атаки. Да, подход не новый, но рабочий.
Для валидации данных часто отталкиваются от OWASP Serverless Top 10 — проверка полей по whitelist, плюс экранирование всего, что может привести к инъекциям, до передачи в базу или внешние API.
От DDoS и перебора помогает rate-limiting в API Gateway, иногда подключают AWS WAF с rate-based правилами — тоже довольно эффективная связка.
Ну и про наблюдаемость, как бы ни хотелось «делегировать всё провайдеру», без нормального мониторинга врядли что то получится. Lambda Insights и Anomaly Detection в CloudWatch здесь выручают — не пропустят аномалии и дадут реакцию.
Спасибо за поднятую тему о конфликте SRP. После изучения практик крупных тех-гигантов, могу сказать, что архитектурные и инфраструктурные оптимизации приносят куда больше эффекта, чем попытка «почистить» каждый метод в отдельности.
Напримерр, в Java-сервисе Netflix (GS2) при переносе с m5.4xlarge на m5.12xlarge ожидаемый линейный рост не подтвердился — фактическое улучшение оказалось существенно ниже. При микроархитектурном анализе выяснилось, что имеет место false sharing : соседние поля в объекте конкурировали за одну кеш-линию, генерируя постоянные инвалидации и просадки throughput. Добавиление 56-байтный padding – и voilа: ≈3.5× рост RPS и заметное снижение как средней, так и 99-го процентиля задержки.
Тут хорошо видно, как локальные проблемы на уровне железа могут полностью «съесть» масштабируемость, даже при честном соблюдении принципов проектирования.
Другой пример — AWS Local Zones. Netflix перенёс часть latency-sensitive логики ближе к студиям аниматоров, и теперь художники получают однозначные миллисекундные задержки при интерактивном рендеринге графики — чего невозможно добиться при кросс-региональном вызове. При этом внутри объединённых процессов соблюдаются чёткие DDD-bounded contexts и event-driven обмен, так что поддерживаемость и масштабируемость не страдают.
и снова видно, что инфрастр. решение зачастую даёт больший выигрыш, чем идеальная SRP-архитектура, особенно в условиях real-time.
Так что именно такой микс «умных» границ и продуманных инженерных приёмов зачастую сильнее тысячи правок Code Smells. Этот ответ подпитан свежей кружкой кофе и старыми добрыми статьями тех-блогов :)