#деньги #машины_разное
В стандарте 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
#машины_aws
Теперь, когда у нас есть AWS SDK для SAP ABAP, какой язык будет следующим?
Ставлю на COBOL.
Теперь, когда у нас есть AWS SDK для SAP ABAP, какой язык будет следующим?
Ставлю на COBOL.
😱7👍4
#машины_aws
Особо за re:Invent не слежу, потому что вкатился в backend разработку, а с AWS'ом дел имею редко.
Но вот эту красоту я ждал давно и долго, и это просто потрясающе, что амазонцы раз и навсегда убрали необходимость писать так называемые glue функции Lambda, которые берутжсон событие из одного места и кладут в другое. Пушка!
Особо за re:Invent не слежу, потому что вкатился в backend разработку, а с AWS'ом дел имею редко.
Но вот эту красоту я ждал давно и долго, и это просто потрясающе, что амазонцы раз и навсегда убрали необходимость писать так называемые glue функции Lambda, которые берут
Amazon
Amazon EventBridge Pipes is now generally available
👍6
#машины_разное #жиза
У меня увольняется коллега, и я как-то спросил его за перерывом на смузи с тапиокой (перечитал, что написал, и самого передернуло), ради чего он уходит на новое место.
Коллега, надо уточнить, уходит из Убера в логистическую контору масштабом поменьше, но на должность повыше, из Staff'ов в Senior Staff'ы.
И вот одним из аргументов было следующее: хочется работать с разными технологиями напрямую, а у нас в Убере все абстрагировано, автоматизировано, ощущения не те и вообще скучно. А в новой конторе все опенсорсное, работы валом, строй - не хочу.
Я про себя тогда хмыкнул: кто ж тебе, сеньор стаффу, делать что-то руками даст, ты же очень дорого!
Здравое зерно, тем не менее, есть. В масштабах Убера выгоднее держать отдельную команду "кафкистов", которая сделает большой большой кластер кластеров на все случаи жизни, напишет своего клиента и UI, который на десять слоев абстракций спрячет от меня все тяготы работы.
Мне такое в только в радость, пара кликов и команд, и все красиво само работает из коробки.
А моему, почти бывшему, коллеге скучно и хочется не терять технических скиллзов.
У меня увольняется коллега, и я как-то спросил его за перерывом на смузи с тапиокой (перечитал, что написал, и самого передернуло), ради чего он уходит на новое место.
Коллега, надо уточнить, уходит из Убера в логистическую контору масштабом поменьше, но на должность повыше, из Staff'ов в Senior Staff'ы.
И вот одним из аргументов было следующее: хочется работать с разными технологиями напрямую, а у нас в Убере все абстрагировано, автоматизировано, ощущения не те и вообще скучно. А в новой конторе все опенсорсное, работы валом, строй - не хочу.
Я про себя тогда хмыкнул: кто ж тебе, сеньор стаффу, делать что-то руками даст, ты же очень дорого!
Здравое зерно, тем не менее, есть. В масштабах Убера выгоднее держать отдельную команду "кафкистов", которая сделает большой большой кластер кластеров на все случаи жизни, напишет своего клиента и UI, который на десять слоев абстракций спрячет от меня все тяготы работы.
Мне такое в только в радость, пара кликов и команд, и все красиво само работает из коробки.
А моему, почти бывшему, коллеге скучно и хочется не терять технических скиллзов.
👍25🤔4
#машины_разное #люди
У меня в черновиках лежит блог о прекрасном будущем инфраструктуры, где приложение будет волшебным образом само себя разворачивать, масштабировать, деградировать, включать и выключать, и так далее.
Я думал уже закончить над ним работу и опубликовать, но потом понял, что это будущее наступит нескоро. Индустрия сделала мертвую петлю и вернула нам системных администраторов.
Вернемся на 30 лет назад. Типичный сисадмин, в зависимости от размеров и специфики конторы, отвечает за программно-аппаратный комплекс в определенной степени. Если представить себе торт из таких слоев: приложение - зависимости - midlleware (читай, какая-нибудь WebSphere/Weblogic) - ОС - прошивка железа - железо; то сисадмин владеет всем до midlleware.
Затем происходит НЕЧТО, из-за чего сисадмин учится масштабировать свою работу и берет на себя роли build и release инженера, начинает тащить всякие Jenkins’ы с Ansible’ми. Граница "владения" медленно ползет вверх, наш сисадмин чуть ли не сам код уже пишет, а некоторые и пишут!
Затем опять происходит НЕЧТО, и сисадмины на время исчезают. Теперь у нас есть инженер, который управляет какой-то облачной инфраструктурой, суть-то программируемыми абстракциями. Дай мне виртуальную сеть, виртуальную машину, виртуальную оркестрацию контейнеров, виртуальный кластер баз данных - словом, инфраструктура вроде как есть, но ей и управлять особо не надо. Тогда сисадмин, а ныне модный SRE/DevOps инженер может выступать в двух ипостасях.
Одна ипостась красиво управляет всем этим зоопарком, тратя на саму работу 10-20% своего времени, другая побросала эту скучную работу и активно пишет тот же промышленный код, инвестируя в его надежность.
Облачные провайдеры вовсю продают fully managed сервисы; всерьез идут разговоры о NoOps и даже Low Code; машинное обучение подсказывает готовый код; я заношу виртуальное перо над своим блогом, ведь вот она, эта прекрасная индустрия будущего!..
Как вдруг мою виртуальную руку с виртуальным пером нежно хватает незнакомец в маске. На ней красивым шрифтом светится надпись Platform Engineer, и незнакомец, медленно качая головой, говорит: "Еще рано." Я с недоумением смотрю на него, но погодя на меня снисходит озарение. Я снимаю маску с гостя и узнаю в нем того самого Системного Администратора!
ОК, лирику в сторону. По сути, индустрия как могла выживала сисадминов с рынка, но в итоге научила их программировать, работать с потребителями и предоставлять продукты с самообслуживанием для удобства разработчиков.
Раньше сисадмин давал вам проприетарный интерфейс VMware с минимальным доступом к созданию виртуалок в своем пуле ресурсов, а теперь у вас есть красивый удобный UI и куча автоматики, чтобы вам не приходилось думать лишний раз.
Тупиковая ли это ветвь эволюции или еще один виток, покажет история.
У меня в черновиках лежит блог о прекрасном будущем инфраструктуры, где приложение будет волшебным образом само себя разворачивать, масштабировать, деградировать, включать и выключать, и так далее.
Я думал уже закончить над ним работу и опубликовать, но потом понял, что это будущее наступит нескоро. Индустрия сделала мертвую петлю и вернула нам системных администраторов.
Вернемся на 30 лет назад. Типичный сисадмин, в зависимости от размеров и специфики конторы, отвечает за программно-аппаратный комплекс в определенной степени. Если представить себе торт из таких слоев: приложение - зависимости - midlleware (читай, какая-нибудь WebSphere/Weblogic) - ОС - прошивка железа - железо; то сисадмин владеет всем до midlleware.
Затем происходит НЕЧТО, из-за чего сисадмин учится масштабировать свою работу и берет на себя роли build и release инженера, начинает тащить всякие Jenkins’ы с Ansible’ми. Граница "владения" медленно ползет вверх, наш сисадмин чуть ли не сам код уже пишет, а некоторые и пишут!
Затем опять происходит НЕЧТО, и сисадмины на время исчезают. Теперь у нас есть инженер, который управляет какой-то облачной инфраструктурой, суть-то программируемыми абстракциями. Дай мне виртуальную сеть, виртуальную машину, виртуальную оркестрацию контейнеров, виртуальный кластер баз данных - словом, инфраструктура вроде как есть, но ей и управлять особо не надо. Тогда сисадмин, а ныне модный SRE/DevOps инженер может выступать в двух ипостасях.
Одна ипостась красиво управляет всем этим зоопарком, тратя на саму работу 10-20% своего времени, другая побросала эту скучную работу и активно пишет тот же промышленный код, инвестируя в его надежность.
Облачные провайдеры вовсю продают fully managed сервисы; всерьез идут разговоры о NoOps и даже Low Code; машинное обучение подсказывает готовый код; я заношу виртуальное перо над своим блогом, ведь вот она, эта прекрасная индустрия будущего!..
Как вдруг мою виртуальную руку с виртуальным пером нежно хватает незнакомец в маске. На ней красивым шрифтом светится надпись Platform Engineer, и незнакомец, медленно качая головой, говорит: "Еще рано." Я с недоумением смотрю на него, но погодя на меня снисходит озарение. Я снимаю маску с гостя и узнаю в нем того самого Системного Администратора!
ОК, лирику в сторону. По сути, индустрия как могла выживала сисадминов с рынка, но в итоге научила их программировать, работать с потребителями и предоставлять продукты с самообслуживанием для удобства разработчиков.
Раньше сисадмин давал вам проприетарный интерфейс VMware с минимальным доступом к созданию виртуалок в своем пуле ресурсов, а теперь у вас есть красивый удобный UI и куча автоматики, чтобы вам не приходилось думать лишний раз.
Тупиковая ли это ветвь эволюции или еще один виток, покажет история.
👍13🔥4❤1
#машины_разное
Тонкое искусство наблюдаемости (оно же observability), прошло не один десяток лет, прежде чем заматереть.
Поначалу был дубовый мониторинг - смотрели данные датчиков, состояние железа и процессов ОС, затем научили приложение рапортовать о своем состоянии теми же метриками.
После SRE научил не просто мерять сигналы, а выработать некий стандарт из 4 золотых сигналов , тот же Брендан Грегг использует метод USE (Utilisation/Saturation/Errors) для выявления проблем с производительностью.
Потом пришли трассировки и структурированные широкие события, и наблюдаемость стала сама по себе отдельной сложной дисциплиной, как, впрочем, бывает с любым витком эволюции любой практики в ИТ.
Если отвлечься от технической части, то наблюдаемость нам нужна, чтобы ответить на вопрос “Оно работает?”, и этот вопрос куда сложнее, чем многие думают.
Автор этих строк помнит активные дискуссии на том же Хабре и тематических чатах времен 2014-2018, когда сильные умы мира сего задавали эти титанически сложные вопросы “А что значит не работает?”, “А что мы понимаем под работой?” или мое любимое “А когда оно у вас в последний раз работало?”.
Очевидно, что работающая система это та, которая выполняет свои задачи. Система может работать в нормальном или деградированном режиме, может совсем не работать, тут уже как мы контракты написали. Для того, чтобы определять “рабочесть” у нас есть огромный пласт методов и инструментов. Все они направлены на то, чтобы научить приложение говорить от своего лица о своем самочувствии, так что в целом все логично.
Но я не зря написал про толкования “рабочести” и изменчивость нашей индустрии. Видите ли, система может быть по всем фронтам “здоровой”, значения метрик приемлемыми, пейджер тихим, дежурство спокойным… А система все равно не будет работать! 😱
Вернемся к предыдущему толкованию “работает” - т.е. система выполняет свои функции. Функции, как мы понимаем, получаются из запросов бизнеса в виде ТЗ, историй и чего бы то ни было, но задача системы - выполнять задачу бизнеса. И вот тут может быть функциональный казус, когда система вроде бы и работает, но задач своих не выполняет.
Определить это немногим сложнее, чем набросать метрик и логов в нужных местах нашего кода. Достаточно взять бизнес-метрики на определенные процессы, строить по ним графики, выявлять аномалии и несовпадения. Лукавить не стану, на практике это не так тривиально, как на словах.
Например, если у нас есть определенный SLA на техподдержку, то рабочая система такая: 10 человек завели по жалобе, 10 жалоб создалось, 10 жалоб получили по назначенному специалисту ТП, 10 жалоб разрешилось в рамках SLA. Любое отклонение - вне зависимости от причин - является симптомом нерабочей системы. 🎉
---
Вижу новую главу наблюдаемости, которая так и просится стать очередным трендом. Я, можно сказать, только только ступаю на эту новую землю и надеюсь, поделиться своими результатами и наблюдениями в корпоративном блоге, но моей аудитории предлагаю почитать, ну или послушать, как это делают в одной экстремистской, согласно некоторым законам, организации.
С наступающим!
Тонкое искусство наблюдаемости (оно же observability), прошло не один десяток лет, прежде чем заматереть.
Поначалу был дубовый мониторинг - смотрели данные датчиков, состояние железа и процессов ОС, затем научили приложение рапортовать о своем состоянии теми же метриками.
После SRE научил не просто мерять сигналы, а выработать некий стандарт из 4 золотых сигналов , тот же Брендан Грегг использует метод USE (Utilisation/Saturation/Errors) для выявления проблем с производительностью.
Потом пришли трассировки и структурированные широкие события, и наблюдаемость стала сама по себе отдельной сложной дисциплиной, как, впрочем, бывает с любым витком эволюции любой практики в ИТ.
Если отвлечься от технической части, то наблюдаемость нам нужна, чтобы ответить на вопрос “Оно работает?”, и этот вопрос куда сложнее, чем многие думают.
Автор этих строк помнит активные дискуссии на том же Хабре и тематических чатах времен 2014-2018, когда сильные умы мира сего задавали эти титанически сложные вопросы “А что значит не работает?”, “А что мы понимаем под работой?” или мое любимое “А когда оно у вас в последний раз работало?”.
Очевидно, что работающая система это та, которая выполняет свои задачи. Система может работать в нормальном или деградированном режиме, может совсем не работать, тут уже как мы контракты написали. Для того, чтобы определять “рабочесть” у нас есть огромный пласт методов и инструментов. Все они направлены на то, чтобы научить приложение говорить от своего лица о своем самочувствии, так что в целом все логично.
Но я не зря написал про толкования “рабочести” и изменчивость нашей индустрии. Видите ли, система может быть по всем фронтам “здоровой”, значения метрик приемлемыми, пейджер тихим, дежурство спокойным… А система все равно не будет работать! 😱
Вернемся к предыдущему толкованию “работает” - т.е. система выполняет свои функции. Функции, как мы понимаем, получаются из запросов бизнеса в виде ТЗ, историй и чего бы то ни было, но задача системы - выполнять задачу бизнеса. И вот тут может быть функциональный казус, когда система вроде бы и работает, но задач своих не выполняет.
Определить это немногим сложнее, чем набросать метрик и логов в нужных местах нашего кода. Достаточно взять бизнес-метрики на определенные процессы, строить по ним графики, выявлять аномалии и несовпадения. Лукавить не стану, на практике это не так тривиально, как на словах.
Например, если у нас есть определенный SLA на техподдержку, то рабочая система такая: 10 человек завели по жалобе, 10 жалоб создалось, 10 жалоб получили по назначенному специалисту ТП, 10 жалоб разрешилось в рамках SLA. Любое отклонение - вне зависимости от причин - является симптомом нерабочей системы. 🎉
---
Вижу новую главу наблюдаемости, которая так и просится стать очередным трендом. Я, можно сказать, только только ступаю на эту новую землю и надеюсь, поделиться своими результатами и наблюдениями в корпоративном блоге, но моей аудитории предлагаю почитать, ну или послушать, как это делают в одной экстремистской, согласно некоторым законам, организации.
С наступающим!
👍10🔥5
Своих дорогих читателей, соратников и друзей, я хочу поздравить с наступающим, а для кого-то наступившим Новым Годом!
Оставайтесь здоровыми и находитесь в кругу близких вам людей и союзников. Пусть 2023 будет к вам благосклонен!
Мирного неба над головой!!
Искренне ваш,
Чел и Маш. :)
❤29🔥22👍7
#машины_разное
Я посмотрел на The state of open source software и заметил пару очень интересных моментов, которыми хочу с вами поделиться.
Python выбился на второе место среди популярных языков.
Обещания Гвидо ускорить Python не прошли даром, да и высокий тренд на машинное обучение подпитывает популярность языка. Прибавьте к этому растущее количество bootcamp’ов, воспитывающих новое поколение инженеров с нуля и использующих этот язык с его низким порогом вхождения, и получите закономерный результат.
Конторы продолжают инвестировать в open source.
Что не новость, да и хитрость. Такие проекты повышают имидж и привлекают большое количество бесплатной рабочей силы. 🙂
HCL - самый быстрорастущий язык на GitHub.
Вот это очень интересно при условии, что HCL не язык программирования, а DSL. 🙂 Что однако не мешает писать на нем скрипты, судя по его README.
Я посмотрел на The state of open source software и заметил пару очень интересных моментов, которыми хочу с вами поделиться.
Python выбился на второе место среди популярных языков.
Обещания Гвидо ускорить Python не прошли даром, да и высокий тренд на машинное обучение подпитывает популярность языка. Прибавьте к этому растущее количество bootcamp’ов, воспитывающих новое поколение инженеров с нуля и использующих этот язык с его низким порогом вхождения, и получите закономерный результат.
Конторы продолжают инвестировать в open source.
Что не новость, да и хитрость. Такие проекты повышают имидж и привлекают большое количество бесплатной рабочей силы. 🙂
HCL - самый быстрорастущий язык на GitHub.
Вот это очень интересно при условии, что HCL не язык программирования, а DSL. 🙂 Что однако не мешает писать на нем скрипты, судя по его README.
🔥7👍1
#машины_aws
У меня есть программа, которая выполняет следующее действие:
Мозгом я понимаю, что мой код сделает вызов
Запускаю код, получаю следующую ошибку:
Неожиданно! Окей, Гугл, какие еще действия нужно добавить в политику? Беглый поиск привел меня в StackOverflow, где решением было, конечно же, дать EC2FullAccess.
"Вздор!" - подумал я, сходил в документацию и увидел там тоже самое. 🤦♂️
У меня есть программа, которая выполняет следующее действие:
def pin_lt_version_to_asg(asg, asg_name, lt_name, lt_version):
return asg.update_auto_scaling_group(
AutoScalingGroupName=asg_name,
LaunchTemplate={
'LaunchTemplateName': lt_name,
'Version': lt_version,
},
)
Мозгом я понимаю, что мой код сделает вызов
autoscaling:UpdateAutoScalingGroup, и разрешаю это действие в IAM. Запускаю код, получаю следующую ошибку:
botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the UpdateAutoScalingGroup operation: You are not authorized to use launch template: myTemplate
Неожиданно! Окей, Гугл, какие еще действия нужно добавить в политику? Беглый поиск привел меня в StackOverflow, где решением было, конечно же, дать EC2FullAccess.
"Вздор!" - подумал я, сходил в документацию и увидел там тоже самое. 🤦♂️
🔥12😱8👍5
#машины_разное
Утечки утечками, а в этом коде еще разобраться надо будет!
Из очевидного вижу статический анализ кода на какие-нибудь CVE + захардкоженные секреты.
Сам код у себя поднимать смысла нет, намучаетесь с зависимостями и внутренними инструментами сборки.
Безопасникам Яндекса сил и терпения. Разгребать это придется долго, знаю по печальному опыту.
Утечки утечками, а в этом коде еще разобраться надо будет!
Из очевидного вижу статический анализ кода на какие-нибудь CVE + захардкоженные секреты.
Сам код у себя поднимать смысла нет, намучаетесь с зависимостями и внутренними инструментами сборки.
Безопасникам Яндекса сил и терпения. Разгребать это придется долго, знаю по печальному опыту.
Хабр
Утечка исходных кодов сервисов Яндекс
25 января 2023 в сети появились исходные коды и сопутствующие им данные множества сервисов и программ компании Яндекс. Раздача содержит отдельные архивы (.tar.bz2), по названиям которых можно...
👍4👎1