Най-доброто от 2018 г. в Tech Talks

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

Този списък в никакъв случай не е изчерпателен и сигурен съм, че има много технологични разговори от 2018 г., които ще открия само много по-късно. Но сред разговорите, на които присъствах или гледах, тези бяха едни от най-добрите (в определен ред).

  1. Бъдещето на микропроцесорите, Софи Уилсън

Софи Уилсън, известна пионерка на оригиналния чип ARM, изглежда вярва, че законът на Мур е към своя край (заедно с някои други, изброени по-късно в този пост). Това беше феноменална беседа от JuliaCon, която влиза в историята, еволюцията и бъдещето на микропроцесорите.

Видео

2. Пеперудата на урагана: Отстраняване на грешки в патологично работещи системи, Брайън Кантрил

Два от разговорите, които бяха включени в списъка ми за предходната година, бяха Зебри докрай и Отстраняване на грешки под огън: Дръжте главата си, когато системите са загубили ума си. Това беше беседа в подобен смисъл и изнесена с най-важния Cantrillian нюх, вим и енергичност, които сме отраснали да очакваме. Софтуерът е изграден като куп абстракции, като на пръв поглед незначителни проблеми в един слой (пеперудите) имат потенциал да се трансформират в системни проблеми с патологична ефективност в друг (ураганът). Като се има предвид такъв ураган, как човек намира пеперудите?

Слайдове видео

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

Признавам, че не съм гледал всички разговори от AWS re: Invent, но от онези, които съм гледал, това вероятно беше моят любим разговор. Той определя някои принципи на проектиране за изграждане на високо стабилни и надеждни системи (като контролни самолети).

  1. Контролна сума на всички неща
  2. Криптографска проверка
  3. Клетки, черупки и „Отровни вкусове“
  4. Асинхронно свързване
  5. Затворени контури за обратна връзка
  6. Малки натискания и големи издърпвания (за конфигурация)
  7. Избягвайте студените стартове и студените кеши
  8. Горивоподаване
  9. Делти
  10. Модалност и постоянна работа

Беше увлекателно да науча как някои анти-модели и интуитивен дизайн всъщност могат да помогнат за подобряване на стабилността на системите. Вероятно най-интересната част от беседата беше идеята, че стабилните системи за управление изискват „PID цикъл“ - пропорционални, интегрални, производни компоненти и че да може да разгледа дизайна и мястото на системата, ако липсва някоя от тях, е суперсила. Това е първият път, когато чувам за този „PID цикъл“; беседата препоръчва книгата Проектиране на разпределени системи за управление, за да научите повече за това как принципите на теорията на управлението могат да се прилагат за инженеринга на разпределени системи.

Също така беше интересно да научите йерархията или приоритетите в AWS: сигурност, дълготрайност, наличност, бързина.

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

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

Това беше фантастичен разговор за историята и еволюцията на микропроцесорите, за преминаването от CISC към RISC машини до края на закона на Мур и за мащабирането на Dennard, което от своя страна представя безпрецедентни възможности за напредък в пространството „архитектура, специфична за домейна“. „Архитектура, специфична за домейна“ включва както напредъка в хардуера (невронни мрежови процесори за машинно обучение като TPU, така и към графичните процесори на NVIDIA към FGPA), заедно със специфичния за домейна софтуер (като Swift for TensorFlow). Беседата завършва с историята за създаването и растежа на RISC V ISA.

За тези, които предпочитат писмена статия пред видеоклип, в съобщенията на ACM този месец има статия с автор на Хенеси и Патерсън (автори на известната книга Компютърна архитектура) по тази тема. Законът на Мур за транзисторите може да е приключил, но изглежда се наблюдава ръст на броя на документите за машинно обучение, публикувани през последните години.

Видео [Hennessy в Станфорд, ~ 1 час]

Видео [Patterson на @Scale Conference на Facebook ~ 30 минути]

5. Безопасно поведение на клиента, Ариел Гох

Това трябва да е очевидно за старите ръце на разпределените системи, но си струва да повторим, че клиентите са важна част от разпределената система и по този начин трябва да участват в усилията за устойчивост. Това е фантастична беседа от SRECon Asia / Australia за най-добрите практики за дизайн на клиенти за подобряване на устойчивостта на цялата система. Предложените техники включват трептене на клиентски заявки, добавяне на случайност, така че всички клиенти не завършват случайно синхронизиране, когато отправят заявки, кога да не се опитват отново, трептене, повторни опити с експоненциални баккофи (и съпътстващи готча), „повторни бюджети“ (като бюджети за грешки) ), преместване на част от контрола към сървъра и установяване на линия за обратна връзка между сървъра и клиентите, адаптивно дроселиране на клиенти и много други.

Видео

6. Как се обслужва и защитава (с клиентска изолация), Франсис Джонсън

Това е още една отлична беседа от SRECon Asia / Australia за защита на услуга като Google Maps (с множество вътрешни и външни клиенти) от претоварване. Беседата засяга проблеми като претоварване на системата (и съпътстващи проблеми като низходящи, които не се съобразяват с претоварването на системата), каскадна повреда, клопки на статичните квоти, плюсовете и минусите на прилагането на изящни техники на разграждане в различни слоеве на стека (клиент, ръб, фронт, заден ден).

Видео

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

Това е невероятна беседа (както винаги) от Kavya от QCon London за това как да използва техники за моделиране на производителността, за да може да отговори на въпроси, като какво допълнително натоварване може да поддържа системата без да намалява времето за реакция и как да открие затрудненията в използването на системата. Разговорът първо ни превежда през един типичен пример за уеб сървър, за да демонстрира как да анализираме производителността в „отворените системи“, последван от пример за „затворени системи“ и как двете зависят от различни предположения и изискват различни техники за анализ.

Слайдове видео

8. Amazon Aurora: Съображения за проектиране на релационни бази данни с висока пропускателна способност, Sailesh Krishnamurthy

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

Има две [1] [2] придружаващи бели книги, публикувани от Amazon на Aurora. В беседата се споменават много точки от втория документ, по-специално като основният опит е, че разпределеният консенсус убива ефективността и че местната държава всъщност може да бъде добро. С използването на неизменен лог като източник на истината, Aurora избягва разпределения консенсус за промени в членството, като използва някои „оазиси за съгласуваност“ с използването на епохи като пазачи като форма на кворум за писане и избягвайки изобщо да се чете кворум. Интересно е в епоха, в която транзакционните системи правят нещо завръщане и 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 и други. Особено ми хареса да науча за предлагания принцип на SHOCK (Self Healing или Constant Work), който предполага, че когато изграждате система, тя трябва да е устойчива на дори големи удари. Или казано по друг начин, "ако се промени нещо голямо, системата трябва да може да продължи както обикновено". В разговора се предлага:

1. Постоянните усилия и възстановяването от провал са естествените състояния
2. Винаги работете в режим на ремонт. Когато един възел не успее, Hyperplane всъщност върши по-малко работа!
3. Когато проектираме широкомащабни системи, не искаме те да са сложни. Искаме те да са възможно най-прости. За тази цел искаме възможно най-малко режими на работа (Hyperplane, например, няма режим на повторен опит. Той прави piggybanks на вродения механизъм за повторен опит на TCP). Натрупването на различни режими на работа води до комбинаторно взривяване на сложността, което води до невероятно трудно тестване на системата. Искаме система, която да е последователна и винаги да изпълнява така, както очакваме.
4. Беседата също така въвежда идеята за рязко заточване, DDoS техника за смекчаване (където изолацията е основната техника за смекчаване), която сега е широко използвана в много AWS услуги.

Видео

15. Изолация без контейнери, Тайлър Макмълън

Една от моите области на интерес е това, което описвах пред приятели като „спектър от изчисления“ - виртуални машини, microVM, вложени VM, контейнери (и аромати на „пясъчни контейнери“ като ката контейнери) и „без сървър“ (или функции като услуга). Особено се интересувам от „спектъра на изолация“, което предлагат - от строга изолация на ниво процес до изолация чрез пясъчна кутия като V8. През последните години в пространството за виртуализация се появиха няколко технологии като gVisor (хипервизор, който реализира подмножество на API на ядрото Linux в потребителското пространство) до Firecracker - монитор за виртуална машина, който е създаден за работа на леки и без сървър работни натоварвания в микро VM , самият той е изграден върху crosvm (монитор за виртуална машина на Chrome OS). Едно от най-завладяващите разработки в това пространство е WebAssembly. Първоначално проектиран като цел за използване на естествен код в браузъри, WASM сега се използва от доставчиците на CDN за пускане на произволен код, без каквато и да е форма на базирана на процеса изолация. Макар че все още мисля, че журито е по въпроса дали тази форма на изолация наистина преминава в съзнание, това беше увлекателна беседа от Strangeloop по тази тема, която обяснява характеристиките на WASM, което дори прави това донякъде издръжливо.

Видео

16. Как работят Отладчиците на C ++, Simon Brand

Заглавието е доста обясняващо. В разговорите се обяснява всичко от това какво представляват двоичните файлове на ELF, символите на DRAWF, механиката на това как работят точките на прекъсване, това, което стъпването на код наистина води до това, работата с многонишкови приложения в дебъгъра и много други. Това определено е едно от първите ми три разговора в този списък с невероятни разговори.

Видео

17. Философия на софтуерния дизайн, Джон Ousterhout

Книгата „Философия на софтуерния дизайн“ бе най-добрата техническа книга, която прочетох през 2018 г. Всяка глава в книгата си струва злато, но главата за дълбоките модули вероятно е тази, която съм цитирала най-много. Беседата засяга някои от основните идеи и червените знамена, въведени в книгата, но ако бях на вас, просто щях да купя книгата и да свърша с нея.

Видео книга

18. Clangd: архитектура на мащабируем езиков сървър на C ++, Иля Бирюков

Едно от най-интересните разработки на Microsoft през последните години е протоколът на езиковия сървър. Версията 5.0 на компилатора clang въведе Clangd, внедряването на LLVM за протокола за езиков сървър. Clangd е реализация на протокола за езиков сървър, за да предостави функции като завършване на код, поправка, гото определение, преименуване и т.н. за клиенти като редактори на източник на C / C ++. Това беше добра беседа от CPPCon, която засегна някои от ограниченията на libclang и обясни мотивите, които стоят зад развитието на Clangd, както и общата му архитектура.

19. Представяне на Coroutine и ABI в LLVM, John McCall

Coroutines в LLVM е добавен за първи път от Гор Нишанов на Microsoft и е проектиран според нуждите на C ++ корутини TS. Това беше невероятна беседа от срещата на разработчиците на LLVM, която се вписва в някои от плюсовете и минусите на различни съображения за внедряване, като контрол на преустановяване (контекстна смяна, разделяне на корута със споделено възобновяване и функции за възобновяване на добива), до съхранение на местно състояние (стабилни процедури , странично разпределение, съвместно съжителство) за получаване на данни, както и предизвикателствата за генериране на код за езикови функции, задвижвани от съвместни програми като генератори. След това разговорът се занимава с някои подробности за различен тип понижаване, наречен „връщащ аромат на продължение“ за програмния език на Swift, където някои от оптимизациите се случват на слоя SIL на Swift, а не директно на ниво LLVM.

Видео

PS: Всички разговори от срещата на LLVM Developer са дълбоко образователни. Гледах само този един разговор, но съм сигурен, че с удоволствие бих препоръчал и всички останали, щом отида да ги гледам.

20. Разработване на Kotlin / Native инфраструктура с LLVM / Clang, Николай Иготи

Kotlin Native е изключително интересна разработка през последните години, която позволява котлинът на Kotlin да бъде компилиран до двоични файлове на платформата (ELF, Mach-O, WASM и т.н.), така че може да се управлява и в допълнение към възможността да се изпълнява в JVM. Това беше наистина добър разговор от Европейската среща на LLVM Developer относно механиката на Kotlin / Native, включително някои от предизвикателствата при прилагането на управлението на паметта извън JVM, обработката на изключения и пренасянето в WASM (което няма време за изпълнение, няма разпределител на памет, без изключения и т.н.), както и някои от общите проблеми, срещани с LLVM (бавен кодген и свързване, липсващ обществен API за приставки на LLDB и т.н.).

Слайдове видео

21. Пресен асинхрон с Котлин, Роман Елизаров

Спектърът на асинхронното програмиране е широк и разнообразен. Това беше фантастична беседа от Гото Копенхаген за предизвикателствата, залегнали в основата на някои от тези парадигми на асинхронното програмиране, по-специално подходът, базиран на обратния разговор с Futures. След това разговорите продължават да се занимават с това как Котлин има за цел да реши този проблем с процедурите чрез предоставяне на синхронен интерфейс на потребителя (чрез спирането на примитива), докато е под капака, използвайки продължения и точки на окачване за изграждане на държавна машина. Най-завладяващата част от беседата беше сравнението между подхода на Котлин и подхода на C # за асинхронизация / чакане, като основната опция зад дизайнерските решения на Котлин е, че едновременността е твърда и ерго трябва да бъде категоричен. Разговорът завършва с това, че дори модели на CSP могат да бъдат реализирани, използвайки примитивите на Коротин от Kotlin.

Видео

22. Модел на коренната съвместимост на Kotlin, Николай Иготи

Kotlin няма паралелни примитиви на езиково ниво. Котлинът на Котлин, както е описано в беседа по-горе, е конструкция, базирана на библиотека, насочена към JVM. Kotlin / Native eschews JVM стил споделена купчина обект и заключване чрез поддържане на инвариант, че даден обект или е собственост на един контекст на изпълнение, или е неизменен (споделен XOR мутационен). Това беше чудесна беседа от KotlinConf, която се описва как това се постига с „не външно препратени подграфове на обекти“

Освен това Kotlin като език няма неизменност, вградена в системата тип. Неизменяемостта се постига чрез концепцията за замразяване, което прави неизменното преходното затваряне на всички обекти от даден обект. В допълнение, 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. Kubernetes и пътят към сървъра, Kelsey Hightower

Това е беседа на Kelsey Hightower

Трябва ли да казвам повече? Аз не мисля.

Видео

30. Използване на Rust за разработване на игри, Катрин Уест

Разговорът започва с „Това е може би най-скучното говорене ...“

Не е.

Това всъщност може да е най-доброто говорене в този списък.

Видео