Читати книгу - "ХЗ. Хто знає, яким буде майбутнє"

Із впливом мережевих компаній на суспільство все зрозуміло, та слід враховувати, як по-різному влаштовані ці мережі.

Після мого cаміту Open Source 1998 року я підготував «агітаційну презентацію» про основні принципи програмного забезпечення Open Source, хакерську культуру й інтернет. На одному зі слайдів я пояснював, чому спільнота розробників софту Open Source або мережа, не обмежена дозволами, як-от інтернет, є такими потужними:

• Архітектура участі — це схема, за якої користувачі розширюють платформу.

• Мінімум бар’єрів для експериментів і максимум інновацій завдяки тому, що система сприяє «хакерству».

• Інтероперабельність дає змогу замінювати компонент або сервіс, у разі появи кращого.

• Бар’єри для зміни постачальника потрібні тому, що користувачам необхідні ваші послуги, а не тому, що ви маєте абсолютний контроль.

Ще я розповідав, як платформи зароджуються й еволюціонують. Спочатку хакери й ентузіасти досліджують потенціал нової технології. Потім вона приваблює підприємців, і, намагаючись побудувати успішний бізнес, фахівці спрощують її для користувачів. Провідні гравці індустрії розробляють платформу й обмежують доступ бар’єрами. Розвиток загальмовується; хакери й підприємці рухаються далі, шукають нових горизонтів. Іноді (на жаль, тільки іноді) вдається побудувати здорову екосистему, де хакери, підприємці і платформи грають у квача. Абсолютних бар’єрів для зміни постачальника немає, і всім треба вдосконалюватися, щоб не втрачати конкурентоспроможності.

Потім я показував слайд «Урок історії», де останній пункт був «родзинкою» презентації: «Стратегія платформи завжди перемагає стратегію програми!».

Джефф Безос слухав презентацію на нашій конференції ETech, присвяченій перспективним технологіям, і 2003 року попросив мене виступити перед групою девелоперів Amazon.

Раніше, у березні 2001 року, я літав у Сіетл: намагався переконати Джеффа, що компанії Amazon слід надавати доступ до своїх даних через веб-сервіси131. Для дослідження ринку O’Reilly кожні три години використовувала на Amazon «веб-павука» в пошуку інформації про ціни, рейтинги, кількість сторінок і відгуки на книжки нашого видавництва і конкурентів. Мені здавалося, що «веб-павук» — зайвий клопіт, адже доводилося завантажувати багато зайвої інформації й виокремлювати найголовніше. Я був переконаний, що величезний каталог продукції Amazon — ілюстративний приклад масиву даних, до яких потрібен доступ на програмному рівні через веб-сервіси API. Такий підхід вписувався в «Операційну систему інтернету» наступного покоління, яку я проповідував.

Джеффа ідея заінтригувала, а потім з’ясувалося, що група розробників Amazon на чолі з інженером Робом Фредеріком саме працювала над проектом веб-сервісів. Окрім того, Джефф виявив, що багато інших малих компаній, так само як O’Reilly, користуються на Amazon «веб-павуками» і розробляють неавторизовані інтерфейси до даних компанії. Замість чинити опір, Джефф зібрав нас разом, щоб ми чогось навчилися один в одного і допомогли Amazon виробити стратегію.

Пам’ятаю, Джеффа розчарував мій виступ на тій міні-конференції девелоперів Amazon. Він підскочив з останнього ряду, щойно я завершив, і сказав: «Ви ж нічого не розповіли про те, що платформа завжди перемагає програму!». Тому, виступаючи на зустрічі зі співробітниками Amazon у травні 2003 року, я виправився132.

Веб-сервіси першого покоління, які гігант електронної торгівлі запровадив 2003 року, надавали доступ до внутрішнього каталогу продукції та базових даних. Інфраструктурні сервіси, випущені 2006 року в рамках пакету AWS (Веб-сервіси Amazon), були вже геть іншими. AWS започаткував велику трансформацію в індустрії — те, що нині називають хмарними обчисленнями. Ті сервіси були розроблені зовсім з інших причин, але хочеться вірити, що і я доклав руку: переконав Джеффа, що для подальшого процвітання Amazon мала стати чимось більшим за додаток для електронної торгівлі, а саме — платформою.

Джефф має особливий талант: продумувати й розвивати будь-яку ідею. Тож він розвинув ідею з платформою набагато більше, ніж мені уявлялося. У короткому інтерв’ю Омові Маліку 2008 року Джефф пояснив: «Усе почалося чотири роки тому. Ми в Amazon розуміли, що витрачаємо забагато часу на ретельну координацію між інженерією та програмуванням у мережі. Отож вирішили розробити низку прикладних програмних інтерфейсів (API) між двома рівнями, щоб обмежитися загальною координацією»133. (Ось і «слабко зв’язані деталі»).

Це важливо, бо сервіси AWS вирішували проблему організаційної моделі. Джефф розумів принцип, який має враховувати будь-яка мережева компанія ХХІ століття. Як сказав консультант із людських ресурсів Джош Берсін, «працювати в цифровій галузі і бути цифровою компанією — різні речі».

За цифрової доби, онлайн-сервіс і компанія, яка його розроб­ляє, мають стати одним цілим.

У кожній бізнес-школі треба розповідати, як Джефф вивів ідею перетворення Amazon на платформу з площини програмного забезпечення в площину організаційної моделі.

Як це сталося, описав колишній інженер Amazon Стів Йеґґе колегам із Google. Інформація, яку він запостив, випадково поширилася в інтернеті й умить розійшлася серед девелоперів. Той пост Йеґґе відомий як «Стівова ода платформам» (Stevey’s Platform Rant). Це настанова, яку, за словами Йеґґе, Джефф Безос написав, «якщо не помиляюся, десь так 2002-го, плюс-мінус рік». Ось пост Стіва Йеґґе:

Велика Настанова була приблизно такою:

1. Відтепер усі команди розробників викладають свої дані й функціонали на сервісних інтерфейсах.

2. Команди повинні взаємодіяти між собою через ці інтерфейси.

3. Жодні інші комунікації в процесі роботи не дозволяються: посилання, зчитування архівів збережених даних інших команд, моделі спільної пам’яті — жодних лазівок. Допускається лише комунікація шляхом звернень через сервісні інтерфейси в мережі.

4. Байдуже, які технології використовуються в роботі: HTTP, Corba, Pubsub чи клієнтські протоколи — не має значення. Безосу байдуже.

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