В 2010 году у нас был выделенный сервер в дата-центре колокации. Стоечный сервер 1U, двойные процессоры Xeon, 16ГБ RAM, RAID-1. Стоимость: $400/месяц за аренду места плюс стоимость железа ~$3500. Новый сервер? Нужно заказать железо, ждать доставки, физически установить (или платить дата-центру), установить ОС через KVM.
Новый проект? Тот же сервер. Он запускал Apache, MySQL, PHP и растущую коллекцию клиентских сайтов, которым нечего было делать на одной машине.
Amazon Web Services запустила EC2 в августе 2006. Мы игнорировали её годами - непонятное ценообразование, примитивный инструментарий, и «облако» звучало как маркетинговый термин для чужого компьютера. К 2010 начали обращать внимание. К 2013 - полностью перешли.
Кривая обучения EC2
Наш первый EC2 инстанс (сентябрь 2010):
# AWS CLI v1 (Ruby-based)
ec2-run-instances ami-6936fb00 \
--instance-type t1.micro \
--key-name aunimeda-key \
--group web-sg \
--region us-east-1
ec2-allocate-address
ec2-associate-address -i i-12345678 54.23.45.67
ssh -i ~/.ssh/aunimeda-key.pem ubuntu@54.23.45.67
Затем обычный Linux setup: apt-get install apache2 mysql-server php5... точно как на физической машине, но без ожидания доставки железа. Первый раз запустить сервер за 90 секунд вместо 3 недель - бизнес-модель изменилась.
Откровение с ценами. t1.micro стоил $0.02/час в 2010. $14.40/месяц. Для среды разработки, нужной только в рабочее время, можно было останавливать по вечерам и выходным: ~215 часов/месяц × $0.02 = $4.30/месяц. Наш $400/месячный выделенный сервер работал 24/7 для сайтов с 500 посетителями/день. Экономика была неправильной.
S3: откровение
До S3: файлы пользователей хранились в файловой системе веб-сервера. Бэкапы через rsync. Если сервер умирал - файлы потенциально терялись.
// Старый подход: файлы на сервере
$uploadDir = '/var/www/html/uploads/';
move_uploaded_file($_FILES['image']['tmp_name'], $uploadDir . $filename);
// Новый подход: файлы на S3
$result = $s3->putObject([
'Bucket' => 'aunimeda-uploads',
'Key' => 'images/' . $filename,
'SourceFile' => $_FILES['image']['tmp_name'],
'ContentType' => $_FILES['image']['type'],
'ACL' => 'public-read',
]);
$imageUrl = $result['ObjectURL'];
Последствия: загрузки переживали замену серверов. Хранилище масштабировалось без планирования ёмкости. Гарантия надёжности S3 (99.999999999% - одиннадцать девяток) была несравнимо лучше одного RAID-диска. Стоимость - $0.023/ГБ/месяц.
Heroku: деплой без инфраструктуры
Heroku абстрагировал всю инфраструктуру: никакого SSH, никакой настройки сервера, никакой конфигурации Apache. Просто пушишь код.
heroku create aunimeda-app
heroku config:set DATABASE_URL=postgres://...
heroku config:set SECRET_KEY=randomstring
# Деплой: git push = деплой
git push heroku main
heroku ps:scale web=2 # Два веб-динос
heroku ps:scale worker=1 # Один фоновый воркер
heroku logs --tail
Procfile определял, что запускается:
web: gunicorn app:app
worker: python worker.py
Для стартапа без ops-инженеров Heroku был трансформативным. Один разработчик мог задеплоить production Rails или Python приложение с Postgres, Redis и фоновыми воркерами за 30 минут.
Момент автоскейлинга
Самой мощной функцией AWS был не EC2 и не S3. Это были Auto Scaling Groups - серверы, масштабирующиеся под нагрузкой и сворачивающиеся при снижении трафика.
Наше первое настоящее событие масштабирования произошло во время ТВ-рекламы клиента. Региональный ритейлер запустил 30-секундный ролик в 21:00 прайм-тайм. Страница товара получила 2400 одновременных посетителей за 5 минут после показа рекламы, при обычной нагрузке 40 одновременных.
Без автоскейлинга: сервер бы упал. С Auto Scaling: 6 серверов запустились за 4 минуты. Трафик обработан. Реклама закончилась, серверы завершены через 30 минут. Доп. затраты: ~$0.40. Если бы мы провизионировали выделенным железом под пиковый трафик, имели бы 6 серверов простаивающих 23.5 часа в сутки.
Изменение мышления
Самое фундаментальное изменение от физического к облаку было психологическим.
Физические серверы были питомцами: именованными, тщательно обслуживаемыми, оплакиваемыми при поломке. Облачные серверы были скотом: пронумерованными, заменяемыми, завершаемыми без сожаления при неисправности.
Этот сдвиг сделал возможными автоматические деплои без страха: если деплой сломал сервер - завершаем его и запускаем новый из известного AMI. Blue-green деплои: запускаем новые серверы с новым кодом, направляем трафик, завершаем старые. Никаких окон обслуживания.
Миграция в облако была не просто переносом инфраструктуры на чужое железо. Это было изменение отношения между разработчиками и операциями - начало того, что назовут DevOps.