Прежде всего, хочу извиниться перед всеми, кто шлет мне слезные письма. Мол, Володенька, родненький, перестань писать непонятные посты, давай как раньше, чтоб за живое с кучей матов и смешно, и за жизнь чтоб, про политику, Тимошенко там или Обаму Хусейновича. Прочитаешь бывало, а потом детям покажешь и сам поржешь. Ну а сейчас с женой читаем и ничего не понимаем, зачем ты так с нами? Мы же твоя целевая аудитория. Так вот, аудитория, слушайте меня сюда, если кто мою Кристиночку. Я не ибигдан, не тема с двумя точками над буквой "е" и уж тем более не другой. Если кто не читал дисклеймер, то осмелюсь повторить его ключевую мысль здесь. Мне в хуй не упало, сколько людей меня читает, пишу я исключительно для себя, чего и вам желаю, солнышки вы мои. Вот такой вот я брутальный социопат, lmao.

А теперь перейдем непосредственно к теме сегодняшнего моего монолога. Google, не прошло и года как, прислал мне приглашение "на посмотреть" на облачную систему хранения больших объемов данных в массиве их content delivery network под названием Google Storage for Developers. Прислал очень неожиданно, всего через час после того, как я включил платный себе аккаунт на Google Apps Engine, это вам такой намек, хозяйке на заметку, зарегистрируйте свою карту в Google Checkout и инвайты приду сами собой, гугл не любит нищебродов, ага. Так вот, всем нам известен первопроходец, ставший практически монополистом в сфере cloud computing + storage. Amazon уже достаточно долгое время предоставляет за смешные деньги всем желающим возможность воспользоваться своим CDN для распространения контента по всему миру на больших скоростях. Тут нужно упомянуть о текущем бесспорном преимуществе S3 над GSfD, которое заключается в географической разветвленности датацентров амазона, гугл же пока дает место только на континенте демократии. Возможно, все изменится после выхода API из состояния бетатеста, все же у гугла серверных мощностей по всему миру будет побольше, чем 5 датацентров амазона. Вообще, такой вот фразой, про бетатест и раннюю стадию развития, можно оправдать отсутствие всего необходимого в Google Storage. Я думаю, что многие видели интерфейс AWS Management Console (кто нет - тут вам скриншоты), гугл в этом смысле немного отстает, предоставляя лишь базовый функционал создания ведра (мне нравится так переводить bucket, хотя, в принципе, корзина подходит много лучше), создания вложенных в ведро директорий, загрузки файлов и получения публичных ссылок на них. Все это выглядит у гугла подобным образом, и есть еще интерфейс управления ключами доступа. У Amazon все же лучше получилось, учитывая их расширенный copy-cut-paste функционал и выпадающее контекстное меню. Гугл не позволяет даже упорядочить файлы в ведре по их размеру или дате создания, что вообще печально. С другой стороны, тут есть любимый мной drag and drop, когда, перетянув файл в открытую вкладку GSfD, мы инициируем его загрузку. Не зря в свое время гугл очень суетился, проталкивая эту draggable file objects спецификацию в стандарт html, и использует ее сейчас практически во всех своих SaaS-ах. Недостатком является невозможность загрузки целой директории, путем ее перетаскивания, но это скорее security policy ограничение стандарта, а не интерфейса. Это что касается визуальных свистелок и перделок, теперь стоит сказать о том, что интересует developers, для которых, собственно, исходя из названия, и был сделан Google Storage, а именно - RESTful API сервиса. Для red-eye управления своим стореджем гугл сделал консольную утилиту под названием gsutil, которой можно сделать абсолютно любые операции над своими ведрами, но в то же время (вниманием), гугл не изобретала велосипед и сделала свой API абсолютно совместимым с API S3, а значит все утилиты требуют минимального фейслифта в виде смены ENDPOINT и xmlns для миграции с облаков на облака. Что касаемо модульной реализации для разных языков, то в качестве примера в Google выбрали boto - Python interface to Amazon Web Services c минимальным изменениями. Очень все это не похоже на гугл, ведь, по сути, даже сам gsutil это практически s3cmd. Скажу сразу, моя радость по поводу возможного объединения Google Apps Engine (все же blob storage c его глупым лимитом чтения 1MB per 1 API call заставляет писать неприятные ресурсоемкие велосипеды) и Google Storage for Developers была преждевременной, у URLFetch библиотеки - единственной "дырки", через которую можно выйти за пределы своего окружения в GAE, есть один неприятный лимит 1MB max upload and download per 1 API Call. Ах ты ж ебаный ты нахуй, не иначе. Все это, конечно, решаемо, но ценой процессорного времени, которое денежку стоит. Хотя, если посмотреть на Roadmap проекта, то гугловцы клянутся, что в ближайшем времени интеграция этих двух сервисов должна пройти в рамках GAE, искренне надеюсь, что без глупых лимитов. Что касается скоростей загрузки\отдачи, то мой опыт и обзоры в интернете показывают, что GSfD совсем немного быстрее, это вполне объяснимо менее активным его использованием. Так что и тут пальцем в небо. При всей моей любви к поисковому гиганту, я не могу найти хоть одно маломальское преимущество. Об этом мы и поговорим в завершении поста (тут могла бы быть шутка про Пасху, но нет).

Ну вот, раз мы теперь знаем, что у обеих компаний все одинаково, стоит спросить себя, а нафиг вообще гугл затеял эту возню и как он собирается переманивать клиентов? Правильным ответом могли бы стать цены, но нет. Сравните стоимость Amazon S3 (я уже молчу про их RRS) и Google Storage for Developers. И без калькулятора видно, что даже в самом дорогом датацентре цены у амазонки то пониже будут, я уже молчу про наличие одного бесплатного гигабайта out-трафика в качестве вкусной плюшки для мелких сайтов или экспоненты снижения стоимости bw при большом потреблении. Какие мотивы остаются у гугла для разработчиков? Только лишь географическая распределенность хранилища и тесная интеграция со своей вычислительной платформой Google Apps Engine. Ни первое, ни второе не реализовано, а есть только громкое имя, копипаст технологии, завышенные цены и пока еще не совсем определенное будущее. Будем надеяться, что гугл, как и в случае с Google Apps, оставит небольшую бесплатную квоту, которой будет хватать для личного, небольшого приложения, тем самым завлекая разработчиков на свой сервис. Других путей достижения успеха, а не создания очередного сервиса аля Google Buzz (много шумихи, драка за инвайты, обзор месяца на слешдоте и т.д., и т.п., но пользуются единицы), я не вижу.

Возможно, данная статья должна была увидеть свет где-то год, а то и два года тому назад, а в наши с вами времена покорения космоса подобные размышления уже отдают не первой свежестью, но, тем не менее, только теперь у меня появилось время опробовать платформу гугла под разработку ресурсоемких приложений в облаках и повосхищаться ее возможностями и продуманностью. Я не буду детально останавливаться на описании самой технологии, об этом тонны книг и тысячи блогов уже написали, а лишь расскажу о плюсах и недостатках, ну и в конце поста - приведу пример и код реально работающего приложения. Скажу сразу, до знакомства с Google App Engine у меня уже был накоплен значительный опыт работы в облачных сервисах, преимущественно от компаний Amazon и Rackspace, а значит сравнивать мне есть с чем, хотя сравнение тут не особо уместно. Если вам все же лень читать описание всех этих клауд компьютингов, то постараюсь объяснить просто. Гугл предоставляет свою платформу, что-то вроде обычного шаред хостинга или готовый environment скорее, на котором уже установлены практически полнофункциональная версии Python и значительно куцая версия Java, которые обвешаны сверху разным API от гугла, в частности это интерфейсы хранения бинарных данных в BlobStorage, хранения табличных данных (как сложно писать тех. статью на русском, table data все же звучит как-то привычней) в подобии (еще раз, подобии, relation-ы тут реализуемы с помощью референсов, а это не совсем то) реляционной БД интересно объединенной с key-value стореджем в виде DataStorage, свой UrlFetch, своя реализация cron-а и многое другое. Лимитами же являются полное read-only операций с файловой системой и определенные ограничения в использовании системных ресурсов в виде процессорного времени, трафика и такого прочего, что, впрочем, стоит сущие копейки и элементарно докупается при первой надобности и применимо к аналогам-конкурента. Что касаемо того же Amazon EC2 или Mosso Rackspace, то вы получаете свой instance в виде голой операционной системы, которую должны настроить и запустить свой сервис на ней. Является ли это преимуществом? Однозначно, ведь вы, по сути, ограничены только материально и, как следствие из первого ресурса, лимитами облачной машины, которую сами и купили купили. К тому же, переносимость проекта на амазоновских или рэкспейсовских облаках не создает никаких проблем, в то время, как GAE - уникальная в своем роде платформа и без кардинальной смены кода вы никуда от нее не уйдете (нет, уйти то конечно можно, но не далеко и на костылях). Вот тут на самом деле вам может серьезно пригодится MVC паттерн для вынесение модели вне логики, на всякий пожарный. Что же до недостатков амазоновских иластиков - есть и такие. В частности, необходимость настройки программного обеспечения, его оптимизации и наличие прокладки в виде ОС между массивом облаков с виртуализацией и процессом пользователя дает меньшее быстродействие. Но, как я уже говорил, платформы абсолютно разные. Если GAE - только веб приложения, то AEC2 - все, что можно запустить в linux\windows окружении. Если вообще простым языком говорить, то в случае с GAE вы работаете на стройке, где уже готов фундамент и можно строить что хочешь, но только кирпичами и цементом гугла, которые строго ограничены и за превышения квот нужно платить, зато фундамент настолько крепкий, что не рухнет даже при землетрясении, т.к. выстроен профессионалами, то в AEC и иже с ним у вас есть площадка земли, вы можете завести те же кирпичи, вырыть котлован, построить дом, но нет никаких гарантий, что он не рухнет от ветра потому что вы забыли домешать песок в цемент или ваш root пароль брутфорсится за пол часа. Зато на этой же земле можно ничего и не строить, а засадить все цветами. В то время, как с гуглом такой номер не пройдет.

Существуют и более серьезные недостатки GAE, как, например, невозможность привязать к своему приложению naked домен. Ну в смысле без сабдомена www, все это связано с технической особенностью, когда load balancing осуществляется с помощью направления всех запросов через CNAME ghs.google.com, а CNAME не может быть прилеплен вместо главное A записи. Приходится делать фитны ушами и искать дополнительные www-лайзеры или url-форвардеры, которые будут перенаправлять все запросы с голого домена на www, что само по себе противоречит идее распределения нагрузок, все эти сабдомены - прошлый век, как по мне. Еще есть некоторые глупые лимиты касаемо максимального куска данных, получаемого urlfetch за раз, лимит времени исполнения в 30 секунд, достаточно бородатая версия питона и django, кривая реализация сессий и много других спорных моментов. Впрочем, в отличии от конкурентов, гугл дает нам бесплатный аккаунт с квотами, которых хватит для маломальского приложения с головой, лишая нас проблем с бекапом данных, постоянными обновлениями серверного ПО, переживаниями по поводу новой уязвимости в apache или mysql, provision control (тут он хоть и примитивный, но удобный деплой с возможностью запуска нескольких версий приложения на разных сабдоменах аппспота) и такого прочего. Ну, пожалуй, хватит переливать из пустого в порожнее. Вернемся к реальному применению платформы GAE. У меня есть свой укорачиватель ссылок, который крутится на домене mclnk.me. Просто однажды были у меня сертификат на свободный домен и много времени, а хотелось ссылку короче битли и с просмотром контента типа роликов ютуба и картинок. До недавнего времени, она (обрезалка, укорачивалка - как хотите), как и весь этот блог, была написана на PHP и кушать особо не просила, но, путем случайного выбора, стала кандидатом на перенос себя в облака Google. В качестве языка реализации я выбрал Python. Он мне нравится с момента далеко знакомства в его бытности еще сырым языком первых версий, именно на данном инструменте должны учить программировать студентов, а не засорять их головы бейсиками да паскалями. Питон учит лаконичности, правильной разметке кода и дзену программирования. А вот второй вариант, Java, мною нелюбим за его избыточность. Нет, я конечно понимаю, что это обусловлено исключительно добрыми побуждениями и минимизирует вероятность возникновения ошибок исполнения в дальнейшем, но писать несколько экранов кода для элементарного функционала при ограниченных ресурсах времени, не седых пока еще волос и энергетиков мне не кажется целесообразным. Код приложения выглядит подобным образом, прошу прощения, что все навалено в кучу и пару раз я схалтурил (как при проверке валидности ссылки, например), но делалось это в прямом смысле на коленке левой рукой. Укорачиватель ссылок публично доступен по адресу http://mclnk.me, а результат обрезания выглядит подобным образом http://mclnk.me/e.

В качестве заключения, у GAE есть своя ниша, ведь достаточно мощный RDS (lighttpd + php-fcgi + mysql на другом хосте) начинал захлебываться с la под 2 при ab -n 1000 -c 500, а вот google hosted проглотил и даже не подавился, подняв 25 инстансов для обработки запросов и отдав все без дилеев (речь сейчас не об link shortener, разумеется). Много пока еще не хватает, тот же Google Storage, который сейчас только по инвайтам и, если верить слухам, должен стать серьезным конкурентам Amazon S3, но Roadmap проекта внушает хорошие надежды в светлое будущее. Подумайте только об одном, а нужно ли вам это? Или пусть дальше ваш уютненький бложек живет на хостинге по $3 в месяц? Я же просто попробовал это just for fun и решил для себя, что следующий крупный проект с уверенностью можно поднимать на платформе Google App Engine, сэкономив деньги, нервы и бесценное время.