Раздел 5.2. Инфраструктура как сервис (AWS): Указ Безоса (2002 — ...)

В этом разделе мы увидим, как параноидальная внутренняя политика одной компании по продаже книг случайно создала самую мощную инфраструктуру в истории интернета. Это история о том, как Джефф Безос, пытаясь навести порядок в своем доме, построил фундамент для Airbnb, Netflix, Uber и половины современного веба.

Раздел 5.2. Инфраструктура как сервис (AWS): Указ Безоса (2002 — наше время)

В начале 2000-х Amazon был просто большим книжным магазином, который отчаянно пытался стать «магазином всего» (The Everything Store), продавая игрушки и тостеры. Внутри компании царил технологический ад.

Монолит: Сайт amazon.com был гигантским куском кода (C++ и Perl). Когда программисты добавляли кнопку «Купить» для игрушек, они случайно ломали поиск по книгам.
Спагетти-связи: Сотни команд наступали друг другу на ноги. Если команда «Рекомендаций» хотела узнать историю покупок пользователя, она писала SQL-запрос напрямую в базу данных команды «Заказов».
Merchant.com: Amazon пыталась продавать свой движок другим магазинам (Target, Toys"R"Us), но не могла отделить его от собственных данных.

Разработка новой фичи занимала месяцы. 70% времени инженеры тратили не на код, а на настройку серверов и согласование доступа к базам данных. Джефф Безос, человек с мышлением инженера и жестокостью диктатора, решил разрубить этот гордиев узел одним ударом.

А. The API Mandate: Меморандум, изменивший мир

Легенда о письме

Примерно в 2002 году (точная дата варьируется в легендах, но суть подтвердил инженер Стив Йегге в своем знаменитом посте) Безос разослал по всей компании письмо. Оно не было приглашением к дискуссии. Это был ультиматум.

Вот его суть (в вольной реконструкции):

Все команды отныне будут предоставлять свои данные и функционал только через сервисные интерфейсы (API).
Запрещаются любые другие способы коммуникации: никакого прямого чтения чужих баз данных, никакого использования разделяемой памяти, никаких бэкдоров. Только сетевые вызовы.
Неважно, какую технологию вы используете (HTTP, Corba, PubSub). Главное — интерфейс.
Самое важное: Все интерфейсы должны быть спроектированы так, чтобы их можно было выставить во внешний мир. Никаких исключений. Вы должны строить так, будто вашим API завтра будут пользоваться разработчики не из Amazon, а хакеры из гаража.
Наказание: Любой, кто не выполнит этот указ, будет уволен.
Хорошего дня!

Что это значило на практике?

Это была принудительная Сервис-Ориентированная Архитектура (SOA). Безос заставил Amazon превратиться из монолита в набор сотен независимых стартапов.

Команда «Корзины» больше не знала, как устроена база данных «Склада». Она просто посылала запрос: GetStock(ItemID) и получала ответ.
«Правило двух пицц»: Безос ввел правило, что команда должна быть такой маленькой, чтобы её можно было накормить двумя пиццами (6-8 человек). Каждая такая команда владела своим микросервисом и своим API.

Это было больно. Разработка замедлилась на два года. Инженеры ненавидели Безоса, потому что им приходилось писать кучу лишнего кода («обертки», документацию, авторизацию). Но через два года произошло чудо. Amazon стал невероятно гибким. Команды могли обновлять свои сервисы (например, «Поиск») независимо друг от друга, не роняя весь сайт.

Прозрение: «Undifferentiated Heavy Lifting»

В 2003 году топ-менеджеры Amazon — Энди Джесси (тогда тень Безоса, сейчас CEO Amazon) и Вернер Фогельс (CTO, академик) — провели стратегическую сессию в доме Безоса. Они проанализировали проблемы и поняли странную вещь:

«Мы тратим 70% времени не на улучшение магазина, а на "недифференцированную тяжелую работу" (undifferentiated heavy lifting): закупку серверов, настройку баз данных, организацию хранилища. И мы стали в этом чертовски хороши. Никто в мире не умеет так масштабироваться, как мы».

Безос спросил: «А что, если мы будем продавать эту компетенцию другим?». Логика была железной: если мы заставили свои команды общаться через внешние API (по указу 2002 года), значит, мы технически готовы пустить туда чужих разработчиков. Нам даже не надо ничего переписывать.

Так родился проект AWS (Amazon Web Services).

Рождение S3 и EC2 (2006)

В 2006 году Amazon без громких презентаций запускает два сервиса, которые перевернули IT.

Amazon S3 (Simple Storage Service): Бесконечный жесткий диск в облаке.
- Предложение: Вы можете загрузить туда хоть 1 байт, хоть 100 терабайт. Вы платите только за то, что заняли (тогда это было $0.15 за Гб). Никаких контрактов.
Amazon EC2 (Elastic Compute Cloud): Аренда виртуального компьютера.
- Шок рынка: Раньше, чтобы получить сервер, вы заказывали его у Dell или IBM, ждали 3 недели, везли в дата-центр, настраивали сеть. Минимальная цена входа — $10,000+.
- Предложение Amazon: Вы вводите номер кредитки, нажимаете кнопку, и через 30 секунд у вас есть root-доступ к серверу Linux. Цена — 10 центов в час. Когда сервер не нужен, вы его удаляете и перестаете платить.

Реакция рынка: Гиганты смеялись. Ларри Эллисон (Oracle) шутил: «Облака — это просто вода. Это мода. Кто будет хранить данные у продавца книг? Это игрушка для стартапов». IBM и HP считали, что «серьезный бизнес» никогда не доверит свои данные публичному интернету. Они не понимали, что "игрушки" захватывают мир снизу.

Б. CapEx vs OpEx: Экономическая революция

AWS совершила не столько технологическую (виртуализация уже была), сколько экономическую революцию. В корпоративных финансах есть два типа расходов:

CapEx (Capital Expenditures): Капитальные расходы. Покупка завода, станка или сервера. Это «длинные деньги», которые требуют утверждения советом директоров и амортизируются годами.
OpEx (Operating Expenditures): Операционные расходы. Зарплата, электричество, вода, аренда. Это деньги «здесь и сейчас».

Старый мир (до AWS)

Представьте, что вы хотите запустить «Убийцу Facebook» в 2004 году.

Вам нужно купить 50 серверов, чтобы выдержать нагрузку, если вы вдруг станете популярным.
Это стоит $100,000. Плюс аренда стойки в дата-центре. Плюс зарплата сисадмина.
Вы идете к венчурным инвесторам и просите деньги на железо.
Если стартап провалился (а это 90% случаев), у вас остается груда никому не нужного металла. Инвестор потерял деньги.

Новый мир (после AWS)

Вы запускаете стартап в 2008 году (например, Airbnb или Pinterest).

Вы не покупаете сервера. Вы арендуете маленький сервер на AWS за $50 в месяц (OpEx).
Вы платите с личной кредитки. Вам не нужны инвесторы на старте.
Если к вам пришел трафик (о вас написали в TechCrunch), вы запускаете скрипт, и Amazon автоматически выделяет вам еще 100 серверов на пару часов.
Если трафик ушел (ночь), вы отключаете сервера.
Если стартап провалился, вы просто закрываете аккаунт. Ваши потери — $200.

Эффект: Это снизило порог входа в IT-бизнес практически до нуля. Студенты в общежитии получили доступ к той же вычислительной мощности, что и транснациональные корпорации.

Кейсы:

Dropbox: Дрю Хьюстон и Араш Фердоуси построили многомиллиардный бизнес, не имея своих жестких дисков. Весь Dropbox первые годы — это просто удобная "морда" для Amazon S3.
Netflix: Главный конкурент Amazon в видео! В 2008 году у Netflix случился сбой в их собственном дата-центре, и они не могли отправлять DVD. Рид Хастингс принял решение: «Мы не умеем строить дата-центры. Мы переезжаем в облако».
- Netflix платит AWS сотни миллионов долларов. Amazon получает деньги от конкурента. Это уникальная ситуация "Coopetition" (Сотрудничество-конкуренция).

Смерть старого IT-рынка

Традиционные продавцы «железа» (Sun Microsystems, HP, Dell) не сразу поняли, что их убивают. Раньше IT-директор должен был планировать бюджет на год вперед.

«Нам нужно купить серверов с запасом на Черную пятницу».
В итоге 11 месяцев в году серверы простаивали (нагрузка 10%), но электричество жрали.

AWS дала Эластичность. В "Черную пятницу" Amazon добавляет себе мощностей столько, сколько есть у всей компании Walmart, а после распродажи отдает их обратно в общий пул. Никакой физический дата-центр не может дать такой гибкости.

Итог раздела: Джефф Безос доказал, что инфраструктура — это не актив, а коммунальная услуга (Utility), как вода из крана или электричество в розетке. Вы не копаете колодец, чтобы попить чаю. Вы открываете кран. Теперь у нас есть бесконечное железо по требованию. Но как управлять тысячами этих арендованных серверов? Настраивать их вручную — безумие. В следующем разделе мы узнаем, как Google (через Kubernetes) и Docker научили нас упаковывать приложения в контейнеры, чтобы они работали в этом новом облачном мире.