Сдал только что AWS Certified Database - Specialty.

Ожидание:
- Тонкая настройка Read Replicas
- Рассчитать консистентность Aurora Global Database в разных сценариях
- Всякий high load с моделированием данных

Реальность:
- Как подружить корпоративный AD с MS SQL Server
- Как затолкать Oracle в AWS
- RDS
- RDS
- DynamoDB
- DynamoDB
- DynamoDB
- DynamoDB
- Еще DynamoDB

Ну раз хотите динаму, будет вам динама!

Автор уходит на отдых и скоро вернется с первой главой Amazon DynamoDB Deep Dive.

Не поймите неправильно, я очень люблю Скрам как идею. Есть группа мульти-кросс-гиперфункциональных людей, которая за спринт заносят всякие ништячки заказчику.

Повторюсь, затея - космос. Есть только ряд недостатков: под заказную разработку либо неэффективно, либо избыточно; под инфраструктурные проекты не подходит, под большие организации тоже (можно тащить SAFe, но это очень дорого).

Да и мульти-кросс-гиперфункциональных людей (этакие Т-shape на стероидах) на рынке нет от слова совсем, надо перекупать у конкурентов. А наберете вы очень дорогих спецов, сверху еще потратив на их поиск и выкуп… Наверняка захотите на серьезный инфраструктурный внутряк или core business.

Что я понял из опыта - Скрам с его спринтами хорошо работает только для небольших проектов строго на микросервисах (где изменение завозится в течение пары недель), либо на молодых продуктах, судьба которых не определена. Инфраструктурщина и системная инженерия лучше работает по Канбану, причем по формуле “Это будет сделано, когда будет сделано.”

С адекватными и честными сроками, разумеется.

Кого не пугает английский язык, приходите на AWS Community Day Amsterdam.

Я и остальные Летучие Голландцы будут там вещать.

Ваше воскресное чтиво - первая ступень в нашем глубоком погружении в Amazon DynamoDB.

Что есть DynamoDB, в чем ее отличие от других NoSQL СУБД, как создать таблицу и что-то в нее записать - в этом обзорном материале.

Для смелых духом и опытных амазонщиков этот пост покажется излишне легким, но вам остается лишь чуть-чуть подождать.

Дальше будет гораздо сложнее и больше.

Я еще тут. И хочу поговорить с вами про аутсорсинг.
https://telegra.ph/Pro-greblyu-na-galerah-10-12

Немного контекста: у меня с Мишей (@anykeynotes) был недавно разговор про работу в аутсорсе, который стал его постом выше. Продолжением беседы будет мой ему ответ.

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

Говорить за всех аутсорсеров не берусь, использую только свои условия, информацию, которой владею, и говорю только о своем работодателе. Вместо слова “галера” я буду применять “консалтинг”, коим EPAM de facto и является.

Мнение, разумеется, только мое, и говорю я только от своего имени.

“Весь бизнес компании строится на том, что клиенту вас как сотрудника продают с наценкой, …”

Не совсем. У консалтинга есть определенное портфолио проектов с экспертизой в разных областях бизнеса. Заказчик приходит с запросом “Хочу Х”. Консалтинг “отгрузит” необходимое количество рук и мозгов, которое может реализовать желаемое в определенные сроки. Поскольку требования могут на ходу меняться (мы живем в реальном мире), то договор заключают как раз по месячной работе кадров разных профилей и специализаций. Отсюда и наваждение, что консалтинг это body shop.

“Клиент не оплатил вовремя, клиент долго стартует проект, у клиента кончились деньги и объем проекта уменьшился, у клиента резко сдвинулись сроки в меньшую сторону - всё это риски, которые несёт компания.”

1. Эти риски оговариваются в контракте. 2. Эти же риски могут присутствовать в любом внутреннем проекте большой компании с бюрократией, бюджетами и прочими прелестями enterprise-сектора. Смотрим “кладбище Google”.

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

Не класть все яйца в одну корзину вполне логично, но ни один менеджер не станет назначать 100% billable сотрудника на несколько проектов. В теории, я могу договориться о работе на нескольких проектах одновременно (двух или трех), что приведет к тому… что я не буду работать ни на одном. Это не принесет пользы ни мне, ни работодателю, ни заказчику.

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

“Единственный риск, который компания не может хэджировать - сроки сдачи проекта. Овертаймы в аутсорсинге будут всегда.”

Вздор. Срок контракта != Срок сдачи проекта. Если в проекте меняются или появляются новые требования, сроки сдачи всегда пересматриваются, и нормальный заказчик на это идет.

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

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

Действительно, решение о выходе в промышленную эксплуатацию принимает program/project board (ну а кто же еще). Это решение принимается на основе десятков ПМИ - performance test, dry-run и прочих, которые являются маркерами technical readiness.

Вдобавок есть еще operational readiness, при котором эксплуатация заказчика подписывается под тем, что готова обслуживать проект на первой и второй линии поддержи. Эксплуатация, к слову, хоть и не является членом program board и по сути обладает правом Вето.

—

Дальше идет то, что я просил Мишу раскрыть, а именно так называемое “галерное мышление”. Про это поговорим чуть позже.

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

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

Второе, на что стоит обращать внимание, это почему решение неэффективное. Со стороны удобно бросаться замечаниями о плохой/кривой/немасштабируемой/и т.д. архитектуре/инфраструктуре (чем ваш покорный очень любит заниматься), но стоит начать копаться в истории, так сразу всплывают всевозможные 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 я еще засвечусь вне общего расписания, так что приходите! Буду рад всем, пусть и виртуально.