У 1980-х роках спеціальний комітет із міжнародних стандартів (більш традиційного складу) вирішував майбутнє компютерних мереж. У результаті, було сформовано мережеву модель OSIвичерпну й універсальну. Один із провідних фахівців писав 1986 року: «У довготривалій перспективі більшість продавців перейдуть від протоколу TCP/IP до Layer 4транспортного рівня мережевої моделі OSI. Та в короткотривалій перспективі протокол TCP/IP забезпечить організації функціональністю й захистить їхні інвестиції в обладнання, а згодом спростить перехід на OSI»130.
Не склалося. Найпростіші протоколи інтернету розвинулися й стали більш комплексними, а протокольний пакет OSI дістав статус базової моделі, що використовувалася при аналізі архітектури мереж. Архітектура всесвітньої павутини, що перегукувалася з радикальною схемою основних інтернет-протоколів, зумовила появу компютерних програм наступного покоління і поширення колись недосяжної мережевої технології серед мільярдів людей.
Отож мережі, які прагнуть вийти на масштабний рівень, повинні враховувати: проекти Open Source на зразок Linux і відкриті системи на зразок інтернету і всесвітньої павутини працюють не завдяки центральній платформі, яка ухвалює кожну нову версію, а завдяки тому, що розробники визначили чіткі правила співпраці й інтероперабельності.
Координація закладена в проекті системи.
Це ключовий принцип, який не тільки допомагає зрозуміти нинішніх гігантів у сфері інтернет-технологій, а й розібратися в тому, що не гаразд із ХЗ-економікою.
6. Обіцяні результати
Із впливом мережевих компаній на суспільство все зрозуміло, та слід враховувати, як по-різному влаштовані ці мережі.
Після мого cаміту Open Source 1998 року я підготував «агітаційну презентацію» про основні принципи програмного забезпечення Open Source, хакерську культуру й інтернет. На одному зі слайдів я пояснював, чому спільнота розробників софту Open Source або мережа, не обмежена дозволами, як-от інтернет, є такими потужними:
Архітектура участіце схема, за якої користувачі розширюють платформу.
Мінімум барєрів для експериментів і максимум інновацій завдяки тому, що система сприяє «хакерству».
Інтероперабельність дає змогу замінювати компонент або сервіс, у разі появи кращого.
Барєри для зміни постачальника потрібні тому, що користувачам необхідні ваші послуги, а не тому, що ви маєте абсолютний контроль.
Ще я розповідав, як платформи зароджуються й еволюціонують. Спочатку хакери й ентузіасти досліджують потенціал нової технології. Потім вона приваблює підприємців, і, намагаючись побудувати успішний бізнес, фахівці спрощують її для користувачів. Провідні гравці індустрії розробляють платформу й обмежують доступ барєрами. Розвиток загальмовується; хакери й підприємці рухаються далі, шукають нових горизонтів. Іноді (на жаль, тільки іноді) вдається побудувати здорову екосистему, де хакери, підприємці і платформи грають у квача. Абсолютних барєрів для зміни постачальника немає, і всім треба вдосконалюватися, щоб не втрачати конкурентоспроможності.
Потім я показував слайд «Урок історії», де останній пункт був «родзинкою» презентації: «Стратегія платформи завжди перемагає стратегію програми!».
Платформа завжди перемагає програму
Джефф Безос слухав презентацію на нашій конференції ETech, присвяченій перспективним технологіям, і 2003 року попросив мене виступити перед групою девелоперів Amazon.
Раніше, у березні 2001 року, я літав у Сіетл: намагався переконати Джеффа, що компанії Amazon слід надавати доступ до своїх даних через веб-сервіси131. Для дослідження ринку OReilly кожні три години використовувала на Amazon «веб-павука» в пошуку інформації про ціни, рейтинги, кількість сторінок і відгуки на книжки нашого видавництва і конкурентів. Мені здавалося, що «веб-павук»зайвий клопіт, адже доводилося завантажувати багато зайвої інформації й виокремлювати найголовніше. Я був переконаний, що величезний каталог продукції Amazonілюстративний приклад масиву даних, до яких потрібен доступ на програмному рівні через веб-сервіси API. Такий підхід вписувався в «Операційну систему інтернету» наступного покоління, яку я проповідував.
Джеффа ідея заінтригувала, а потім зясувалося, що група розробників Amazon на чолі з інженером Робом Фредеріком саме працювала над проектом веб-сервісів. Окрім того, Джефф виявив, що багато інших малих компаній, так само як OReilly, користуються на Amazon «веб-павуками» і розробляють неавторизовані інтерфейси до даних компанії. Замість чинити опір, Джефф зібрав нас разом, щоб ми чогось навчилися один в одного і допомогли Amazon виробити стратегію.
Памятаю, Джеффа розчарував мій виступ на тій міні-конференції девелоперів Amazon. Він підскочив з останнього ряду, щойно я завершив, і сказав: «Ви ж нічого не розповіли про те, що платформа завжди перемагає програму!». Тому, виступаючи на зустрічі зі співробітниками Amazon у травні 2003 року, я виправився132.
Веб-сервіси першого покоління, які гігант електронної торгівлі запровадив 2003 року, надавали доступ до внутрішнього каталогу продукції та базових даних. Інфраструктурні сервіси, випущені 2006 року в рамках пакету AWS (Веб-сервіси Amazon), були вже геть іншими. AWS започаткував велику трансформацію в індустріїте, що нині називають хмарними обчисленнями. Ті сервіси були розроблені зовсім з інших причин, але хочеться вірити, що і я доклав руку: переконав Джеффа, що для подальшого процвітання Amazon мала стати чимось більшим за додаток для електронної торгівлі, а самеплатформою.
Джефф має особливий талант: продумувати й розвивати будь-яку ідею. Тож він розвинув ідею з платформою набагато більше, ніж мені уявлялося. У короткому інтервю Омові Маліку 2008 року Джефф пояснив: «Усе почалося чотири роки тому. Ми в Amazon розуміли, що витрачаємо забагато часу на ретельну координацію між інженерією та програмуванням у мережі. Отож вирішили розробити низку прикладних програмних інтерфейсів (API) між двома рівнями, щоб обмежитися загальною координацією»133. (Ось і «слабко звязані деталі»).
Це важливо, бо сервіси AWS вирішували проблему організаційної моделі. Джефф розумів принцип, який має враховувати будь-яка мережева компанія ХХІ століття. Як сказав консультант із людських ресурсів Джош Берсін, «працювати в цифровій галузі і бути цифровою компанієюрізні речі».
За цифрової доби, онлайн-сервіс і компанія, яка його розробляє, мають стати одним цілим.
У кожній бізнес-школі треба розповідати, як Джефф вивів ідею перетворення Amazon на платформу з площини програмного забезпечення в площину організаційної моделі.
Як це сталося, описав колишній інженер Amazon Стів Йеґґе колегам із Google. Інформація, яку він запостив, випадково поширилася в інтернеті й умить розійшлася серед девелоперів. Той пост Йеґґе відомий як «Стівова ода платформам» (Steveys Platform Rant). Це настанова, яку, за словами Йеґґе, Джефф Безос написав, «якщо не помиляюся, десь так 2002-го, плюс-мінус рік». Ось пост Стіва Йеґґе:
Велика Настанова була приблизно такою:
1. Відтепер усі команди розробників викладають свої дані й функціонали на сервісних інтерфейсах.
2. Команди повинні взаємодіяти між собою через ці інтерфейси.
3. Жодні інші комунікації в процесі роботи не дозволяються: посилання, зчитування архівів збережених даних інших команд, моделі спільної памятіжодних лазівок. Допускається лише комунікація шляхом звернень через сервісні інтерфейси в мережі.
4. Байдуже, які технології використовуються в роботі: HTTP, Corba, Pubsub чи клієнтські протоколине має значення. Безосу байдуже.
5. Усі сервісні інтерфейси треба від початку розробляти для екстерналізації. Команди мають планувати й розробляти продукти так, щоб була можливість викласти інтерфейс для зовнішніх девелоперів. Винятків бути не може.
6. Тих, хто порушить це правило, буде звільнено134.
Джефф виходив із того, що Amazon ніколи не стане платформою, якщо не будувати її, починаючи з фундаменту, тобто з тих API, що пропонуватимуться зовнішнім девелоперам.
Отож протягом наступних кількох років Amazon переформатувала систему: було створено комплекс фундаментальних сервісів (зберігання, обчислювання, очікування тощо), до яких девелопери компанії мали доступ через стандартизовані програмні інтерфейси. До 2006 року ці сервіси були достатньо надійними, гнучкими, із чітко визначеними інтерфейсами, і їх можна було пропонувати клієнтам Amazon.