Build Abstractions Not Illusions • Gregor Hohpe • YOW! 2023
В этом докладе Gregor Hohpe говорит про абстракции и их пользу, а также как чрезмерное абстрагирование и исключение важных вещей приводит к созданию иллюзий (и протекающих абстракций).
- Intro - автор показывает свой стандартный пример с различными географическими картами, которые отличаются в зависимости от цели и аудитории.
- Platform abstraction - автор переходит к platform abstraction и вспоминает про уменьшение когнитивной нагрузки для пользователей платформы. И тут появляется аналогия с машинами и платформами, которые использовались в автомобильной индустрии для выпуска машин разных марок на базе одной "платформы". Это позволяло экономить, разработав качественную платформу и переиспользовать ее для разных продуктов
- Abstractions vs composition - Автор продолжает приводить примеры из области автомобилестроения и говорит про педаль газа (хотя это скорее не педаль газа, а педаль ускорения, что еще очевиднее, если мы рассматриваем элетрические автомобили). Дальша он приводит SQS-Lambda-SQS из AWS, а потом переходит к паттерну scatter-gather pattern, который изначально назывался broadcast aggregate. Проблема в том, что в этих случаях описывается не сама абстракция, а ее реализация. Дальше автор рассказывает про электрическую розетку, которая является отличной абстракцией и автор объясняет почему (разделение интерфейса и реализации, стандартизация интерфейса, ...). Но даже электрическая розетка протекает как абстракция, если происходит глобальное отлючение энергии (в розетке заканчивается ток). Ну и напоследок автор говорит про абстракцию сокетов (sockets и packet routing). В итоге, автор говорит про то, что композиция бывает полезна, но она отличается от абстракции, так как объединение элементов в этом случае не предоставляет новую абстракцию
- Abstractions vs Illusions - Автор описывает абстракции, которые зашли слишком далеко. Например RPC (remote procedure call), который он описывает так, как было принято в начале 2000х, когда RPC пытались сделать похожим на локальный вызов и скрыть всю сложность. С тех пор утекло много воды и так никто не делает, но вьетнамские флешбеки Грегора тут выглядят странно. В итоге, проблема описывает так, что в иллюзиях мы выкидываем важные детали или излишком обобщаем до состояния, когда наша модель начичнает вводить людей в заблуждение. Дальше автор рассказыывает про абстракцию платформ. Интересно, что как представитель AWS он катит бочку на создателей IDP (internal developer platform) внутри компаний поверх публичных облаков - по мнению Грегора часто это не добавляет никакого value, а только отнимает его (мне эти аргументы кажутся очень biased). И дальше Грегор показывает хорошую по его мнению абстракцию в виде ledger database из двух dynamo db и event bridge pipes посередине. Суть этих размышлений сводится к тому, что IDP внутри компаний должны не просто уменьшать возможности публичных сервисов, закручивая гайки, а скорее создавать новые абстракции, которые полезны для пользователей внутри компании. И дальше автор говорит, что "good abstractions support broad usage".
- Distributed system abstractions - В этой части автор напирает на асинхронную работу с сообщениями (asynchronous messaging) и добавляет к абстракции data flow еще и control flow, который бывает полезно понимать. Речь идет примерно про puller, pusher, pool и driver
Ну а дальше Грегор показывает как понимание работы control flow позволяет сделать стандартные абстракции полезными
- Summary - в заключение Грегор подводит итог и говорит, что
#Conference #PlatformEngineering #SystemEngineering #Software #Architecture #DistributedSystems
В этом докладе Gregor Hohpe говорит про абстракции и их пользу, а также как чрезмерное абстрагирование и исключение важных вещей приводит к созданию иллюзий (и протекающих абстракций).
- Intro - автор показывает свой стандартный пример с различными географическими картами, которые отличаются в зависимости от цели и аудитории.
- Platform abstraction - автор переходит к platform abstraction и вспоминает про уменьшение когнитивной нагрузки для пользователей платформы. И тут появляется аналогия с машинами и платформами, которые использовались в автомобильной индустрии для выпуска машин разных марок на базе одной "платформы". Это позволяло экономить, разработав качественную платформу и переиспользовать ее для разных продуктов
- Abstractions vs composition - Автор продолжает приводить примеры из области автомобилестроения и говорит про педаль газа (хотя это скорее не педаль газа, а педаль ускорения, что еще очевиднее, если мы рассматриваем элетрические автомобили). Дальша он приводит SQS-Lambda-SQS из AWS, а потом переходит к паттерну scatter-gather pattern, который изначально назывался broadcast aggregate. Проблема в том, что в этих случаях описывается не сама абстракция, а ее реализация. Дальше автор рассказывает про электрическую розетку, которая является отличной абстракцией и автор объясняет почему (разделение интерфейса и реализации, стандартизация интерфейса, ...). Но даже электрическая розетка протекает как абстракция, если происходит глобальное отлючение энергии (в розетке заканчивается ток). Ну и напоследок автор говорит про абстракцию сокетов (sockets и packet routing). В итоге, автор говорит про то, что композиция бывает полезна, но она отличается от абстракции, так как объединение элементов в этом случае не предоставляет новую абстракцию
- Abstractions vs Illusions - Автор описывает абстракции, которые зашли слишком далеко. Например RPC (remote procedure call), который он описывает так, как было принято в начале 2000х, когда RPC пытались сделать похожим на локальный вызов и скрыть всю сложность. С тех пор утекло много воды и так никто не делает, но вьетнамские флешбеки Грегора тут выглядят странно. В итоге, проблема описывает так, что в иллюзиях мы выкидываем важные детали или излишком обобщаем до состояния, когда наша модель начичнает вводить людей в заблуждение. Дальше автор рассказыывает про абстракцию платформ. Интересно, что как представитель AWS он катит бочку на создателей IDP (internal developer platform) внутри компаний поверх публичных облаков - по мнению Грегора часто это не добавляет никакого value, а только отнимает его (мне эти аргументы кажутся очень biased). И дальше Грегор показывает хорошую по его мнению абстракцию в виде ledger database из двух dynamo db и event bridge pipes посередине. Суть этих размышлений сводится к тому, что IDP внутри компаний должны не просто уменьшать возможности публичных сервисов, закручивая гайки, а скорее создавать новые абстракции, которые полезны для пользователей внутри компании. И дальше автор говорит, что "good abstractions support broad usage".
- Distributed system abstractions - В этой части автор напирает на асинхронную работу с сообщениями (asynchronous messaging) и добавляет к абстракции data flow еще и control flow, который бывает полезно понимать. Речь идет примерно про puller, pusher, pool и driver
Ну а дальше Грегор показывает как понимание работы control flow позволяет сделать стандартные абстракции полезными
- Summary - в заключение Грегор подводит итог и говорит, что
Good abstractions reduce cognitive load because they form a cohesive language and a mental model.
Omitting relevant details is tempting but leads to dangerous illusions.
#Conference #PlatformEngineering #SystemEngineering #Software #Architecture #DistributedSystems