Як Мартин Клеппман пройшов шлях від стартапів до створення вічної класики про розподілені системи
Мартин Клеппман для багатьох бекенд-інженерів – це автор культової книги «Designing Data-Intensive Applications», яка стала настільною для тисяч розробників. Однак його шлях до академічних висот починався зовсім інакше — він спершу створював цілком прикладні продукти: сервіс автоматизованого тестування Go Test It, а згодом розширення для Gmail під назвою Rapportive, яке потрапило до рук LinkedIn. Саме цьому практичному досвіду з реальними користувачами, обмеженим бюджетом і тиском інвесторів Клеппман завдячує унікальне бачення, як повинні працювати дані, інфраструктура та робочі колективи.
Ця розповідь не лише про книгу та Kafka, а скоріше про два стартапи з різними долями: один – гарно автономний і бутстреплений, інший – під крилом Y Combinator і з продажем LinkedIn, які разом сформували системне мислення Клеппмана, далеко за межами простого програмування.
Go Test It: коли технологія є, але бізнес не підхоплює
У 2008 році, коли веб-розробники боролися з несумісністю браузерів, Клеппман запустив Go Test It. Це був сервіс, який автоматизував перевірку роботи сайтів у різних браузерах, базуючись на відкритому Selenium. Завдання було зрозумілим: імітувати операції користувачів, щоб впевнитися, що все працює скрізь однаково. Продукт працював бездоганно з технічної точки зору, але ось з бізнесом виникли проблеми.
Річ у тім, що навіть якщо кросбраузерне тестування важливе, багато команд не готові знаходити час і зусилля на зміну власних процесів. Для них це було надмірним вкладенням поза межами термінів і тиску угод. Ось і вийшло, що чудове технічне рішення зіткнулося з непохитною інерцією звичних звичок.
Інші компанії, як Sauce Labs, змогли розвиватися в цьому ж сегменті, та навіть їм довелося звикати до повільного ринку без різкого вибуху.
Перший урок Клеппмана – інженерна краса і користь не завжди гарантують успіх. Зміна робочих процесів — тяжкий крок, який потребує більше, ніж технологій.
Бути бутстреп стартапом: коли кожна година роботи – це інвестиція
Go Test It фінансували власними силами: Клеппман заробляв консалтингом і вклав ці гроші в продукт. Друзям і знайомим пропонували працювати майже безплатно, а інвестиції ззовні були незначними. Така модель дає свободу без тиску пошуку великих інвесторів, але і не дає запасу для масштабних експериментів.
У цьому режимі важко грати у довгу: кожна нова функція – це компроміс між невідкладними грошима і потенціалом майбутніх прибутків. Тим не менше, цей досвід навчив Клеппмана вибирати технології, які легко підтримувати, і розуміти, як користувачі реагують на інструменти, які впливають на процеси.
Go Test It не став великим проривом, але заклав фундамент для подальших ідей і став школою реалістичного погляду на інженерний продукт.
Rapportive: коли соціальні мережі зустрічають електронну пошту
2010 року Клеппман та команда створили Rapportive — розширення для Gmail, яке додавало у вікно пошти соціальний контекст відправника. Замість холодної адреси можна було побачити фото, посаду, твіти і навіть пости з Facebook — коротко кажучи, спрощений соціальний профіль.
Це вирішувало практичну задачу: швидко зрозуміти, хто пише, і чи варто звертати увагу. Для сейлзів, фаундерів і рекрутерів це був справжній must have.
На відміну від Go Test It, тут не треба було ламати звички користувачів — вистачало одного натискання «встановити», і користь була помітна одразу. Такий низький поріг входу і чітка користь зробили Rapportive популярним доволі швидко.
Інженерно це була нетривіальна задача — інтегруватися в Gmail без порушень, але саме це дозволило продукту зайти безболісно.
З Великої Британії до Кремнієвої долини: шлях у світ великих стартапів
Rapportive став перепусткою у класичний стартап-нардний світ — команда пройшла через Y Combinator і переїхала до Сан-Франциско. Тут мережа контактів і доступ до інвесторів значно ширші, а тиск на зростання — відчутно більший.
Попри популярність, бізнес-модель складалась не просто: продукт ріс, але фінансова стійкість була під питанням. Врешті виникла пропозиція продажу LinkedIn, коли в компанії було лише п’ять людей.
Продаж став і класичним acqui-hire, і продуктово-стратегічним рішенням: LinkedIn отримав команду, що розбирається в соціальних даних, і продукт, якій доповнює їхню екосистему.
Не менш важливий факт – візові обмеження засновників, які ускладнювали довготривалу роботу без стабільності, зробили продаж меншою «поганою» необхідністю, ніж здійснення мрії. Але дивлячись пізніше — це виявилось успішним кроком для всіх.
Практика в LinkedIn: можливості, експерименти й уроки провалу
Після поглинання команда Rapportive фактично працювала майже незалежно у межах LinkedIn, продовжуючи інтегрувати соціальний контекст у пошту.
Розширення для Gmail залишили в підтримці, а увагу переключили на LinkedIn Intro — новий продукт, який працював безпосередньо у еко-системі платформи. За автономією та довірою LinkedIn зайшов далеко для невеликої купленої команди.
Втім, продукт натрапив на складну реакцію ринку і невдовзі закрився. Та команда отримала важливий досвід: підтримку від великої корпорації навіть у разі невдач, свободу на експерименти і навички роботи з масштабними системами.
Згодом Мартин перейшов у внутрішній відділ, де опановував Kafka й Samza — технології, що лягли в основу його майбутнього книги.
Технічний бекграунд Rapportive: проста архітектура – велика ідея
Попри бізнесові метаморфози, бекенд Rapportive був досить звичним: Ruby on Rails, PostgreSQL і Redis. Ніяких коштовних NoSQL або графових баз, що було навпаки цікавим вибором.
Адже продукт працював із соціальними графами — зв’язками, профілями, вплетеними у соціальні мережі. Замість запускатися на спеціалізованій графовій базі, Клеппман побудував подібну технологію поверх реляційної структури.
Це означало, що логіку графа втілювали у структурі таблиць і запитах SQL, покладаючись на надійність і звичність PostgreSQL, а Redis використовувався для швидкого кешування.
Такі рішення показують прагматизм у підході: вибирати інструменти, які добре знайомі, підтримані і прості в обслуговуванні, а не бігти за гучними трендами, що можуть додати операційних складнощів.
Які уроки можна винести з цієї історії
Шлях від Go Test It до Rapportive і подальша робота в LinkedIn демонструють, наскільки повсякденна реальність стартапів та інженерії впливає на формування системного мислення.
1. Навіть найкраще технічне рішення може не стати успішним бізнесом, якщо воно суперечить існуючим робочим процесам і не дарує миттєву вигоду власникам.
2. Бутстреп-стартап змушує бути економним, обирати перевірені технології і підлаштовувати продукт під обмеження.
3. Інструменти, які легко вписуються у щоденну працю користувачів, мають більші шанси на швидке та успішне впровадження.
4. Навіть у великих корпораціях для невеликих команд можливий простір для автономії та експериментів, хоча юрідичні та фінансові аспекти часто диктують правила гри не менш жорстко, ніж технічні.
5. І, нарешті, простота в технологічних стек-платформах — це не компроміс, а необхідність для підтримки реальних систем із реальними обмеженнями ресурсів.
Ця історія показує, що глибинне розуміння розподілених систем формується не лише у науковому середовищі чи на конференціях, а й у непростих реаліях маленьких команд, де технології тісно переплетені з фінансовими, юридичними й організаційними викликами.
Джерело
Designing Data-intensive Applications with Martin Kleppmann — The Pragmatic Engineer
