Продолжим. Автор сделал два важных тезиса:
- Инженер неизбежно деградирует и отказывается улучшать решение.
- Архитектор/Менеджер неизбежно деградирует и теряет мягкие скиллы

Тут надо учитывать важный момент, а именно: никто не предлагает делать свою работу плохо. А если человек осознанно делает свою работу плохо, то в консалтинге к нему применяются те же методы стимуляции, что и в других компаниях.

Второе, на что стоит обращать внимание, это почему решение неэффективное. Со стороны удобно бросаться замечаниями о плохой/кривой/немасштабируемой/и т.д. архитектуре/инфраструктуре (чем ваш покорный очень любит заниматься), но стоит начать копаться в истории, так сразу всплывают всевозможные trade off’ы и ограничения, которых избежать не удалось.

Третье - завышенное ЧСВ и эго не имеет никакого отношения к сфере, в которой работает человек, и более того - подход “я - начальник, ты - дурак” присутствовал и до сих присутствует во всевозможного вида конторах. Честности ради, у себя на проекте я его не наблюдаю, но зовите меня выжившим с ошибками.

У консалтинга по факту есть два минуса. Очень серьезных минуса, о которых мало кто знает.

Во-первых, невсегда идет правильная работа с заказчиком. Используется подход “любой каприз за ваши деньги”, хотя по-хорошему заказчику нужно коммуницировать все риски и последствия тех или иных решений - с цифрами и альтернативным решением. Впрочем, сговорчивые и либерально настроенные заказчики попадаются гораздо чаще упертых и принципиальных.

Во-вторых, при проектной работе часто присутствует жесткий стек технологий, который в консалтинге знает многие (чтобы ускорить onboarding новых людей на проект). Это ограничивает творческую свободу инженеров, которые хотят изучать и применять ту или иную хайповую технологию, но вынуждены ковыряться в legacy.

Хотя legacy и в продукте хватает.

Я тут только прочитал блог на тему WET - антонима DRY, который означает Write Everything Twice.

Совпадение или нет, но он написан фронтендером.

Вчера AWS выпустил Origin Shield для CloudFront - своей услуги CDN. Из названия мне показалось, что речь про некий экран, который позволит пользователю получать контент только от узлов CDN, блокируя трафик до origin, но на деле нововведение оказалось гораздо полезнее.

Origin Shield имплементирует дополнительный уровень кеширования, который позволит Edge локациям (географически распределенные точки присутствия CloudFront) обновлять свой локальный кеш не из origin, а непосредственно из этого слоя.

Иными словами, если вы расположились в eu-west-1 и настроили CloudFront на раздачу по всему миру, то все Edge локации будут запрашивать контент у ваших серверов в eu-west-1, тем самым создавая серьезную нагрузку на ваш origin. В случае с Origin Shield обновление кеша будет запрашиваться непосредственно с узлов CloudFront в eu-west-1, и только локальный CloudFront будет “мучать” ваш origin.

Такое решение лучше всего подходит для динамического контента, такого как видеостриминг. Имплементация единого слоя кеширования позволит уменьшить затраты на вычислительные мощности origin’ов или перенаправив их в другое русло, хоть на то же транскодирование видеоконтента.

Важно! Имейте в виде, что Origin Shield имеет добавочную стоимость, так что прежде чем радостно ставить галочку в консоли CloudFront сравните расходы на трафик с Origin Shield с трафиком и ценой на compute origin’а.

А то будете потом писать мне, что клавды клятые вас грабят.

#машины_разное

Как немногие из вас знают, я большой поклонник баз данных. А с недавних пор еще и поклонник того, что творится в их внутренностях.

Внутри СУБД реализован компонент под названием page cache (он же buffer pool, он же buffer cache - в разных СУБД и в разные времена оно называется по-разному, но суть та же). В это быстрое (потому что в памяти) и временное хранилище попадает транзакция, прежде чем закрепиться в бинарном логе, а затем уже и в файле данных на диске.

Page Cache во многих СУБД имплементирует ту самую комбинацию кеширований Lazy Loading и Write-Through. Свежий INSERT/UPDATE считается оттуда - Write-Through. SELECT, пришедший из диска, ляжет в него - Lazy Loading.

Однако читатели, сведущие во внутренностях *nix-подобных заметят - page cache присутствует не только в СУБД, он есть еще и в ОС! И будут совершенно правы. Linux kernel тоже кеширует page из диска в свободную оперативную память, чтобы эффективнее выполнять операции ввода/вывода (IO).

СУБД общается с хранилищем через Storage Engine, тот обращается к диску через VFS. Получается, что запрос от клиента идет по следующей цепочке: RDBMS Page Cache → OS Page Cache → Disk.

Совсем неэффективно, плюс дупликация информации, если один и тот же page хранится в кешах и СУБД, и ОС. Как же быть?

Вот здесь получился конфликт. Разработчики СУБД решили, что кеширование ОС им не нужно, и делают запросы в диск с использованием флага O_DIRECT, который говорит ядру: "Не смотри в своем кеше, отправь меня сразу в диск." Разумеется, одному финну это не понравилось, но консенсус не найден и вряд ли будет.

Для удобства читателей (вы у меня публика разных интересов), я буду в начале каждого поста указывать тэг, чтобы читатель не тратил время на то, что ему неинтересно:

- #машины_aws - посты и ссылки про один, никому неизвестный поставщик услуг.
- #машины_разное - посты и ссылки на то, что связано с техникой, но не AWS.
- #люди - про взаимодействие с людьми: коллеги, заказчики, партнеры, руководители, подчиненные - словом, коммуникации.
- #жиза - истории из жизни - например та, где меня одна девушка оговорила за крик "Черт побери!" при детях.
- #пятничное - что в голову лезет, но ни подо что не подходит.
- #анонсы - объявления о новых выступлениях, выпусках и т.д.
- #деньги - все о платежах, деньгах, банках, биржах и иже с ними.

#машины_aws

Коллеги, читатели, котики, приятели!

Напоминаю, что завтра я и мои коллеги по цеху из Нидерландов будут выступать на AWS Community Day Netherlands!

Регистрация все еще открыта!

#машины_aws

Кто не смог присутствовать лично, могут посмотреть мое выступление в записи.

#люди

Чем для меня примечателен недавно отгремевший AWS Community Day, так это тем, что это было мое первое публичное выступление на английском языке.

А я уже давно хотел попробовать свои презентейшон скилз на западном поприще.

Что очень понравилось в организации - всеобъемлющий пофигизм на то, как ты выглядишь дома, и что у тебя на заднем фоне. Если в рамках подготовки к DevOps Live 2020 от меня чуть ли не требовали поставить что-то за спиной, чтобы заныкать кровать, то на техническом прогоне с организаторами CommDay тем хватило, чтобы мое лицо было видно - “Ну кровать и кровать.”

В свою очередь порог вхождения мне совсем не понравился.

Видите ли, я не первый месяц пытался достучаться до нидерландской группы амазонщиков, чтобы набрать нужный “баланс”, с которым потом можно идти проситься в программы APN Ambassador и Community Builders. И пока я стучался в сообщество через публичные каналы, отправляя в Call-for-Papers форме один доклад за другим, “увиден” я был только в тот момент, когда получил статус “посла”, да и более того - председатели тусовки сами зашли в гости и предложили засветиться на Дне Сообщества.

Помимо на главной сцене засветились такие же “талантливые” докладчики, доклады которых были неприлично скучны, но конторы этих докладчиков выступали спонсорами.

Проще говоря, чтобы залететь с крутым докладом в русскоговорящую тусовку достаточно иметь крутой доклад. Тематические сообщества открыты новым лицам и свежим идеям (иначе как объяснить, что такой ноунейм, как я, оттарабанил на HighLoad++).


В нидерландской же тусовочке нужно иметь либо имя, либо спонсорский статус. И хоть необходимость спонсорства мне понятна, хотелось бы, чтоб у спонсоров был годный контент.

Флешмоб!

Не оплаченный пост🖖

Решил сделать подборку своих каналов в телеграме, здесь штук 10 нет т.к. там не часто пишут посты или же с мемами каналы, но думаю с мемами вы и так найдёте.

Спасибо авторам и людям, которые их ведут и обновляют❤️

@tech_b0lt_Genona
@alexmakus
@catops
@devopslibrary
@flant_ru
@linuxgram
@opensource_findings
@hacker_news_feed
@oleg_log
@oleg_fov
@generictalks
@overtimehate
@nosingularity
@cybershit
@bykvaadm
@sqaunderhood
@evilmartians
@sudo_rmrf
@bortlog
@qaload
@lovely_it_hell
@badoo_tech
@buhtig
@opennet_ru
@razborfeed
@automation_remarks
@experimentalchill
@itgram_channel
@manandthemachine
@good_bad_reviewer
@sec_devops
@tmfeed
@your_tech
@werf_ru_notifications

#люди

Я знаю, что вы ждете продолжение моего блога про DynamoDB. Пока я хотел бы обсудить с вами такой важный в нашей сфере термин, как reliability, у которого нет точного перевода на русский язык, но самым близким является надежность.

#машины_aws

AWS завез SQL-подобный язык для DynamoDB.

На самом деле язык появился еще с год назад и имел поддержку RedShift и QLDB (AWS-ный blockchain-ledger), но именно сейчас его стала поддерживать DynamoDB.

Ощущения у меня от этого смешанные. С одной стороны, мы получаем относительно удобный и известный метод получения доступа к данным. С другой стороны, SQL был адаптирован для получения структурированного вывода из таблиц, которые являются целостной структурой данных. В DynamoDB таблица - лишь группа сущностей (items), а каждый item может быть раскидан по разным хранилищам (именно поэтому операции Scan очень дорогие и неэффективные). Применение SQL-подобного языка может как минимум зарубить на корню имплементацию подхода Single-table Design, а как максимум компрометировать расчеты provisioned R/W capacity units - рассчитать хотя бы приблизительный объем операций чтения и записи на транзакцию может стать невозможно… Не говоря уже о том, что неизвестна реакция PartiQL на throttling от DDB. Ну и вряд ли это новшество было сделано для 22-летних сеньоров - многие миллениалы познакомились с MongoDB раньше, чем с MySQL.

С другой стороны, такой шаг может служить толчком для адаптации legacy приложений на новую структуру хранения данных.

Надевая шапочку из фольги и глядя на Network Firewall, GWLB, а теперь еще и PartiQL для DynamoDB, я могу делать выводы, что AWS вдоволь наелся в секторе small-medium business и объявляет 2021 годом “кровавого энтерпрайза”.

#машины_aws

На следующий год планов много. А вот на этот год публичная активность потихоньку приходит к концу.

Моим последним в 2020 выступлением будет доклад, посвященный вольной имплементации Оруэлловского “1984” в рамках AWS с применением AWS Config и Systems Manager.

В рамках ZED я еще засвечусь вне общего расписания, так что приходите! Буду рад всем, пусть и виртуально.

#машины_aws

https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-modules/

Надеюсь не увидеть завтра новость, что в CloudFormation появилась поддержка HCL.

#машины_aws

3 года назад я мерзковато хихикал, глядя на отказ S3 в Сев. Вирджинии и удивляясь непредусмотрительности разработчиков IoT услуг.

Я не ожидал, что после такого удара, никто не усвоит урок.

Коротко о вчера:

#машины_разное

Я очень трепетно отношусь к израильтянам и к "ядерщикам". Ну а кернельщиков-израильтян я прям очень сильно люблю.

Кто же еще так хорошо расскажет про современное состояние хранилищ?

Я общался с Глобером только один раз, и то на собеседовании. Один из тех немногих людей, с кем мне очень хотелось бы поработать.

#машины_разное

https://aws.amazon.com/message/11201/

"For the latter communication, each front-end server creates operating system threads for each of the other servers in the front-end fleet."

Что может пойти не так, верно?

"Rather, the new capacity had caused all of the servers in the fleet to exceed the maximum number of threads allowed by an operating system configuration."

Это очень хороший пример, когда scale out проигрывает scale up.

#машины_aws #машины_разное #люди

Помимо выступления 4ого числа, я участвую еще в паре движух в рамках Zed.
Сегодня, буквально через пару часов я буду обсуждать всякие глупости из мира облачно-культурных вещей.
Ну а 3-его числа можно позадавать мне удобные (и не только) вопросы. На некоторые из них я даже смогу ответить!

На самом Zed будет много интересного. Если хотите взглянуть на то, что заготовили для вас различнве сообщества, вы можете посмотреть их программе “будок”.

#анонсы

Коллеги! Помните, давеча я писал про крепких “середнячков”? Настало время поднимать ставки!

С нового года мой клиент хочет превратить свою платформу в нечто страшное и огромное, словно Netflix. Гео-избыточность, мульти-регион и, конечно же, мои любимые РАСПРЕДЕЛЕНОЧКИ!

На этот раз мне нужны чудовища из морских глубин, психи, бессмертные воины клавиатурного труда… и кто-то кто расскажет мне про eBPF.

Кроме шуток - со следующего года планируется следующая фаза проекта, на котором я тружусь. И на этот этап мне нужны:
- 1 архитектор - будет ходить со мной, проговаривать и прорабатывать все вопросики, рисовать стрелочки, разрабатывать PoC и заниматься прочей очень важной деятельностью.
- 6 инженеров - будут говорить мне и этому архитектору, что стрелочки нарисованы через одно место, а затем любезно доводить до ума это поделие.
- 1 QA (по факту SDET) - будет говорить инженерам, что их поделие написано через одно место, а затем любезно доводить до ума это поделие.

От кандидатов я жду: знание AWS, распределенных систем, навыки разработки и построения отказоустойчивых гео-распределенных систем.

Я не могу и не буду обещать вам золотых гор и лучшего в мире работодателя. Я обещаю вам погружение в пучину ада, безумия и жести, из которой вы вместе со мной, словно герои творчества Лавкрафта, выйдете победителями, сохранив рассудок. А после этого у вас начнется ломка, потому что ЛЮБОЙ другой проект или задача покажется детской шалостью и легко летней прогулкой.

Повторюсь, я ищу очень сильных инженеров, понимающих и осознающих, что будет сложная работа. Очень сложная.

Пишите мне в ЛС за подробностями.