2012 год. Мечты сбываются.
Счастье потенциального пользователя очевидно. Интересно другое: чем обернется переход от десктопного приложения к облачному сервису для компании-разработчика? Не только для TGS Labs, но и для любой другой компании, переводящей свой продукт в облака. Какие преимущества получит компания, с какими трудностями может столкнуться и каким аспектам стоит уделить особое внимание?
Все зайцы - одним выстрелом
Компания-разработчик обслуживает одну систему, с которой работают все пользователи. Не нужно поддерживать три предыдущих версии, выдерживать обратную совместимость, с ужасом наблюдать, как очередной “security update” в операционной системе блокирует работу твоего продукта. Один облачный сервис - и компания получает армию пользователей на Windows 7, Ubuntu и Mac OS X. И никаких звонков в саппорт: “С включенным UAC в Windows 7 ваша программа не работает“ или “Когда вы будете поддерживать Linux?”. Все, что нужно - это обеспечить поддержку самых популярных браузеров.
Как слышно? Прием!
Облачный сервис - это быстрая обратная связь. В дооблачном мире пользователь скачивал триальную версию и практически терялся из виду. Либо программа ему нравилась, и он ее оплачивал, либо просто о ней забывал. Пользователей, которые не поленились рассказать о своих впечатлениях - единицы. В облаке с этим проще. Мы предоставляем пользователю возможность высказать свое мнение прямо на web-странице. Один клик - и в всплывающем окне пользователь сможет поделиться своими впечатлениями. Более того, с помощью Google Analytics или самопального логирования мы сможем понять, на какой именно странице остановился пользователь в процессе работы с сервисом. Мы можем обратиться к концепции A/B testing и опытным путем установить, какой вариант интерфейса в наибольшей степени отвечает потребностям пользователя.
Легче, гибче, быстрее!
При грамотной организации логирования разработчик видит все исключения, все непредвиденные обстоятельства, с которыми столкнулся пользователь. Обнаружен баг? Что ж, выпускаем фикс, проверяем в тестовом сервисе и заливаем в Production. Нет мороки с оповещением владельцев программ и многократным пережевыванием одних и тех же случаев то у одного пользователя, то у другого. Работа над фиксом начинается сразу же после первого обнаружения бага и завершается до того как на него наткнутся другие пользователи.
Чем могу служить?
У каждого стоящего продукта есть своя тусовка лояльных пользователей, которые с радостью встречают свежую версию продукта. Но таких пассионариев мало. Большинство пользователей не любит возиться со скачиванием и установкой новых версий. В случае облачного сервиса разработчик делает эту процедуру прозрачной и получает возможность обрадовать пользователя без дополнительных телодвижений со стороны последнего.
Sounds good, right? А теперь несколько слов о том, что нужно не забыть при таких радужных перспективах.
Все яйца в одной корзине
Да, да, да. Одним махом исправляем баг для всех пользователей и другим махом привносим другой баг для той же тусовки. У нас появилось больше гибкости, но нужно научиться ей не злоупотреблять и не спешить выкладывать фикс без надлежащей проверки. Иначе будет “один за всех, и все за одного”. Дедлоки - общие, забитые очереди - общие, downtime - общий.
Скажи мне кто твой друг
В большинстве случаев облачный сервис создается не на пустом месте. Компания-разработчик выбирает провайдера и строит свою систему на его ресурсах. Здесь важно не ошибиться с партнером. Не прикажет ли он долго жить? Насколько надежна и эффективна его инфраструктура (бесперебойная работа, функциональность API)? Что там в SLA? Насколько оперативно провайдер будет реагировать на потребности партнеров и потребности рынка? Насколько выгодна его система тарификации? Насколько легко можно будет перенести облачный сервис от одного провайдера к другому?
Дивлюсь я на небо та й думку гадаю
Мы становимся ответственными за данные пользователя. В случае локальной версии пользователь сам заботился о резервном копировании и восстановлении. Теперь об этом нужно думать нам: учитывать форс-мажорные обстоятельства и эффективно с ними справляться. Да, и предоставить пользователю возможность экспортировать данные к себе на десктоп и импортировать от себя в облако.
Ой, мамочки!
Еще один нюанс: данные пользователей важно не перепутать. Файлы с компьютера Васи Пупкина не могут попасть на компьютер Клима Чугункина, а вот в облаке данные пользователей хранятся рядышком. Да, у них разные ID и в базу они складываются со всеми предосторожностями. Но если поисковый запрос не учитывает эти ID и шарит по всей базе, то … ну вы сами понимаете. Вот один наглядный пример из опыта Microsoft.
Это я, почтальон Печкин!
Важный момент: аутентификация пользователей. Сегодня считается моветоном использовать собственную систему аутентификации. А значит, нужно поддерживать OpenID, аккаунты в Google/Facebook и другие наиболее популярные варианты. И таки важно не пропустить шпиЁнов, иначе доверие пользователей может упасть.
Эх, дубинушка, ухнем!
Сервис обретает популярность, количество пользователей растет, нагрузка импульсная: “Сегодня пусто, завтра густо”. Сервис должен уметь масштабировать свои ресурсы: при увеличении нагрузки запрягать свежих виртуальных лошадок (aka workers), а при спаде - давать им отдохнуть. Тут два момента. Во-первых, реакция на резкое увеличение запросов к сервису должна быть оперативной. Современный пользователь избалован: если он ждет в браузере больше 3 секунд, то обратно может не вернуться. Во-вторых, бОльшие мощности означают бОльший счет у провайдера (Windows Azure - наглядный пример). Получается, что нужно выдерживать баланс между удовлетворенностью пользователя и окупаемостью сервиса.
Солдат не спит - служба идет
Да, больше нет пользователей с зоопарком из установленных OS, антивирусов и прочих программ, которые могут препятствовать работе нашего драгоценного продукта. Саппорт перевел дух, но сказка впереди. Теперь пользователи стоят за нашими спинами и дышат в затылок. Нужна эффективная система мониторинга сервиса. Логи логами, но их мегабайты и гигабайты. Они пригодятся при анализе проблемы, но сначала на нее нужно оперативно отреагировать. Сервис недоступен - что делать? Поднять из теплой постели разработчика? Не надо. Откатиться к предыдущей версии? Уже лучше. Установить заглушку на проблемный блок, не лишая пользователей возможности продолжать работать с сервисом? Замечательно. Процедуры управления сервисом должны быть продуманы и отлажены. В случае облачного сервиса, заливка - это такая же важная часть техпроцесса как разработка и тестирование.
Все не так страшно. При переходе от десктопного приложения к облачному нужно учесть много нюансов, но оно того стоит. Рынок облачных приложений развивается, и уже сейчас видны его перспективы. Стремительно растет количество пользователей и расширяется номенклатура устройств с возможностью серфинга в Интернете. Мобильный интернет от сотовых операторов, бесплатные точки доступа в самолетах и поездах, в кафе и развлекательных центрах. Нетбуки, айфоны, айпэды, электронные книжки. Мир быстро меняется, потребности пользователя эволюционируют, но базовые ценности остаются: необходимость оперативно управлять своей информацией с наименьшими усилиями. Есть спрос - будет предложение. До связи, ваш облачный сервис.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Автор комментария : Ольга | April 21, 2011
Спасибо за статью. Рассмотрены основные и важные моменты, достоинства и недостатки. До прочтения статьи я и не задумывалась о том, что рынок всё больше и больше заполняют Интернет-приложения, вытесняя при этом локальные. Ещё одно доказательство того, что мы перешли из эпохи Гутенберга (создателя печатного станка) когда информация только публикуется и преимущественно поглощается, в эпоху Цукерберга (основателя Facebook), когда каждый участник из любой точки планеты может не только поглощать информацию, но и оставить своё мнение, т. е. стать генератором информации. И всё это происходит с невообразимой скоростью.
[Ответить]
Автор комментария : Капитан | May 1, 2011
Ольга, спасибо за ценный комментарий. Да, мир меняется с головокружительной скоростью.
[Ответить]