Зачем Володька сбрил усы?
Наконец-то добрый дядя из Microsoft объяснил мне, почему они переименовали SQL Server Data Services (SSDS) в SQL Data Services (SDS). Не просто потому, что людям трудно выговаривать эти четыре слова. Дело в том, что SDS мало чем связано с SQL Server. Да и вообще с SQL. На месте Microsoft я бы просто назвал этот продукт Data Services :)
Я раньше думал, что идея такая - ты просто используешь SQL Server, который хостится не у тебя, а в Microsoft. Нет, все совсем не так. Оказывается, SDS - это нереляционная база, в которой практически нет такого понятия как схема. У экземпляров одной и той же сущности может быть разный набор атрибутов. А так же нет индексов и хранимых процедур. И все это действительно хостится "в облаке" у Microsoft. Язык запросов больше похож на Linq, чем на SQL.
Наверное, это нечто похожее на гуглевскую BigTable или амазоновскую S3. Важно понимать, что SDS - это не продукт, а сервис. Его нельзя взять и поставить себе на компьютер. Сколько будет стоить этот сервис, и как Microsoft будет расчитывать оплату (по килобайтам, по сложности запросов и пр.), пока неясно.
Докладчик нам рассказывал, как все классно, что добрая Microsoft возьмет на себя все проблемы с дата-центрами. Не нужно будет самостоятельно заботиться о патчах, резервном копировании, охране, пожарной безопасности, охлаждении, электричестве. Не нужно бежать и срочно покупать новые сервера, если резко выросла нагрузка - достаточно просто заплатить за ресурсы. И не надо продавать лишние, если нагрузка упала. Все это понятно, все это замечательно. Но я сразу же задал простой вопрос:
- Если нет ни хранимых процедур, ни индексов, как же мы будем реализовывать сложную бизнес-логику на стороне сервера?
- Ээ..уу..ну, надо будет закачать все в приложение и там обработать.
Ха! А если у меня в базе миллион записей? Или миллиард? Это несерьезно. Я думаю, что еще лет 15 реляционным базам данных точно ничего не угрожает. Сначала нужно или повысить пропускную способность Интернет в тысячи раз, или придумать для SDS что-то похожее на хранимые процедуры и индексы.
Еще нам показали о том, как хостить workflow "в облаке". Да, тоже идея замечательная, но функциональность пока сильно урезана по сравнению с теМ, что можно делать в нормальной WWF.
Задали вопрос, какие средства Microsoft дает для мониторинга. Докладчик опять замялся.
Я хотел было ответить за него в таком ключе: "Мы сравниваем вычислительные услуги с коммунальными услугами. Вы же не жалуетесь, что у Вас нет возможности посмотреть, на какой электростанции произведено Ваше электричество? Или из какой реки поступает вода в Ваш кран? Или через какие АТС идет Ваш телефонный звонок? Если говорить об электричестве, то все, что у нас есть - это напряжение в сети и счетчик потребленного электричества".
Но я промолчал. Ведь по определению коммунальная услуга (utility) - это нечто однородное, легко поддающееся изменению. Канализация просто куда-то утекает. Мусор просто куда-то вывозят (правда, в определенные дни и время). Но в принципе нам все равно, куда. Вода просто откуда-то течет с определенным напором (правда, у воды может быть разная степень очистки).
Но корректно ли вообще сравнивать программное обеспечение с канализацией? Не уверен. Это же не просто поток байтов, которые надо быстро куда-то передавать, все гораздо сложнее и неоднозначнее.
Еще нам немного рассказали про Dublin, я первый раз про него услышал. Это кодовое имя будущего .NET application server. В чем-то он похож на BizTalk, но другие приритеты: простой, быстрый, не очень гибкий и не очень надежный. В двух словах, идея такая: BizTalk - для интеграции приложений, Dublin - для разработки.
Комментариев нет:
Отправить комментарий