Найкраще 2018 року в Tech Talks

Останні два роки я публікував список моїх улюблених технічних переговорів попереднього року (ось видання цієї публікації за 2016 рік і ось видання 2017 року).

Цей список аж ніяк не є вичерпним, і я впевнений, що з 2018 року є багато технічних переговорів, які я дізнаюся лише пізніше. Але серед переговорів, на яких я відвідував або спостерігав, такі були найкращі (не в певному порядку).

  1. Майбутнє мікропроцесорів, Софі Вілсон

Софі Вілсон, відома піонерка оригінальної мікросхеми ARM, схоже, вважає, що закон Мура закінчується (разом із деякими іншими, переліченими пізніше у цій публікації). Це була феноменальна розмова від JuliaCon, яка йде в історію, еволюцію та майбутнє мікропроцесорів.

Відео

2. Метелик урагану: налагодження патологічно працюючих систем, Брайан Кентрил

Дві з переговорів, які потрапили до мого списку минулого року, були Зебрами до кінця і Налагодження під обстрілом: Тримати голову, коли системи втратили розум. Це була розмова в подібному руслі, і вона прозвучала з найвірогіднішим кантрільянським чуттям, життєвою силою та енергійністю, яких ми очікували. Програмне забезпечення побудовано як стек абстракцій, маючи на увазі незначні проблеми в одному шарі (метелики), які мають потенціал перетворитися на системні проблеми патологічної ефективності в інший (ураган). З огляду на такий ураган, як можна знайти метеликів?

Відео слайдів

3. Закрити петлі та відкрити розум: як взяти під контроль системи, великі та малі, Colm MacCarthaigh

Справді, я не дивився всі переговори з AWS re: Invent, але з тих, що я дивився, це, можливо, була моя улюблена розмова. У ньому закладені деякі принципи проектування для побудови високостійких і надійних систем (таких як площини управління).

  1. Контрольна сума всіх речей
  2. Криптографічна автентифікація
  3. Клітини, оболонки та «Отруйники»
  4. Асинхронна муфта
  5. Закриті петлі зворотного зв'язку
  6. Маленькі натискання та великі тяги (для конфігурації)
  7. Уникайте холодних пусків і холодних кешів
  8. Дроселі
  9. Дельти
  10. Модальність і постійна робота

Було захоплююче дізнатись, як певні анти-шаблони та неінтуїтивні конструкції насправді можуть допомогти покращити стабільність систем. Можливо, найцікавішою частиною бесіди була думка про те, що для стабільних систем управління потрібен «цикл PID» - пропорційні, інтегральні, похідні компоненти, і що можливість перегляду дизайну системи та місця, якщо в ньому відсутня якась із них, є наддержави. Це перший раз, коли я чую про цю "петлю PID"; в розмові рекомендується книга "Проектування розподілених систем управління", щоб дізнатися більше про те, як принципи теорії управління можуть застосовуватися до інженерії розподілених систем.

Також було цікаво вивчити ієрархію чи пріоритети на AWS: безпеку, довговічність, доступність, швидкість.

Відео слайди

4. Золотий вік комп’ютерної архітектури, Девід Паттерсон та Джон Хеннесі

Це була фантастична розмова про історію та еволюцію мікропроцесорів, про перехід від CISC до RISC-машин до кінця Закону Мура та про масштаб Деннара, що, в свою чергу, надає безпрецедентні можливості для прогресу в просторі «архітектури, специфічної для домену». "Доменна архітектура" включає в себе як технічний прогрес (нейромережеві мережеві процесори для машинного навчання, такі як TPU, так і GPU NVIDIA для FGPA), а також програмне забезпечення, яке стосується домену (наприклад, Swift for TensorFlow). Розмова завершується розповіддю про створення та зростання RISC V ISA.

Для тих, хто віддає перевагу письмовій статті до відео, у цьому місяці "Комунікації ОСБ" є статтею, написаною Геннесі та Паттерсоном (авторами відомої книги "Комп'ютерна архітектура") саме на цю тему. Закон Мура про транзистори може закінчитися, але, здається, спостерігається зростання закону Мура щодо кількості машинобудівних робіт, що публікуються в останні роки.

Відео [Hennessy у Стенфорді, ~ 1 година]

Відео [Паттерсон на @Scale конференції Facebook ~ 30 хвилин]

5. Безпечна поведінка клієнта, Аріель Гох

Для старих розподілених систем це повинно бути очевидним, але варто ще раз зазначити, що клієнти є важливою частиною розподіленої системи і тому повинні брати участь у зусиллях щодо стійкості. Це фантастична розмова з SRECon Asia / Australia про кращі практики дизайну клієнтів для підвищення стійкості всієї системи. Запропоновані методи включають в себе тремтіння клієнтських запитів, додавання випадковості, щоб усі клієнти випадково не закінчували синхронізацію, коли вони робили запити, коли не намагалися повторити, тремтіти, повторювати повтори з експоненціальними мітками (і супутніми грошами), "повторити бюджети" (наприклад, бюджети на помилки) ), переміщення частини керування на сервер та встановлення циклу зворотного зв’язку між сервером та клієнтами, адаптивне дроселювання клієнтів та багато іншого.

Відео

6. Як обслуговувати та захищати (з відокремленням клієнта), Френсіс Джонсон

Це ще одна чудова розмова від SRECon Asia / Australia про захист такої служби, як Google Maps (з безліччю внутрішніх та зовнішніх клієнтів) від перевантаження. Розмова торкається таких проблем, як перевантаження системи (і супутні проблеми, такі як низхідні потоки, не забуваючи про перевантаження системи), каскадні збої, підводні камені статичних квот, плюси і мінуси застосування витончених методів деградації на різних шарах стеку (клієнт, край, фронтенд, бекенд).

Відео

7. Прикладна теорія продуктивності, Кавія Джоші

Це неймовірна розмова (як завжди) від Kavya з QCon London про те, як використовувати методи моделювання продуктивності, щоб мати можливість відповідати на такі запитання, як додаткове навантаження, яку може підтримувати система без погіршення часу відгуку та як виявити вузькі місця у використанні системи. Розмова спочатку перегляне нас через типовий приклад веб-сервера, щоб продемонструвати, як проаналізувати продуктивність у «відкритих системах», а потім приклад «закритих систем» та як обидва залежать від різних припущень та потребують різних методів аналізу.

Відео слайдів

8. Amazon Aurora: Розгляд міркувань для реляційних баз даних з високою пропускною здатністю, Сайлеш Кришнамурті

Це була абсолютно розгульна розмова з Facebook-конференції @Scale у Facebook про деякі дизайнерські рішення та компроміси, які лежать в основі Amazon Aurora, двигуна зберігання, що забезпечує багато популярних пропозицій баз даних AWS. Як стверджується, Aurora автоматично масштабує до 64 ТБ на екземпляр бази даних і забезпечує високу продуктивність і доступність з до 15 репліками зчитування з низькою затримкою, відновленням в момент часу, постійним резервним копіюванням на S3 та реплікацією у трьох зонах доступності.

Є дві [1] [2] супровідні білі книги, опубліковані Amazon на Аврорі. У бесіді, зокрема, згадується багато моментів другого документу, головний висновок полягає в тому, що розподілений консенсус вбиває результативність і що місцева держава насправді може бути хорошою справою. Використовуючи непорушний журнал як джерело істини, Аврора уникає поширеного консенсусу щодо змін членства, використовуючи деякі "оазиси послідовності" з використанням епох як охоронців як форми кворуму написання та уникаючи взагалі читання кворуму. Це цікаво в епоху, коли трансакційні системи дещо повертаються, і Google проповідує, чому нам слід вибирати міцну послідовність, коли це можливо, Amazon вибирає різні компроміси.

Відео

9. Майбутнє шару зберігання FoundationDB, Стів Етертон

Це була захоплююча розмова про майбутнє рівня зберігання FoundationDB від саміту FoundationDB. FoundationDB - це розподілений, упорядкований сховище ключових значень, але сам рівень зберігання нерозподілений і доступ до нього здійснюється одним процесом з одного потоку. У розмові йдеться про вимоги нового механізму зберігання даних, невимоги (одночасні автори, низький час затримки), потім досліджуються плюси та мінуси декількох структур даних du jour (B + дерева, дерева LSM) та причини вибору Redwood у версії B + дерево.

Відео

Ще однією чудовою розмовою з саміту FoundationDB була розмова на рівні документа, відео про яке можна знайти тут.

10. Автономне тестування та майбутнє розробки програмного забезпечення, Вілл Вілсон

Перш за все, Вілл, можливо, один із найкращих мовців, яких я коли-небудь спостерігав (його попередня розмова про тестування розподілених систем з детермінованим моделюванням від Strangeloop 2014 - один із моїх улюблених за весь час).

Це феноменальна розмова з вступного саміту FoundationDB, який робить досить переконливим випадком для AI-підходу до тестування. У бесіді визначено 3 основні проблеми тестування: крихкість (ваш тест покладається на властивості вашої системи, які є випадковими - це не ті, які ви думали, що ви протестували), відсутність вичерпності та чіткості.

У бесіді стверджується, що тести чудово підходять для виявлення регресій, але майже абсолютно марні для виявлення невідомих-невідомих. Розмова продовжує розглядати всі вищезгадані проблеми як симптоми, а справжньою основною проблемою є те, що тестування все ще є повністю ручним. Навіть «автоматизоване тестування» лише коли-небудь передбачає, що Дженкінс працює за тестовим набором, власником якого є люди. Потім у розмові викладається мрія про автономне тестування як необхідність автоматизованого створення тестів, крім автоматизованого виконання тестів.

Відео

11. Проектування розподілених систем за допомогою TLA +, Гіллел Вейн

Це було надзвичайно доступне обговорення від CodeMesh про використання формальної специфікації для проектування розподілених систем. Подумайте про це як ніжне вступ до TLA +. Котирування включають:

Приділіть системі достатньо часу, і вона зробить усе, включаючи збої.
Код - це не дизайн. Код не показує, як працює ваша система. Це лише ваша реалізація; це не повинно бути вашим дизайном, це не може бути вашим дизайном. І якщо ви думаєте, що можете створити систему і зрозуміти систему з просто кодом, у мене є міст, щоб продати вас, і я збираюся продати його вам двічі одночасно.

Відео

12. Що ми помилилися: уроки від народження мікросервісів у Google, Бен Сігельман

Це була бурлива розмова про основну мережу розподілених обчислень в Google, торкаючись всього того, що Google отримав право на практиці, які були не зовсім, але мали сильні паралелі з тим, що ми знаємо як "мікросервіси" в наші дні. У розмові підкреслюється, де ширша галузь насправді робить певні речі кращими за те, як Google це робив (наприклад, сервісні сітки), коли і чому наслідувати технологічний вибір та практику Google не працює добре для нас, і чому це стає особливо важливим для вміти відповідати на певні типи питань перед тим, як прийняти архітектурні парадигми du jour (наприклад, "без серверів").

Відео слайди

13. Майстерня з дизайну розподіленого журналу обробки, Лора Нолан, Філіп Тішлер, Салім Вірджі

Це абсолютно неймовірна розмова про практику побудови широкомасштабної розподіленої системи, зокрема про те, як підійти до масштабування, як оцінити компроміси по різних осях, а також тонни зворотних обчислень конвертів для обґрунтування кожного рішення.

У робочій книжці SRE (у вільному доступі в Інтернеті) від Google є ціла глава під назвою Неабстрактний великий дизайн системи, присвячена саме цій темі, і я чув, що це важливе інтерв'ю у всьому циклі інтерв'ю Google SRE, оскільки саме це є статистично найбільш імовірним зібрати кандидата з подальшим кодування інтерв'ю. Особисто я вважаю, що це стосується не лише SRE, але має бути прочитане для всіх, хто створює та працює з розподіленими системами.

На жаль, мені не вдалося знайти відео для цього.

Слайди

14. Завантажуйте балансування на Hyper Scale, Alan Halachmi та Colm MacCarthaigh

Це дійсно захоплююча розмова з Facebook-конференції Networking @Scale про еволюцію балансування навантаження на AWS. Він проливає світло на HyperPlane, систему, що лежить в основі балансового завантаження S3 AWS, VPC NAT шлюзу та PrivateLink тощо. Особливо мені сподобалось дізнатися про запропонований принцип ШОК (Самолікування або Постійна робота), який підказує, що коли ви будуєте систему, вона повинна бути стійкою навіть до великих потрясінь. Або, інакше кажучи, "якщо щось велике зміниться, система повинна мати можливість працювати як завжди". У бесіді пропонується:

1. Постійні зусилля та одужання від невдачі - це природні стани
2. Завжди працюйте в режимі ремонту. Коли вузол виходить з ладу, Hyperplane насправді робить менше роботи!
3. Розробляючи широкомасштабні системи, ми не хочемо, щоб вони були складними. Ми хочемо, щоб вони були максимально простими. З цією метою ми хочемо якомога менше режимів роботи (наприклад, у Hyperplane немає повторного режиму. Це накопичувач у вродженому механізмі повторної спроби TCP). Набір різних режимів роботи призводить до комбінаторного вибуху складності, в результаті чого система є надзвичайно важкою для перевірки. Ми хочемо, щоб система була послідовною і завжди виконувала так, як ми очікуємо.
4. У бесіді також представлена ​​ідея загострення перетасовки - техніка пом'якшення DDoS (де ізоляція є основною технікою пом'якшення), яка зараз широко розповсюджена у багатьох службах AWS.

Відео

15. Ізоляція без контейнерів, Тайлер Мак-Маллен

Однією з моїх цікавих областей є те, що я описував перед друзями як "спектр обчислень" - віртуальних машин, мікроВМ, вкладених віртуальних машин, контейнерів (та ароматів "пісочницьких контейнерів", таких як ката-контейнери) та "безсерверних" (або функцій) як послуга). Мене особливо цікавить "спектр ізоляції", яку пропонують ці пропозиції - від жорсткої ізоляції на рівні процесу до ізоляції через пісочницю, наприклад V8. За останні роки в просторі віртуалізації з'явилося декілька технологій, наприклад gVisor (гіпервізор, який реалізує підмножину API ядра Linux в просторі користувачів) Firecracker - монітор віртуальної машини, який створений для запуску легких і безсерверних навантажень у мікро-VM , побудований поверх crosvm (Монітор віртуальної машини Chrome OS). Одне з найбільш захоплюючих розробок у цьому просторі - WebAssembly. Спочатку розроблений як ціль для запуску власного коду в браузерах, WASM зараз використовується постачальниками CDN для запуску довільного коду без будь-якої форми ізоляції на основі процесу. Хоча я все ще думаю, що журі вирішує питання про те, чи справді ця форма ізоляції переходить на розсуд, це була захоплююча розмова Strangeloop про цю саму тему, яка пояснює особливості WASM, що навіть робить це дещо виправданим.

Відео

16. Як працюють налагоджувачі C ++, Simon Brand

Назва досить зрозуміла. У переговорах пояснюється все, що стосується бінарних файлів ELF, символів DRAWF, механіки того, як працюють точки прориву, того, що перехід через код по-справжньому тягне за собою, роботу з багатопотоковими програмами в налагоджувачі та багато іншого. Це, безумовно, одна з моїх перших трьох переговорів у цьому списку неймовірних переговорів.

Відео

17. Філософія дизайну програмного забезпечення, Джон Остертер

Книга «Філософія дизайну програмного забезпечення» отримала найкращу технічну книгу, яку я прочитала у 2018 році. Кожна окрема глава книги важить золото, але розділ про глибокі модулі - це, мабуть, саме те, що я цитував найбільше. У бесіді торкаються деяких основних ідей та червоних прапорів, внесених у книгу, але якби я був ти, я б просто придбав книгу і закінчив би її.

Відеокнига

18. Clangd: архітектура масштабованого сервера мови C ++, Ілля Бірюков

Однією з найцікавіших розробок Майкрософт за останні роки став Протокол мовного сервера. Випуск 5.0 компілятора clang представив Clangd, реалізацію LLVM для протоколу мовного сервера. Clangd - це реалізація протоколу мовного сервера, що забезпечує такі функції, як завершення коду, виправлення, визначення goto, перейменування тощо для клієнтів, таких як редактори джерел C / C ++. Це була хороша розмова від CPPCon, яка торкнулася деяких обмежень libclang та пояснює мотиви розвитку Clangd, а також його загальну архітектуру.

19. Представлення спірних програм та ІПС у LLVM, Джон МакКал

Спроби в LLVM вперше було додано Гор Нішановим від Microsoft і було розроблено на потреби потреб C ++. Це була неймовірна розмова з наради розробників LLVM, яка вкладається в деякі плюси і мінуси різних аспектів впровадження, таких як контроль за припиненням (переключення контексту, розбиття програм із спільним відновленням і функціями відновлення урожайності), зберігання місцевого стану (складні процедури , розподіл сторони, співжиття стека) для отримання даних, а також проблеми генерування коду для мовних особливостей, що працюють на основі супротивників, таких як генератори. Потім у розмові розглядаються деякі деталі іншого типу пониження, що називається "поверненням аромату продовження" для мови програмування Swift, де деякі оптимізації відбуваються на рівні SIL Swift, а не безпосередньо на рівні LLVM.

Відео

PS: Усі переговори з наради розробників LLVM мають глибоку освіту. Я спостерігав лише за цим розмовою, але впевнений, що також радий рекомендувати всіх інших, як тільки зійду, щоб подивитися їх.

20. Розвиток Kotlin / Рідна інфраструктура з LLVM / Clang, Nikola Igotti

Kotlin Native - це надзвичайно цікава розробка останніх років, яка дозволяє скомпонувати код Kotlin до бінарних файлів платформи (ELF, Mach-O, WASM тощо), тому він може бути запущений на власному рівні, крім того, що він може працювати всередині JVM. Це була справді хороша розмова з Європейської наради LLVM про механіку Kotlin / Native, включаючи деякі проблеми впровадження управління пам'яттю поза JVM, обробку винятків та перенесення на WASM (що не має часу виконання, не розподільника пам'яті, немає винятків тощо), а також деякі загальні проблеми, що виникають із LLVM (повільний кодеген та зв'язування, відсутність загальнодоступного API плагінів LLDB тощо).

Відео слайдів

21. Свіжий асинхрон С Котлін, Роман Єлизаров

Спектр асинхронного програмування широкий і різноманітний. Це був фантастичний розмова від Гото Копенгагена про виклики, що лежать в основі деяких з цих парадигм асинхронного програмування, зокрема підходу на основі зворотного виклику з Futures. Далі мова йде про те, як Котлін прагне вирішити цю проблему з підпрограм, надаючи користувачеві синхронний інтерфейс (за допомогою призупинення призупинення), перебуваючи під кришкою, використовуючи продовження та точки припинення для побудови державної машини. Найбільш захоплюючою частиною бесіди було порівняння підходу Котліна та підходу C # до асинхронізації / очікування, при цьому головна пружина, що стоїть за вибором дизайну Котліна, полягає в тому, що одночасність є складною, а ерго має бути явним. Розмова закінчується тим, як можна реалізувати навіть шаблони, пов'язані з CSP, за допомогою примірників коротівок Котліна.

Відео

22. Рідна модель котлін-котлін, Микола Іготті

У Котліна немає мовних примітивів на рівні мови. Котролін Котліна, як описано в розмові вище, - це побудова на основі бібліотеки, орієнтована на СВМ. Kotlin / Native eschews Стиль спільного використання JVM в стилі спільного використання та блокування, підтримуючи інваріант, що об'єкт або належить одному контексту виконання, або він є незмінним (спільний XOR-змінний). Це була чудова розмова від KotlinConf, яка розглядає, як це досягається за допомогою "не згаданих зовні підгрупп"

Крім того, Котлін як мова не має вбудованої незмінності в систему типів. Незмінюваність досягається концепцією заморожування, яка робить перехідне закриття всіх об'єктів доступними від даного об'єкта незмінним. Крім того, Kotlin / Native також дозволяє передавати право власності на об'єкти в різних контекстах виконання. У бесіді представлені основні примітивні принципи безпечної сумісності, що надаються компанією Kotlin / Native, такі як "знімні графіки об'єктів", атоміки та "робітники" в стилі актора, як працює управління пам'яттю, що базується на довідці, в Kotlin / Native, а також як вона досягає сумісності з іншими тривалість виконання.

Відео слайдів

23. Настав час написати операційну систему в Rust, Bryan Cantrill

Я часто зазнавав, що хтось чи інше крісло вважає, що Руст є "мовою, призначеною для запису ядра".

Ну, це так?

Це чудова розмова головного експерта на тему, чому Rust особливо добре підходить для написання системного програмного забезпечення, а також про деякі проблеми потенційного написання всього ядра в Rust. Якщо вам подобаються подорожі по літописах з історії обчислень та рідкісний бренд гарячих занять, який насправді підкріплений добре обізнаним та аргументованим мисленням, це може бути розмовою для вас.

Відео слайдів

24. Що ви маєте на увазі "безпечний для потоків"? Джеффрі Ромер

Це була чудова розмова від CPPCon, яка має на меті розмежувати такі терміни, як "потокова безпека" або більш точні терміни, наприклад, "гонка даних" та "стан гонки", які часто діють на неправильному рівні абстракції. У бесіді пропонується використовувати поняття "гонки API" та інваріантів, які можна побудувати навколо "гонки API", з подальшими рекомендаціями як для бібліотеки C ++, так і для авторів додатків навколо

Відео

25. Швидкий безпечний змінний стан, Бен Коен

Що стосується мутаційного стану, важливо пам’ятати, що це загальний стан, що змінюється, що є поганим, а не самим собою. Це була чудова розмова з конференції Functional Swift про те, коли і як використовувати місцевий стан, що змінюється, не приносячи шкоди безпеці чи продуктивності. Розмова проходить через деякі мовні функції Swift, які надають їй певного функціонального колориту, запобігаючи певним категоріям помилок, можливих при мутації функцій.

Відео

26. Доси та помилки поводження з помилками, Джо Армстронг

Мені приємно було дивитись цю розмову наживо в GOTO Копенгагені. Основна мета цієї розмови полягає в тому, що неможливо досягти відмовостійкості за допомогою однієї машини; передача повідомлення при цьому стає неминучою. Побудова розподілених систем, що мають стійкість до відмов, зводиться до виявлення та дії помилок. Філософія поводження з помилками, яка вважається найбільш розсудливою, полягає в тому, коли програмне забезпечення може бути доведено правильним під час компіляції та коли програмне забезпечення вважається фактично невірним та очікується, що воно вийде з ладу під час виконання. Великі збори дрібних речей неможливо довести правильність; Таким чином, стає важливим можливість визначати "ядро помилки", яке є підмножиною системи, яка повинна бути правильною. Якщо ви, як програміст, не знаєте, що робити, руйнуйтесь. Тоді ваше програмне забезпечення стає простішим.

Вам би пробачили, що роздумали про це як 45-хвилинне пояснення існування мови програмування Erlang.

Відео

27. QUIC: Розробка та розробка замінника TCP для Інтернету, Ian Swett та Jana Iyengar

Це була велика розмова від NetDev, яка дає ознайомлення з протоколом QUIC, розробленим в Google, дизайнерськими рішеннями (навіщо це шарувати поверх UDP, кращим відновленням втрат, гнучким контролем заторів), еволюцією, а також безліччю пригод, що масштабують QUIC на Linux .

Відео слайдів

28. Представлення Network.framework: сучасна альтернатива Sockets, Josh Graessley, Tommy Pauly, Eric Kinnear

Розетки можуть бути важкими у використанні, якщо мова йде про встановлення з'єднання або передачу даних (навіть з неблокуючими розетками) або мобільність.

Network.framework - це сучасний транспортний API, який є альтернативою розеткам на платформах Apple. Це була велика прогулянка від WWDC 2018, яка пройшла анатомію початкового встановлення з'єднання до життєвого циклу зв'язку, а також безліч оптимізацій, здійснених на різних етапах. Це також, можливо, найкраще представлена ​​розмова в цьому списку.

Відео

29. Кубернетес і шлях до безсерверу, Келсі Хайтауэр

Це розмова Kelsey Hightower

Чи потрібно більше говорити? Я думаю, що не.

Відео

30. Використання іржі для розвитку ігор, Кетрін Вест

Розмова починається з того, що "Це, мабуть, найсумніша розмова ..."

Це не.

Це насправді може бути найкраща розмова в цьому списку.

Відео