Сравнение gRPC с OpenAPI https://www.redhat.com/en/blog/comparing-openapi-grpc c бонусом в виде подборки статей внутри. Хотя мне так и не хватает проекта, где один и тот же магазин книг/petstore будет представлен в трех форматах - gRPC, OpenAPI, GraphQL. Если знаете, поделитесь

Поделюсь ссылкой на понравившийся доклад. Точнее, что еще ценнее, ссылкой на его отшлифованную расшифровку https://habr.com/en/company/oleg-bunin/blog/594179/ Доклад, в общем-то, не открывает америку, не презентует новую концепцию. Но при этом будет полезен тем, кто планирует переезд в микросервисы или просто симпатизирует.

И опять я с long-read-ами. Наткнулась на прикольную статью 2002ого года, оценивающую применимость и актуальность security evaluation, проведенного в 1974ом году над Multics. Кто не в курсе, то Multics - это отец Unix-а и через то прародитель большинства современных операционных систем. https://www.acsac.org/2002/papers/classic-multics.pdf Эх, и кто из Intel-а придумал растить стек не в том направлении? А то могли бы избавиться от ROP-а. Сам security evaluation report значительно длиннее, но интересен чтение с точки зрения формата и процедуры Security evaluation https://seclab.cs.ucdavis.edu/projects/history/papers/karg74.pdf

С курса по теоретическому инфобезу вынесла в числе прочего интересный вывод про избыточность. Чаще всего, говоря про избыточность мы подразумеваем redundancy (active/passive/spare) и представляем дополнительные копии сервиса/данных и думаем о защите от неожиданного выхода из строя одной копии. Но есть еще избыточность, которая diversity, заключающаяся в многообразии имплементаций и коллегиального решения на базе разных источников. Цель diversity - уберечься от ошибок каждой имплементации, и используется она в авионике и других life-critical системах. Redundancy используется для достижения availability, а также security (помним ведь cia = confidentiality, integrity, availability). Diversity нужна для safety и надежности системы. Но вот что любопытно: diversity - это один из редких моментов, где safety противоречит security, ведь обычно безотказное и надежное ПО - это еще и ПО без weakness/vulnerabilities, то есть безопасное ПО. Но использование разных имплементаций, хоть и снижает риск ошибки в принимаемом решении, увеличивает кодовую и элементную базу, а значит увеличивает вероятность эксплуатируемой ошибки. И по принципу weakest link снижает секурность всей системы. Такое вот занятное наблюдение

Знакомые стартовали новый канал по недетскому программированию, с обсуждениями тонкостей си, компиляторов, лоу-левел и хай-тек. Зашёл их разбор хоббийных ОС. https://t.me/justcodeit_channel/7

И снова размышление о версионировании REST API. Казалось бы, его место в URI и спор может быть только о том говорить api/v1 или api/1. Но возникают все новые варианты. Вариант 1 - версионировать тела запросов, то есть добавить версию в json. Недостатки: nginx/apigee не сможет роутить запрос на нужную версию инстанса, а значит несимпатичная compatibility логика оказывается в компоненте, увеличивая его сложность(и эту логику никто не любит ни писать, ни тестировать, ну и дальше вы понимаете). Вариант 2 - Microsoft-овский - версия в query parameters https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#12-versioning. Недостатки: routing по query params потребует их парсинга, что увеличит время процессинга; а кроме того усложнится клиент, ведь ему прийдется в явном виде каждый раз формировать query parameters (или надеяться что версия не поломается, а сколько людей не читают документацию). Вариант 3 - версия в header-е https://youtu.be/P0a7PwRNLVU . Routing получше, чем вариант 2, но сложность клиента опять же возрастает с теми же рисками что в варианте 2.

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

Ух ты и ах. Google-овские книги по SRE доступны онлайн. https://sre.google/books/ Конечно, самая главная здесь книга https://sre.google/sre-book/table-of-contents/ Нигде я больше не видела такого внятного размышления про разницу между SLA, SLO и SLI https://sre.google/sre-book/service-level-objectives/

Выбор удобной структуры данных для хранения статистики - одна из классических задачек system design собеседования или algorithm & structures секции общедевелоперского интервью. В отличие от многих других, задача имеет практическое применение. Итак, дано: есть сервис, исполняющий какую-то работу. вопрос: как собирать информативную статистику по производительности его работы. ответ: avg, min, max информативными не являются. первая часть ответа состоит в том, что нам нужны персентили и нужно скользящее окно за последние N минут/секунд/временных интервалов. вторая часть ответа - это как сделать не наивную имплементацию. Наивная имплементация чаще всего сводится к списку величин с popup-ом (ну и может aging). продвинутый ответ включает hdr histogramme, forward decay и t-digest. А дальше все ушли читать про те из структур, что не знали 🙂 И интересно, может у вас какой-то другой ответ на эту задачку?

На Techlead Conf в этом году задалось немало хороших докладов. Сейчас слушала доклад про интервью SRE - организация секции troubleshooting и кратенько про секцию system design. Товарищ предусмотрительно описал доклад в статье. https://apolomodov.medium.com/troubleshooting-interview-3690b40a3d77 делюсь. И ещё слайдик от него же на почитать (среди ссылок ещё одно видение sysDesign interview - https://apolomodov.medium.com/system-design-interview-at-tinkoff-7bd97c20d082)

Как же красиво делает некоторые процессы Google. И выдает наружу готовые материалы для того, чтобы провести workshop, а потом завести процесс у вас. Вот сейчас наткнулась на их раздатки по SLO https://sre.google/resources/practices-and-processes/art-of-slos/ И вроде тема-то простая, но так иногда сложно ее объяснить. В общем, руки чешутся применить.

Postman опубликовали обновление API Platform Landscape [1] с перечнем продуктов и трендов в мире API.

Ключевые тезисы оттуда:
1. Компании переходят к модели API-first
2. Гибридная архитектура и многооблачность
3. API как продукт
4. Взрывной рост продуктов API Gateway
5. Всё больше протоколов для API в активном использовании.
6. Всё больший сдвиг в сторону безопасности доступа к API.

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


Ссылки:
[1] https://blog.postman.com/2022-api-platform-landscape-trends-and-challenges/

#api

Слушала на днях старый доклад с Highload-а про отказоустойчивость. Кроме описания пары amazon кейсов 10-летней давности понравилась формула про “Маленький флот вызывает большой”: инициатирует передачу данных тот, у кого пропускная способность/количество инстансов меньше, иначе рискуем организовать отказ. И в целом размер "флота" можно было бы назвать универсальным критерием для выбора между push и pull моделью, если бы нас интересовал только сценарий отказа, без учета секурити, производительности и масштабируемости. В целом, неплохой доклад про проектирование систем на отказ и каскадные падения, если только не забывать про другие критерии и не брать решения as is, а понимать что все зависит от приоритетов QAS (quality attribute scenario).
https://habr.com/ru/company/oleg-bunin/blog/497332/

Читала статью Бишопа про robust системы. Статья-то хорошая с примерами, что может поломаться при имплементации очереди и как это предотвратить. http://nob.cs.ucdavis.edu/bishop/secprog/robust.html Но как же она проста по сравнению с моим любимым докладом от Алексея Миловидова про robustness ClickHouse-а. https://www.youtube.com/watch?v=ooBAQIe0KlQ&list=PLH-XmS0lSi_zTZrols83QSxI3Q96dSbBm&index=93 Вывод - простые пробои/фейлы можно предотвратить и на уровне простеньких систем. Это девиз про "нормально делай - нормально будет". Но для того, чтобы быть устойчивым и против редких событий требуется уже дополнительные харденинги, на которые далеко не всякая компания готова потратится.

Простые концепции даже при наличии corner case-ов могут значительно упрощать работу со сложными системами. Вот, например, правило 2х от Chromium https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md : никогда не совмещайте (а) код написанный на небезопасных языках, (б) код не из песочницы, (в) недоверенный ввод. Это звучит просто, запоминается как CAP-теорема или триада ремонта("быстро, качественно, недорого - выбирай два из трех"). И имеет теоретическую базу: ребята проанализировали последние уязвимости проекта, откатегоризировали их и придумали как заткнуть основной источник ошибки. Очаровала меня аккуратность такого подхода. То, чего architecture hoisting добивается путем злостной машинерией, инженеры Chromium-а добились аккуратной теорией, заложенной прямо в мозг.

Воодушевляющая пятничная аналитика о падении больших ИТ проектов https://spectrum.ieee.org/lessons-from-a-decade-of-it-failures Читая эту статью, постоянно вспоминала "Путь камикадзе"(Death march) Йордана и его правила выживания в смертельных проектах. Берегите себя

Цитата дня: "The greatest limitation in writing software is our ability to understand the systems we are creating". больше вдохновения в видео John Ousterhout https://www.youtube.com/watch?v=bmSAYlu0NcY, который написал курс по software design для Стендфорда. Размышления об управлении сложностью на уровне кода весьма здравые, особенно когда добавляется измерение горящих дедлайнов.

Сколько лет сталкиваюсь с производительностью, столько не перестаю удивляться людям, которые искренне верят одному замеру или среднему арифметическому из трех. Это кстати хороший аргумент, зачем учиться в вузе. Если ты ИТ-шник - самоучка, то на уровне логики среднее арифметическое если не из трех, то из 10 замеров уже неплохо. Дальше тебе объяснят и научат (если ты обучаемый), а может побьют и посмеются (и тогда ты точно научишься, к сожалению), но первые твои N заходов к снаряду пройдут впустую. А вот учась в вузе на ИТ-шника, ну не сможешь ты миновать мат стат и тер вер. Ну никак. И будешь ты знать распределение Стьюдента. и mean для тебя будет ни в коем случае ни avg, а мат ожидание, к которому прилагается дисперсия и никак иначе. А поскольку я почти в каждом посте делюсь ссылкой, вот и здесь приложу книжку от Стаса Протасова по верхам той математике, которая нужна для программистов. MVP of MVP. https://habr.com/ru/articles/427395/

Читая книгу по производительности систем от Грегга Брендана https://ozon.ru/t/X30XowG , лишь спустя неделю вспомнила, где я видела это имя и фамилию. Он автор всеобъемлющей картинки про зоопарк Линуковсого перф тулинга. http://www.brendangregg.com/Perf/linuxperftools.png Сама книга весьма занятная. Я, конечно, ожидала большей методологии, рассказов о способах повышения достоверности измерений и отсечении фантомных деградаций. Но автор весьма практично размышляет - от USE (utilization-saturation-error) метода собственного изобретения до blame-someone-else антипаттерна. Ну и еще в книге есть прекрасные таблички (относящиеся к методологии adhoc checklist - это типа что нужно проверить суппорту когда система тормозит)

В очередной раз поною о неопределимости и неназываемости quality attribute-ов. Вот громадный спиcок resilience тактик https://insights.sei.cmu.edu/blog/system-resilience-part-5-commonly-used-system-resilience-techniques/ Среди них находим относящиеся к robustness, availability, security, debuggability. И я не о том, что тактики неправильно перечислены. Но о том, что одни и те же тактики используются для разных целей. Кстати, обсуждая этот список, придумали полезное мыслительное упражнение - окинуть взором список тактик и попробовать применить их к компоненту/системе. Для этого ответить на следующие вопросы: (1) как это сделать (что получится при скрещивании ежа и ужа, и куда в вашу систему запихнуть, например, watchdog), (2) что от этого получим в терминах QA-ов (доступность, стабильность, отказоустойчивость), (3) нужно ли это или вы используете другую тактику для данной проблемы? По результатам такого упражнения может прийти два рода озарений - "нам полезна тактика Х" и "у нас не проработан сценарий Y". Удачи!

Написали статью о карьере архитектора в стиле геймдева https://habr.com/ru/companies/kaspersky/articles/842244/