#деньги #машины_разное #машины_aws
Когда мы говорим о запрете трафика куда угодно наружу и внутрь, мы имеем в виду ANY/ANY правила на межсетевых экранах.
PCI-DSS требует жесткого контроля над входящим и исходящим трафиком в безопасный периметр. Удовлетворить это требование можно двумя способами.
Первый способ подразумевает очевидное: прокси и фаерволы; второй же допускает реактивный подход. Вместо того, чтобы разрешать трафик на определенные адреса, мы можем сделать правило, например, разрешающее весь исходящий HTTPS трафик. Однако мы будем держать белый список и проверять весь трафик на соответствие этому списку. В случае подозрительного пакетов, дергаем дежурного, чтобы он пошел и посмотрел, что там такое происходит.
Что использование прокси, что мониторинг трафика несут с собой определенные удобства и неудобства. С прокси суть тот же белый список, что требует дополнительной работы при интеграции с новой платежной системой, особенно если та находится за поставщиком DDOS защиты навроде Akamai. С мониторингом трафика получаем неприятный опыт дежурства.
Мониторинг безопасности сам по себе необходим, и PCI-DSS по сути требует от нас делать то, что мы и так должны делать. Взять к примеру доступ к инфраструктуре, где лежат реальные данные клиентов. Людям/операторам там делать нечего, за исключением случае дешифровки данных по запросу властей, а значит каждый такой доступ должен отправлять уведомление дежурному.
Если мы развернули систему токенизации в облаке, то подобный мониторинг должен быть не только на уровне самих узлов (доступ по SSH), но и на уровне самого клавда -
Важно помнить, что приглядывать надо не только за правами дающими доступ к картам, но и правам дающим администраторский доступ.
В конце концов скомпроментированный сотрудник может просто напросто выключить мониторинг, слить данные, включить мониторинг обратно.
Когда мы говорим о запрете трафика куда угодно наружу и внутрь, мы имеем в виду ANY/ANY правила на межсетевых экранах.
PCI-DSS требует жесткого контроля над входящим и исходящим трафиком в безопасный периметр. Удовлетворить это требование можно двумя способами.
Первый способ подразумевает очевидное: прокси и фаерволы; второй же допускает реактивный подход. Вместо того, чтобы разрешать трафик на определенные адреса, мы можем сделать правило, например, разрешающее весь исходящий HTTPS трафик. Однако мы будем держать белый список и проверять весь трафик на соответствие этому списку. В случае подозрительного пакетов, дергаем дежурного, чтобы он пошел и посмотрел, что там такое происходит.
Что использование прокси, что мониторинг трафика несут с собой определенные удобства и неудобства. С прокси суть тот же белый список, что требует дополнительной работы при интеграции с новой платежной системой, особенно если та находится за поставщиком DDOS защиты навроде Akamai. С мониторингом трафика получаем неприятный опыт дежурства.
Мониторинг безопасности сам по себе необходим, и PCI-DSS по сути требует от нас делать то, что мы и так должны делать. Взять к примеру доступ к инфраструктуре, где лежат реальные данные клиентов. Людям/операторам там делать нечего, за исключением случае дешифровки данных по запросу властей, а значит каждый такой доступ должен отправлять уведомление дежурному.
Если мы развернули систему токенизации в облаке, то подобный мониторинг должен быть не только на уровне самих узлов (доступ по SSH), но и на уровне самого клавда -
sts:AssumeRole “опасных” ролей или в целом подозрительные API вызовы.Важно помнить, что приглядывать надо не только за правами дающими доступ к картам, но и правам дающим администраторский доступ.
В конце концов скомпроментированный сотрудник может просто напросто выключить мониторинг, слить данные, включить мониторинг обратно.
👍13🔥2
#машины_разное
Есть проблема, когда SSD отваливается ровно через 40 000 часов использования.
Есть проблема, когда SSD отваливается ровно через 32 768 часов использования.
И эти проблемы не связаны: While the failure mode is similar, this issue is unrelated to the SSD issue detailed in this Customer Bulletin released in November 2019, which describes an SSD failure at 32,768 hours of operation.
Как хорошо, когда #железопроблемы тебя не касаются.
Есть проблема, когда SSD отваливается ровно через 40 000 часов использования.
Есть проблема, когда SSD отваливается ровно через 32 768 часов использования.
И эти проблемы не связаны: While the failure mode is similar, this issue is unrelated to the SSD issue detailed in this Customer Bulletin released in November 2019, which describes an SSD failure at 32,768 hours of operation.
Как хорошо, когда #железопроблемы тебя не касаются.
🤔12👎2
#машины_разное
"...back in the ‘90s, one of IBM’s Redbooks stated that the “happy path” for any piece of software comprised less than 20 percent of its code; the rest was dedicated to error handling and resilience."
Эти строки из поста про "Отрицательную инженерию" напомнили мне про одну занятную историю с платежными методами.
Средний пользователь имеет 2, максимум 3, подключенных платежных метода, будь то банковская карта, Apple/Google Pay и иже с ним. Спроектировать систему работы с платежными инструментами не так уж сложно, ориентируясь на такой профиль пользователя.
Но со временем появляется тот мизерный процент пользователей с невероятным количеством методов, уникальными способами оплаты с разных мест и прочие corner case'ы, которые предусмотреть невозможно, заложить в систему избыточно...
А чинить и доводить до ума все равно надо.
Пост выше - хороший набор аргументов для продавливания повыше в беклоге задач по оплате технического долга и доведении систем до ума. Пользуйтесь на здоровье.
"...back in the ‘90s, one of IBM’s Redbooks stated that the “happy path” for any piece of software comprised less than 20 percent of its code; the rest was dedicated to error handling and resilience."
Эти строки из поста про "Отрицательную инженерию" напомнили мне про одну занятную историю с платежными методами.
Средний пользователь имеет 2, максимум 3, подключенных платежных метода, будь то банковская карта, Apple/Google Pay и иже с ним. Спроектировать систему работы с платежными инструментами не так уж сложно, ориентируясь на такой профиль пользователя.
Но со временем появляется тот мизерный процент пользователей с невероятным количеством методов, уникальными способами оплаты с разных мест и прочие corner case'ы, которые предусмотреть невозможно, заложить в систему избыточно...
А чинить и доводить до ума все равно надо.
Пост выше - хороший набор аргументов для продавливания повыше в беклоге задач по оплате технического долга и доведении систем до ума. Пользуйтесь на здоровье.
Future
What Is Negative Engineering?
Negative engineering is the time-consuming and sometimes frustrating work that engineers do to ensure small bugs don't take down systems.
👍2
#машины_разное
Многие кандидаты валятся на интервью, когда не могут продемонстрировать полное понимание работы предлагаемых инструментов. Проще говоря, если предлагаешь Kafka в роли брокера сообщений, то будь добр понимать внутреннее устройство со всеми его приколами.
Такая придирчивость не только к кандидатам, но и коллегам во время архитектурных разборов. Хуже системы, поведение и принцип работы которой никому не понятен, в эксплуатации не найти.
Отсюда же недоверие к managed хранилищам. К примеру, архитектура той же DynamoDB еле описана в документации и одноименной научной работе. Все что мы, по сути, знаем, что это Leader-Follower СУБД с шардированием по ключу партиции. Каким именно образом работает шардирование, и сколько мы имеем шардов на старте, и как именно распределяются capacity units по шардам, мы не знаем.
С open-source СУБД все гораздо проще, открыл код, да посмотрели ничего не понял. Для тех, кто не хочет смотреть в код и ничего не понимать, есть отличная литература по кишкам. Одно время я запоем читал Database Internals, а теперь с таким же удовольствием читаю про внутренности Postgres 14-ой версии.
Потому что с autovacuum шутки плохи!
Многие кандидаты валятся на интервью, когда не могут продемонстрировать полное понимание работы предлагаемых инструментов. Проще говоря, если предлагаешь Kafka в роли брокера сообщений, то будь добр понимать внутреннее устройство со всеми его приколами.
Такая придирчивость не только к кандидатам, но и коллегам во время архитектурных разборов. Хуже системы, поведение и принцип работы которой никому не понятен, в эксплуатации не найти.
Отсюда же недоверие к managed хранилищам. К примеру, архитектура той же DynamoDB еле описана в документации и одноименной научной работе. Все что мы, по сути, знаем, что это Leader-Follower СУБД с шардированием по ключу партиции. Каким именно образом работает шардирование, и сколько мы имеем шардов на старте, и как именно распределяются capacity units по шардам, мы не знаем.
С open-source СУБД все гораздо проще, открыл код, да посмотрел
Потому что с autovacuum шутки плохи!
Postgrespro
PostgreSQL 14 Internals
Postgres Professional is a PostgreSQL company delivering Postgres Pro DBMS and all kinds of PostgreSQL professional services worldwide
👍16👎3🤔1
#люди
https://www.infoworld.com/article/3669477/devs-don-t-want-to-do-ops.html
"You build it - you run it" рискует свернуть совсем не туда. Если изначально идея заключалась в том, чтобы строить надежные системы, потому что кому как не тебе в ночи потом это чинить, то теперь люди хотят просто комфортно что-то строить, а чинить это будет пусть кто-то другой.
Колесо Сансары сделало еще один оборот.
https://www.infoworld.com/article/3669477/devs-don-t-want-to-do-ops.html
"You build it - you run it" рискует свернуть совсем не туда. Если изначально идея заключалась в том, чтобы строить надежные системы, потому что кому как не тебе в ночи потом это чинить, то теперь люди хотят просто комфортно что-то строить, а чинить это будет пусть кто-то другой.
Колесо Сансары сделало еще один оборот.
InfoWorld
Devs don’t want to do ops
Developers are straining under the demands of ‘You build it, you run it,’ and operators are feeling more pressure too. Is it time for development and operations to be separated once again?
#машины_aws
Мимо меня прошло две новости, которые заслуживают отдельного внимания и разбора.
Начну с новости меньшей. Теперь можно импортировать данные из S3 в новую таблицу DynamoDB. Использований у этого масса: как механизм Disaster Recovery, так и дешевый экспорт/импорт данных для временной обработки.
Другой анонс куда интереснее и называется IAM Role Anywhere. С "ролями везде" можно расширить функциональность сторонних сервисов "подружив" ее с AWS'ным контролем доступа, или даже сделать свои собственные Service-to-Service модели доступа.
Я распишу этот релиз подробно в отдельном посте (обещаю лонгрид на Медиуме), потому что новость просто пушка.
Мимо меня прошло две новости, которые заслуживают отдельного внимания и разбора.
Начну с новости меньшей. Теперь можно импортировать данные из S3 в новую таблицу DynamoDB. Использований у этого масса: как механизм Disaster Recovery, так и дешевый экспорт/импорт данных для временной обработки.
Другой анонс куда интереснее и называется IAM Role Anywhere. С "ролями везде" можно расширить функциональность сторонних сервисов "подружив" ее с AWS'ным контролем доступа, или даже сделать свои собственные Service-to-Service модели доступа.
Я распишу этот релиз подробно в отдельном посте (обещаю лонгрид на Медиуме), потому что новость просто пушка.
Amazon
Amazon DynamoDB can now import Amazon S3 data into a new table | Amazon Web Services
February, 2025: As of November 1, 2024, Amazon DynamoDB has reduced its pricing, offering a 50% reduction for on-demand throughput. These post was updated to reflect this change. For complete details about these pricing changes, visit New – Amazon DynamoDB…
👍11🔥8
#люди
Удивительно взаимоисключающие, но сосуществующие факторы моей нынешней работы:
1. Надо проектировать/разрабатывать из расчета, что ты будешь поддерживать это годами.
2. Надо проектировать/разрабатывать из расчета, что через месяц это отдадут кому-то другому.
Удивительно взаимоисключающие, но сосуществующие факторы моей нынешней работы:
1. Надо проектировать/разрабатывать из расчета, что ты будешь поддерживать это годами.
2. Надо проектировать/разрабатывать из расчета, что через месяц это отдадут кому-то другому.
👍9🔥5😱4
#машины_aws
Разочарования пост.
У меня были довольно большие ожидания от IAM Role Anywhere. Я прочитал анонс криво и решил, что речь идет о своей собственной внутренней аутентификации и авторизации.
Проще говоря, мы могли бы регистрировать свои собственные сервисы в IAM, создавать свои
Оказалось, что вместо этого мы получаем еще один способ выполнить
Это тоже имеет свою пользу, нам больше не нужно заводить отдельного IAM пользователя, генерировать ему API ключ и секрет и скармливать его on-premise приложениям… Но скучно.
В итоге забросил писать блог об этом. Да, я обещал вам лонгрид, но я обещал вам годный контент, а не переписанный блог от AWS.
А отсутствие контента лучше плохого контента.
Разочарования пост.
У меня были довольно большие ожидания от IAM Role Anywhere. Я прочитал анонс криво и решил, что речь идет о своей собственной внутренней аутентификации и авторизации.
Проще говоря, мы могли бы регистрировать свои собственные сервисы в IAM, создавать свои
Actions, Principals и так далее. Какие возможности открываются.Оказалось, что вместо этого мы получаем еще один способ выполнить
sts:AssumeRole используя mTLS в качестве управления доступом.Это тоже имеет свою пользу, нам больше не нужно заводить отдельного IAM пользователя, генерировать ему API ключ и секрет и скармливать его on-premise приложениям… Но скучно.
В итоге забросил писать блог об этом. Да, я обещал вам лонгрид, но я обещал вам годный контент, а не переписанный блог от AWS.
А отсутствие контента лучше плохого контента.
Telegram
Человек и машина
#машины_aws
Мимо меня прошло две новости, которые заслуживают отдельного внимания и разбора.
Начну с новости меньшей. Теперь можно импортировать данные из S3 в новую таблицу DynamoDB. Использований у этого масса: как механизм Disaster Recovery, так и дешевый…
Мимо меня прошло две новости, которые заслуживают отдельного внимания и разбора.
Начну с новости меньшей. Теперь можно импортировать данные из S3 в новую таблицу DynamoDB. Использований у этого масса: как механизм Disaster Recovery, так и дешевый…
👍12👎1
#деньги
Я только что сдал экзамен по PCI Fundamentals, и одним из вопросов там был: “С какой целью PCI SSC проводит ежегодные встречи сообщества?”
Варианта “А на кой шиш мне это знать?” в списке ответов не было.
Я только что сдал экзамен по PCI Fundamentals, и одним из вопросов там был: “С какой целью PCI SSC проводит ежегодные встречи сообщества?”
Варианта “А на кой шиш мне это знать?” в списке ответов не было.
🤔9👍2😱1
#деньги #машины_разное
В стандарте PCI-DSS есть одна фишка, которая делает его моим любимым стандартом на рынке. Эта фишка называется Compensating Controls (далее СС), и она позволяет переиначить любое из 12 требований, разумеется, в разумных пределах.
Что сами по себе означают СС? СС позволяют подойти к одному или нескольким требованиям PCI-DSS иначе. Взять к примеру требование 1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone, которое в простонародье означает “никаких ALLOW 0.0.0.0 в интернеты, даже на порты 80 и 443!”
Следовать этому требованию можно, но далеко не всем и всегда. Если у вас используются поставщики платежей, обслуживающие транзакции для карточек, и они живут за CDN, то у вас есть несколько вариантов:
1. Добавить все IP адресы CDN в разрешенный список фаерволла.
2. Поставить прокси-сервер, чтобы тот фильтровал только на определенные доменные имена.
Ни то, ни другое целиком требование 1.1.4 не закрывает, прокси-сервер все еще имеет выход в сеть, а за сетью CDN живет не только ваш поставщик, мало ли кому там трафик уйдет. И тут на помощь приходят СС: а давайте мы разрешим трафик наружу, но будем следить за тем, куда этот трафик идет (я об этом уже писал тут).
У СС есть ряд определенных ограничений, ведь регулятор не дурак, и шатать свой стандарт никому не даст. Краткий (но не полный!) список нюансов таков:
1. Смысл в СС в соблюдении требований, а не обходе.
2. Нельзя использовать одно требование в качестве CC для другого (например использовать шифрование паролей в качестве СС для простых паролей).
3. Нельзя применить СС, если QSA указал на грубое несоблюдение требования
4. Каждый СС надо документировать, поясняя почему именно нельзя удовлетворить требование как есть.
Ну и так далее. Очень крутой стандарт, гибкий как резинка, крепкий как паутина. Сейчас еще на PCI ISA доучусь, вообще интересные вещи узнаю.
В стандарте PCI-DSS есть одна фишка, которая делает его моим любимым стандартом на рынке. Эта фишка называется Compensating Controls (далее СС), и она позволяет переиначить любое из 12 требований, разумеется, в разумных пределах.
Что сами по себе означают СС? СС позволяют подойти к одному или нескольким требованиям PCI-DSS иначе. Взять к примеру требование 1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone, которое в простонародье означает “никаких ALLOW 0.0.0.0 в интернеты, даже на порты 80 и 443!”
Следовать этому требованию можно, но далеко не всем и всегда. Если у вас используются поставщики платежей, обслуживающие транзакции для карточек, и они живут за CDN, то у вас есть несколько вариантов:
1. Добавить все IP адресы CDN в разрешенный список фаерволла.
2. Поставить прокси-сервер, чтобы тот фильтровал только на определенные доменные имена.
Ни то, ни другое целиком требование 1.1.4 не закрывает, прокси-сервер все еще имеет выход в сеть, а за сетью CDN живет не только ваш поставщик, мало ли кому там трафик уйдет. И тут на помощь приходят СС: а давайте мы разрешим трафик наружу, но будем следить за тем, куда этот трафик идет (я об этом уже писал тут).
У СС есть ряд определенных ограничений, ведь регулятор не дурак, и шатать свой стандарт никому не даст. Краткий (но не полный!) список нюансов таков:
1. Смысл в СС в соблюдении требований, а не обходе.
2. Нельзя использовать одно требование в качестве CC для другого (например использовать шифрование паролей в качестве СС для простых паролей).
3. Нельзя применить СС, если QSA указал на грубое несоблюдение требования
4. Каждый СС надо документировать, поясняя почему именно нельзя удовлетворить требование как есть.
Ну и так далее. Очень крутой стандарт, гибкий как резинка, крепкий как паутина. Сейчас еще на PCI ISA доучусь, вообще интересные вещи узнаю.
Telegram
Человек и машина
#деньги #машины_разное #машины_aws
Когда мы говорим о запрете трафика куда угодно наружу и внутрь, мы имеем в виду ANY/ANY правила на межсетевых экранах.
PCI-DSS требует жесткого контроля над входящим и исходящим трафиком в безопасный периметр. Удовлетворить…
Когда мы говорим о запрете трафика куда угодно наружу и внутрь, мы имеем в виду ANY/ANY правила на межсетевых экранах.
PCI-DSS требует жесткого контроля над входящим и исходящим трафиком в безопасный периметр. Удовлетворить…
🔥7❤1👍1
#машины_aws
Удивительная компания AWS все-таки. Смотришь анонс какого-нибудь re:Invent или саммита, видишь сплошные bleeding edge технологии и сплошной serverless.
Думаешь: "Ну все, индустрия сделала огромный рывок, legacy в головах выветрилось, луддиты вышли на пенсию, костяк индустрии - 25-летние смузихлебы, программирующие на Lambda'ах и YAML'ах."
А потом видишь анонс, как в консоли можно в один клик подружить виртуалку и RDS экземпляр.
В КОНСОЛИ, Карл, мы все еще меняем что-то в КОНСОЛИ.
AWS ругать тут не за что, раз сделали это, Babelfish и даже App2Container, значит ЦА с криптостартапов полностью освоена, и очередь дошла до малоподвижного enterprise сектора, который очень хочет модный клавд, но все предпочитает держать при себе штат облачных эникеев.
А AWS-то что, они как никак customer obsessed, про их уклон в сторону толстых Старых Денег я и раньше писал (пост никак не найду, но моя OG аудитория все помнит).
Удивительная компания AWS все-таки. Смотришь анонс какого-нибудь re:Invent или саммита, видишь сплошные bleeding edge технологии и сплошной serverless.
Думаешь: "Ну все, индустрия сделала огромный рывок, legacy в головах выветрилось, луддиты вышли на пенсию, костяк индустрии - 25-летние смузихлебы, программирующие на Lambda'ах и YAML'ах."
А потом видишь анонс, как в консоли можно в один клик подружить виртуалку и RDS экземпляр.
В КОНСОЛИ, Карл, мы все еще меняем что-то в КОНСОЛИ.
AWS ругать тут не за что, раз сделали это, Babelfish и даже App2Container, значит ЦА с криптостартапов полностью освоена, и очередь дошла до малоподвижного enterprise сектора, который очень хочет модный клавд, но все предпочитает держать при себе штат облачных эникеев.
А AWS-то что, они как никак customer obsessed, про их уклон в сторону толстых Старых Денег я и раньше писал (пост никак не найду, но моя OG аудитория все помнит).
🔥3🤔2
#пятничное
Волею судьбы оказался на пианинном концерте, от которого получил колоссальное удовольствие.
И дело даже не в акустике или классике, не в композициях и экспрессии, но в интересном опыте.
Перфоманс давали два пианиста Анна Федорова и Йорун фан Вейн. Играли они преимущественно по очереди Рахманинова, Шопена и Эйнауди, но некоторые композиции играли практически в унисон, а их парная игра была не синхронная...
Асинхронная. Какую-то партию отыгрывает Анна, за которой подхватывает Йорун, какую-то наоборот она же поддакивает. По ощущениям получился диалог не двух музыкантов, а двух персонажей произведения, которое я, притаившись за спинкой сидения, слушал.
Очень интересный опыт, который надеюсь повторить.
Волею судьбы оказался на пианинном концерте, от которого получил колоссальное удовольствие.
И дело даже не в акустике или классике, не в композициях и экспрессии, но в интересном опыте.
Перфоманс давали два пианиста Анна Федорова и Йорун фан Вейн. Играли они преимущественно по очереди Рахманинова, Шопена и Эйнауди, но некоторые композиции играли практически в унисон, а их парная игра была не синхронная...
Асинхронная. Какую-то партию отыгрывает Анна, за которой подхватывает Йорун, какую-то наоборот она же поддакивает. По ощущениям получился диалог не двух музыкантов, а двух персонажей произведения, которое я, притаившись за спинкой сидения, слушал.
Очень интересный опыт, который надеюсь повторить.
👍13🤔5🔥2❤1
#машины_разное
В качестве дополнительной загруженности я помогаю студентам Яндекс.Практикума проходить обучение на курсе backend-разработки на Python.
Частью работы является чтение лекций, и вот на одной из лекций меня спросили о перспективах российского рынка труда для выпускников. Если убрать за рамки нюансы, нам и так известные, то вытекает вопрос: насколько Python в целом востребованный язык для коммерческой разработки?
Статистика говорит, что да, востребованный. Вакансий на рынке все еще хватает, на языке написано много, поддерживается тоже много, специализация у языка есть. Казалось бы, все нормально, иди да пиши.
С другой стороны, большие игроки активно инвестируют и развивают Go и Rust, в связи с чем предугадать, куда повернет голову свежий ветер смузи-трендов, сложно. Но тут мне вспомнилось одно обещание Гвидо Ван Россума сделать “родной” движок языка в два раза быстрее.
К чему я это в очередной раз вспомнил? Да к тому, что релиз 3.11 запланирован сегодня, а сами разработчики намерены устроить из этого шоу.
Надеюсь и верю, что это обновление даст второе дыхание на гонке за свое место под солнцем индустрии.
В качестве дополнительной загруженности я помогаю студентам Яндекс.Практикума проходить обучение на курсе backend-разработки на Python.
Частью работы является чтение лекций, и вот на одной из лекций меня спросили о перспективах российского рынка труда для выпускников. Если убрать за рамки нюансы, нам и так известные, то вытекает вопрос: насколько Python в целом востребованный язык для коммерческой разработки?
Статистика говорит, что да, востребованный. Вакансий на рынке все еще хватает, на языке написано много, поддерживается тоже много, специализация у языка есть. Казалось бы, все нормально, иди да пиши.
С другой стороны, большие игроки активно инвестируют и развивают Go и Rust, в связи с чем предугадать, куда повернет голову свежий ветер смузи-трендов, сложно. Но тут мне вспомнилось одно обещание Гвидо Ван Россума сделать “родной” движок языка в два раза быстрее.
К чему я это в очередной раз вспомнил? Да к тому, что релиз 3.11 запланирован сегодня, а сами разработчики намерены устроить из этого шоу.
Надеюсь и верю, что это обновление даст второе дыхание на гонке за свое место под солнцем индустрии.
👍17👎2
#жиза
Когда я писал книгу по CloudFormation, большую часть времени у меня заняла самая последняя и, как ни странно, самая маленькая глава.
Глава называется "What's Next", и в ней я надеваю шапочку визионера и думаю о прекрасной инфраструктуре будущего, как на смену CloudFormation неизбежно приходит CDK, как CDK создает тот самый мост между инфраструктурой и приложением с помощью Assets, и что будет после.
10 страниц текста я выдавливал из себя как мог и потратил на это почти весь срок. А все потому что писать об известных и существующих легко и предсказуемо - переписывать документацию на понятный слог или делиться опытом много ума не требуется.
Другое дело писать о том, что еще не случилось. Да и визионерство от фантазий отличается именно тем, что видение может стать реальностью, если приложить к этому усилия и придать правильное направление.
А значит, витая в облаках, нужно оставаться реалистом, да и растягивать свое видение дольше чем на 10 лет вперед точно не стоит. И без того в неспокойное время живем.
Когда я писал книгу по CloudFormation, большую часть времени у меня заняла самая последняя и, как ни странно, самая маленькая глава.
Глава называется "What's Next", и в ней я надеваю шапочку визионера и думаю о прекрасной инфраструктуре будущего, как на смену CloudFormation неизбежно приходит CDK, как CDK создает тот самый мост между инфраструктурой и приложением с помощью Assets, и что будет после.
10 страниц текста я выдавливал из себя как мог и потратил на это почти весь срок. А все потому что писать об известных и существующих легко и предсказуемо - переписывать документацию на понятный слог или делиться опытом много ума не требуется.
Другое дело писать о том, что еще не случилось. Да и визионерство от фантазий отличается именно тем, что видение может стать реальностью, если приложить к этому усилия и придать правильное направление.
А значит, витая в облаках, нужно оставаться реалистом, да и растягивать свое видение дольше чем на 10 лет вперед точно не стоит. И без того в неспокойное время живем.
👍20👎1
#деньги
Ребрендированный Meta Pay на стероидах, накопительные счета в Apple Pay, бодание между банками и платежными сетями - все это интересные движения, которые мне говорят о следующем:
1. Прямой интерес платежных сетей (Visa, MC, AmEx) - объемы операций. На объем явно стали зариться остальные участники рынка.
2. Big Tech хочет большую часть платежного процессинга внутрь себя. Это вполне осмысленно, на определенных объемах пользоваться внешним PSP становится слишком дорого.
3. Big Tech хочет взять на себя функции банка.
Все эти три пункта вызывают у меня определенные опасения, это во мне шапочка из фольги говорит.
Но я с подозрением отношусь к концепции “быстрые и бесплатные платежи для потребителя”. Видите ли, стоимость транзакции закладывается в стоимость товара, за процессинг чаще всего платит эквайер и берет свою “мзду” с продавца.
Если же цена транзакции не закладывается в продукт - а платежные сервисы технологических компаний такое не предусматривают - то возникают разные вопросы, ответы на которые я не хочу получать.
Ребрендированный Meta Pay на стероидах, накопительные счета в Apple Pay, бодание между банками и платежными сетями - все это интересные движения, которые мне говорят о следующем:
1. Прямой интерес платежных сетей (Visa, MC, AmEx) - объемы операций. На объем явно стали зариться остальные участники рынка.
2. Big Tech хочет большую часть платежного процессинга внутрь себя. Это вполне осмысленно, на определенных объемах пользоваться внешним PSP становится слишком дорого.
3. Big Tech хочет взять на себя функции банка.
Все эти три пункта вызывают у меня определенные опасения, это во мне шапочка из фольги говорит.
Но я с подозрением отношусь к концепции “быстрые и бесплатные платежи для потребителя”. Видите ли, стоимость транзакции закладывается в стоимость товара, за процессинг чаще всего платит эквайер и берет свою “мзду” с продавца.
Если же цена транзакции не закладывается в продукт - а платежные сервисы технологических компаний такое не предусматривают - то возникают разные вопросы, ответы на которые я не хочу получать.
👍2🔥1
#машины_разное #деньги
Что-то катастрофически пошло не так в момент, когда сервисы стали показывать абсолютно бесполезное “Oops, something went wrong” в браузерах и мобильных приложениях.
Начнем с очевидного. Все эти бесполезные “Oops” прилетают, когда где-то в глубинах бизнес логики стреляет необработанное исключение. Логика у всех backend’ов для таких случаев тупа как пробка - тащим 5ХХ на самый вверх до клиента. Клиент видит “Oops”.
Backend тоже не лыком шит, от одной ошибки он складывать лапки не станет. Внутри этих ваших распределенных систем есть повторы, проверка контекста, DLQ и прочие механизмы обеспечения гарантированности транзакций. Ошибки же бывают retryable/повторяемые (пакет на сети потеряли, можем повторить) и nonretryable/неповторяемые (система лежит и не выкупает, что делать). Очевидно, когда надо использовать то или иное.
Проблемы могут быть и внешними, например, запросы к поставщикам. И вот тут мякотка.
Допустим, поставщик принес вам неприятный ответ, который вы не смогли обработать. Вы, конечно же, стреляете 500-ыми, ответ с ошибкой идет вплоть до клиента, клиент видит “Я не шмогла, попробуй еще попозже”. Вот это “попробуй еще попозже” называется user retryable, т.е. бекэнд как бы не смог обработать, что там ему поставщик брякнул, но поставщик проспится и все будет хорошо.
Вроде все круто, да?
А что если та ошибка, которую вернули клиенту, неповторяемая? Например, наш поставщик VISA вернул нам ошибку, что карта устарела или банковский счет заблокирован. Мы не умеем корректно обрабатывать такие отбивки и отправляем клиенту наверх 500-ый. Клиент пробует снова, но счета от таких повторов не разблокируются, а срок годности карточек не продлевается. Более того, можно еще и за abuse отхватить.
VISA, кстати, за попытки повторить невалидные транзакции штрафует коммерсанта. Коммерсант страдает, но клиент-то ни сном, ни духом и жмякает да жмякает кнопочку “оплатить”. И ловит, да ловит “Упс, самфин вент вронг” и бомбит. А коммерсант за это пенни штрафные платит.
К чему я это все? Возвращайте нормальные ошибки клиентам, пожалуйста.
Что-то катастрофически пошло не так в момент, когда сервисы стали показывать абсолютно бесполезное “Oops, something went wrong” в браузерах и мобильных приложениях.
Начнем с очевидного. Все эти бесполезные “Oops” прилетают, когда где-то в глубинах бизнес логики стреляет необработанное исключение. Логика у всех backend’ов для таких случаев тупа как пробка - тащим 5ХХ на самый вверх до клиента. Клиент видит “Oops”.
Backend тоже не лыком шит, от одной ошибки он складывать лапки не станет. Внутри этих ваших распределенных систем есть повторы, проверка контекста, DLQ и прочие механизмы обеспечения гарантированности транзакций. Ошибки же бывают retryable/повторяемые (пакет на сети потеряли, можем повторить) и nonretryable/неповторяемые (система лежит и не выкупает, что делать). Очевидно, когда надо использовать то или иное.
Проблемы могут быть и внешними, например, запросы к поставщикам. И вот тут мякотка.
Допустим, поставщик принес вам неприятный ответ, который вы не смогли обработать. Вы, конечно же, стреляете 500-ыми, ответ с ошибкой идет вплоть до клиента, клиент видит “Я не шмогла, попробуй еще попозже”. Вот это “попробуй еще попозже” называется user retryable, т.е. бекэнд как бы не смог обработать, что там ему поставщик брякнул, но поставщик проспится и все будет хорошо.
Вроде все круто, да?
А что если та ошибка, которую вернули клиенту, неповторяемая? Например, наш поставщик VISA вернул нам ошибку, что карта устарела или банковский счет заблокирован. Мы не умеем корректно обрабатывать такие отбивки и отправляем клиенту наверх 500-ый. Клиент пробует снова, но счета от таких повторов не разблокируются, а срок годности карточек не продлевается. Более того, можно еще и за abuse отхватить.
VISA, кстати, за попытки повторить невалидные транзакции штрафует коммерсанта. Коммерсант страдает, но клиент-то ни сном, ни духом и жмякает да жмякает кнопочку “оплатить”. И ловит, да ловит “Упс, самфин вент вронг” и бомбит. А коммерсант за это пенни штрафные платит.
К чему я это все? Возвращайте нормальные ошибки клиентам, пожалуйста.
👍35❤3
#машины_разное
Недавно Коля (@mykola7799) написал с вопросом, не знаю ли я кого из разработчиков YDB. Пока мы с ним обсуждали, что за прекрасная СУБД эта ваша ЙДБ, возник дискуссионный момент - раз УайДиБи распределенная СУБД, и она поддерживает ACID-транзакции, то она нарушает САР.
И тут я крепко призадумался, потому что САР нарушить невозможно.
Перво-наперво попытавшись найти, что о месте YDB в самой CAP думают сами разработчики, я быстро разочаровался, и стал додумывать. Благо долго не пришлось.
Мы часто думаем про С (консистентность) и А (доступность), но забываем про P (partition tolerance - не знаю, как правильно перевести). Partition tolerance подразумевает, что при разрывах в сети система будет обслуживать трафик в штатном режиме.
Тут все сразу встало на места. Если предположить, что YDB обеспечивает строгую консистентность в пределах одного региона, то эта "строгость" сразу валится, так как транзакция до соседнего узла не долетела из-за кратковременного разрыва в сети.
Узел же, конечно, об этом ничего не знает и искренне верит, что вернул нам консистентные данные... но об этом вы уже читали в кабанчике.
В комментарии приглашаются причастные к YDB, подтвердить/опровергнуть мое мнение. Да и Коля хочет познакомиться!
P.S. Надо уже взять себя в руки и написать уже про это вашу строгую консистентность в распределенных системах.
Недавно Коля (@mykola7799) написал с вопросом, не знаю ли я кого из разработчиков YDB. Пока мы с ним обсуждали, что за прекрасная СУБД эта ваша ЙДБ, возник дискуссионный момент - раз УайДиБи распределенная СУБД, и она поддерживает ACID-транзакции, то она нарушает САР.
И тут я крепко призадумался, потому что САР нарушить невозможно.
Перво-наперво попытавшись найти, что о месте YDB в самой CAP думают сами разработчики, я быстро разочаровался, и стал додумывать. Благо долго не пришлось.
Мы часто думаем про С (консистентность) и А (доступность), но забываем про P (partition tolerance - не знаю, как правильно перевести). Partition tolerance подразумевает, что при разрывах в сети система будет обслуживать трафик в штатном режиме.
Тут все сразу встало на места. Если предположить, что YDB обеспечивает строгую консистентность в пределах одного региона, то эта "строгость" сразу валится, так как транзакция до соседнего узла не долетела из-за кратковременного разрыва в сети.
Узел же, конечно, об этом ничего не знает и искренне верит, что вернул нам консистентные данные... но об этом вы уже читали в кабанчике.
В комментарии приглашаются причастные к YDB, подтвердить/опровергнуть мое мнение. Да и Коля хочет познакомиться!
P.S. Надо уже взять себя в руки и написать уже про это вашу строгую консистентность в распределенных системах.
👍12🔥3❤1
#пятничное
Читать, в наше неспокойное время, жизненная необходимость, и я стараюсь разбавлять свой опыт художественной литературой.
Не большой фанат классики и "обязательных" произведений, и к своему стыду я открыл Хемингуэйа только недавно, когда думал, что загрузить в читалку в отпуск.
Поиск "лучшее из литературы" очевидно выдал мне "По ком звонит колокол", а заодно рассказал, что Эрнест лауреат нобелевки.
Абсолютно не проникся и читаю "Колокол" только для галочки, не люблю бросать начатые книги. Жизнью Хемингуэйа тоже не заинтересовался (знал только, что он застрелился из дробовика), пока не нарвался на ультракороткую биографию.
Чем и делюсь с вами.
Читать, в наше неспокойное время, жизненная необходимость, и я стараюсь разбавлять свой опыт художественной литературой.
Не большой фанат классики и "обязательных" произведений, и к своему стыду я открыл Хемингуэйа только недавно, когда думал, что загрузить в читалку в отпуск.
Поиск "лучшее из литературы" очевидно выдал мне "По ком звонит колокол", а заодно рассказал, что Эрнест лауреат нобелевки.
Абсолютно не проникся и читаю "Колокол" только для галочки, не люблю бросать начатые книги. Жизнью Хемингуэйа тоже не заинтересовался (знал только, что он застрелился из дробовика), пока не нарвался на ультракороткую биографию.
Чем и делюсь с вами.
🔥4👍1
#пятничное
Когда в моей конторе произошел один инцидент, и в массмедия и соцсети просочились скриншоты внутренних продуктов и инструментов, в Твиттер и LinkedIn скопом хлынули улюлюкающие эксперты, и все знали, что у нас произошло на самом деле, как нам нужно строить безопасность, кого нанимать и так далее.
Нам строго настрого запретили обсуждать произошедшее, и мне ничего не оставалось, как скрипя зубами фейспалмить.
И вот спустя какое-то время Илон Маск на вороном коне врывается в Твиттер, увольняет толпы народу и начинает агрессивную депрекацию всего, что плохо лежит.
ИТ тусовочка Твиттера, конечно же, негодует, ведь Твиттер это сложный planet-scale, писали его очень умные люди, и так далее. В очередной раз я вижу, как вчерашние эксперты по безопасности, сегодня обсуждают тонкости распределенных систем и сложности микросервисной архитектуры.
Комментируют это только бывшие сотрудники, и я догадываюсь, почему.
Когда в моей конторе произошел один инцидент, и в массмедия и соцсети просочились скриншоты внутренних продуктов и инструментов, в Твиттер и LinkedIn скопом хлынули улюлюкающие эксперты, и все знали, что у нас произошло на самом деле, как нам нужно строить безопасность, кого нанимать и так далее.
Нам строго настрого запретили обсуждать произошедшее, и мне ничего не оставалось, как скрипя зубами фейспалмить.
И вот спустя какое-то время Илон Маск на вороном коне врывается в Твиттер, увольняет толпы народу и начинает агрессивную депрекацию всего, что плохо лежит.
ИТ тусовочка Твиттера, конечно же, негодует, ведь Твиттер это сложный planet-scale, писали его очень умные люди, и так далее. В очередной раз я вижу, как вчерашние эксперты по безопасности, сегодня обсуждают тонкости распределенных систем и сложности микросервисной архитектуры.
Комментируют это только бывшие сотрудники, и я догадываюсь, почему.
🔥17👍3👎2❤1