Раньше распределенными могли быть только тонкие клиенты на SOA.
C помощью облачных технологий распределенными могут быть и толстые клиенты, так как БД стала таким же ресурсом, как и сервис.

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

Правильно ли понимаю?

Здравствуйте, igor-booch, Вы писали:


IB>Понятно, что удаленный доступ к БД был возможен и раньше,
IB>но облачные технологии обеспечивают делают этот доступ менее трудоемким и более функциональным (безопасность, балансировка нагрузки).
Проблема толстого клиента всегда была в том, что он толстый. Т.е. тянет себе локально большой объем данных. Кроме того, так как база близко, то сходить на нее лишний раз не составляет труда -- как следствие большое количество запросов в базу по делу и нет.
Если теперь базу переместить из локальной сети куда-то там, то появятся тормоза. Нет, конечно, если один из серверов облака находится не далеко, то становится проще, но не сильно.

Тонкий клиент. Тонкий клиент не так "тонок", на самом деле. App-сервер, с которым работает тонкий клиент, сам будет "толстым клиентом" к серверу БД. В том ключе, что база близко и сделать "лишний" или тяжелый запрос не составляет проблем.

Ну и не стоит забывать о толстых клиентах, который при инициализации тянут много данных с сервера, а потом работают автономно, периодчески синхронизируя состояние. Как Janus для RSDN. Для них побарабану где сервер.

СУВ, Aikin

A>Проблема толстого клиента всегда была в том, что он толстый. Т.е. тянет себе локально большой объем данных.
A>Если теперь базу переместить из локальной сети куда-то там, то появятся тормоза.

Тормоза это проблема прошлого. Сейчас тенденция такова, что скорость интернет сетей постоянно растет. Это раз.
Второе облачные технологии для того и существуют, чтобы бороться с этими тормозами за счет распределения вычислений и распределения хранения данных. Раньше сервер БД и сервер приложения должен был находится в локальной сети. Теперь Вы можете купить услугу хостинга БД и серверного ПО у дата центра. Причем не у одного физического дата центра, а у сети дата центров. Ваша БД и серверное ПО будет распределено по физическим дата центрам, таким образом чтобы снизить нагрузку на каналы связи. Но для Вас, то есть Вашего толсто клиента, будет видна одна БД и один сервер приложений. То есть единая логическая точка доступа на множество физических хостов.

Здравствуйте, igor-booch, Вы писали:

A>>Проблема толстого клиента всегда была в том, что он толстый. Т.е. тянет себе локально большой объем данных.
A>>Если теперь базу переместить из локальной сети куда-то там, то появятся тормоза.

IB>Тормоза это проблема прошлого. Сейчас тенденция такова, что скорость интернет сетей постоянно растет. Это раз.
Скорость фигня, тут важна латентность. Скорость света еще никто не отменял.

IB>Второе облачные технологии для того и существуют, чтобы бороться с этими тормозами за счет распределения вычислений и распределения хранения данных. Раньше сервер БД и сервер приложения должен был находится в локальной сети.
Что распределять если у меня строго императивный код, который на 1 открытие формы использует 5-10 запросов к серверу, который находится, дай бог, в той же стране что и я (а скорее всего где-нить в голандии или, супер, в москве)? Если пинг до сервера у нас, скажем 20mc (сравни с <1mc для локалки), то только на то чтобы достучаться к серверу у нас уйдет 5*20-10*20mc=100mc-200mc. А теперь добавь сюда расходы на соединение и передачу данных, будет хз сколько, но не меньше 300mc. Добавь сюда тяжелые запросы, которые мы любим писать. Твои пользователи готовы работать с приложением, которое будет работать на 0,1-0,3 сек медленней, чем если бы оно работало в той же сети? А для чего? Только для того, чтобы руководство отчиталось, что мы используем олачные технологии?

IB>Теперь Вы можете купить услугу хостинга БД и серверного ПО у дата центра. Причем не у одного физического дата центра, а у сети дата центров. Ваша БД и серверное ПО будет распределено по физическим дата центрам, таким образом чтобы снизить нагрузку на каналы связи. Но для Вас, то есть Вашего толсто клиента, будет видна одна БД и один сервер приложений. То есть единая логическая точка доступа на множество физических хостов.
Что это меняет если у ближайший датацентр в 300 километрах от меня?



Тут дело в том, что нужно менять подход к программированию, менять архитектуру толстого клиента, а это уже будет не толстый клиент.


СУВ, Aikin

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

CAP-теорему пока еще никто не отменял, так что "классическая" реляционная БД в облаке не будет маштабироваться бесконечно.

IB>>Тормоза это проблема прошлого. Сейчас тенденция такова, что скорость интернет сетей постоянно растет. Это раз.
A>Скорость фигня, тут важна латентность. Скорость света еще никто не отменял.
Время пинга это такая же техническая проблема. С ростом сети дата центров она решится. Так как чем больше дата центров, тем больше вероятность что рядом с Вами находится один из них. Это вопрос времени.

A>Тут дело в том, что нужно менять подход к программированию, менять архитектуру толстого клиента, а это уже будет не толстый клиент.
Основная идея облачных технологий заключается в том, что код клиента абстрагирован от того где физически находится нужный сервис (БД). Код толстого клиента не зависит от того где находится БД в облаке или локальной сети. Меняется только конфигурация: connection string.

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

A>Что распределять если у меня строго императивный код
Вы наверное имеете ввиду что декларативный код может быть автоматически распараллерен? Да хранилище данных должно быть поддерживать распределенность. Но это дело хранилища данных и облачных технологий, а не кода толстого клиента. Код толстого клиента остается императивным. Программист БД, так же по сути должен быть абстрагирован от распределенности.

А>CAP-теорему пока еще никто не отменял, так что "классическая" реляционная БД в облаке не будет маштабироваться бесконечно.

CAP-теорема: http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP не доказана. Она эвристическая. Поэтому пока до конца непонятно, то ли она описывает фундаментальные ограничения, то ли ограничения обусловленные текущим уровнем развития облачных технологий. Хотя теорема интересная, спасибо.

Здравствуйте, igor-booch, Вы писали:

IB>Кстати, Вы также абстрагированы от масштабов (количества одновременно работающих пользователей (клиентов)). Если у Вас резко увеличивается количество пользователей просто докупите у дата центра машинное время и увеличьте степень распределения хранилища данных.

Это легко только для чтения. А вот как обеспечить нормальную запись при сохранении всех тех же гарантий? Ведь обновление одного и того же объекта могут запросить на разных узлах.

IB>Код толстого клиента остается императивным. Программист БД, так же по сути должен быть абстрагирован от распределенности.
Не получится. Если сохранять все старые гарантии, запись будет тормозить. Либо запись будет вестись только на master node, либо узлы облака будут как-то согласовывать общие блокировки. Оба варианта — потеря скорости по сравнению с одной базой. А если не обеспечивать клоассическую транзакционность, то это будет уже совсем другой подход на клиенте (другая модель операций, необходимость учитывать конкретные варианты потери данных и т.п.).

Здравствуйте, igor-booch, Вы писали:

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

IB>Правильно ли понимаю?
Откуда там безопасность? Если облако "чужое", то ее никогда и не было. А если свое, то безопасность может оказаться сложнее обеспечить, чем для одной базы. Одна база банально закрывается брэндмауэром от внешнего мира, а для облака нужно синхронизацию настраивать.

Да и "балансировка нагрузки" пойдет только на чтение (запись нужно распространять по остальным узлам). Вероятно, при этом еще и задержку на распространение данных придется учитывать. Если я что-то считал, а потом пошел делать update этого с optimistic locking (where version = ...), обновление может обломаться (что ожидаемо). Но после этого я хочу получить последнюю (!) версию данных (или с версией не ниже, чем...). Догадается ли облако сделать это "прозрачно" для меня?

Здравствуйте, igor-booch, Вы писали:

IB>>>Тормоза это проблема прошлого. Сейчас тенденция такова, что скорость интернет сетей постоянно растет. Это раз.
A>>Скорость фигня, тут важна латентность. Скорость света еще никто не отменял.
IB>Время пинга это такая же техническая проблема. С ростом сети дата центров она решится. Так как чем больше дата центров, тем больше вероятность что рядом с Вами находится один из них. Это вопрос времени.
С таким подходом тебе в философию нужно, а не сюда.

СУВ, Aikin

M>Это легко только для чтения. А вот как обеспечить нормальную запись при сохранении всех тех же гарантий? Ведь обновление одного и того же объекта могут запросить на разных узлах.
M>Либо запись будет вестись только на master node, либо узлы облака будут как-то согласовывать общие блокировки.

Да, для записи потребуется координатор распределенных транзакций, то есть некий центральный узел.
Облачная технология рассчитана на ассиметричность чтения\записи. Типичный клиент читает больше чем пишет.
А какая альтернатива? Web и тонкие клиенты? Там все через центральный узел: и чтение и запись.

Здравствуйте, igor-booch, Вы писали:

M>>Это легко только для чтения. А вот как обеспечить нормальную запись при сохранении всех тех же гарантий? Ведь обновление одного и того же объекта могут запросить на разных узлах.
M>>Либо запись будет вестись только на master node, либо узлы облака будут как-то согласовывать общие блокировки.

IB>Да, для записи потребуется координатор распределенных транзакций, то есть некий центральный узел.
IB>Облачная технология рассчитана на ассиметричность чтения\записи. Типичный клиент читает больше чем пишет.
IB>А какая альтернатива? Web и тонкие клиенты? Там все через центральный узел: и чтение и запись.

Для начала нужно определиться, с чем и как ведется работа. Да и с облачными технологиями. Что такое облако? Если я правильно понимаю, "облачные технологии" предполагают два сервиса. Первый — это некий хостинг ресурсов в вакууме где угодно, но только не в вакууме (в вакууме проблемы с охлаждением). Второй — это API доступа к этому хостингу (напоминающий обычный API). И нужно разобраться, какие же проблемы хочется решать путем получения ресурсов в облаке.

1. У нас клиенты работают по всему миру и важна латентность обращения к серверам (ping пресловутый). Облако нам этого в общем случае гарантировать не может. Провайдер будет оптимизировать расположение узлов так, как выгоднее ему. Они могут уехать в антарктиду (дешевое охлаждение) или туда, где интернет дешевый. Но совсем не туда, куда нужно бы для удобства клиентов. Кроме того, латентность может иметь смысл бороть. Ручной выбор хостинга (и настройка клиентов на правильные адреса) лучше.
2. Важна вычислительная мощность на сервере (именно считать!). Да, до тех пор, пока запросы не упираются в тот же балансировщик, например. И только до тех пор, пока важен throughput, а не latency (потому что на тот же вычислительный узел внезапно может приехать много клиентов). Здесь физическое расположение хостинга не важно, API доступа не принципиален.
3. Важна вычислительная мощность (выборка данных). Разница только в том, насколько клиент знает о различии между операциями чтения и записи. Если операции "только чтение" и "возможна запись" различимы, то технологии есть (с различным уровнем гарантии). Любая реплиация это гарантирует. Точно есть в Oracle. Есть в нескольких видах в postgresql. Автоматическое руление запросами для постгреса умеет pgpool. В этом случае запросы на запись пойдут на одну базу. Запросы на чтение — на любую базу. При синхронной репликации даже задержек заметных не будет. Здесь API доступа к данным важен. Могут быть важны и особенности хостинга, так что облако плохо подходит.
4. Важно дисковое хранилище. Опять зависит от того, нужно ли нам throughput (и неважно, где и как) или latency (тогда важно, где, и как выполняется доступ)

В общем, все упирается в то, что в первую очередь нужно от хостинга и что мы готовы сделать с приложением. Ну и банально все упирается в деньги. В облаке может быть удобнее хостить приложения с низкой нагрузкой, с высокой вычислительной нагрузкой, с высокими требованиями к хранению. В общем, либо совсем некритичные задачи, либо задачи ориентированные на throughput (вычисления или хранения, "больше", но не "быстрее"). Провайдер облака ведь тоже будет оптимизировать свои издержки, так что без минусов не обойдется. Оптимизации быстродействия имеет смысл рулить вручную. По тем же базам нанять кого-нибудь для балансировки нагрузки, и получите почти облако. Географически распределенную сеть построить. И т.п.

Кстати, не вижу проблем с тонким клиентом. Ни с "читать", ни с "писать". Для клиента, который знает о распределенности, вообще никаких проблем нет (уровень обмена данными достаточно низок и если мы различаем запросы, мы можем их рулить по разным серверам). Который не знает можно порулить round-robin'ом и несколькими записями в DNS. Или redirect на нужный адрес по IP клиента делать. А за фронтендом можно свое "облако" поднимать. Ну будет к базе ходить 5 узлов вместо одного. На тех (веб)-узлах тоже все способы балансировки можно применять. И локальные реплики базы делать, и в сервере данные кэшировать (кстати, дополнительный уровень для повышения производительности при доступе к данным!)

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

M>И нужно разобраться, какие же проблемы хочется решать путем получения ресурсов в облаке.

Я уже написал в исходном сообщении какие проблемы решают облака. Если Вы не согласны с этого нужно было и начинать.
Построюсь. Сейчас информационные системы уровня предприятия выходят за рамки локальной сети здания. Бизнес становится распределенным, интеграция информационных систем повышается. Раньше единственным средством создания распределенных клиентов был Web. Но Web разработка (тонкий клиент) дороже, чем для настольных приложений (толстый клиент). Если сравнить стоимость двух приложений с одинаковым набором возможностей, но отличающих только тем, что одно Web, а другое настольное приложение, то дороже будет Web. Облачные технологии позволяют сделать распределенными толстые клиенты. Да, это удешевлении при увеличении набора возможностей. Но в этом и заключается развитие технологий.
Про остальное либо уже писал, либо не понял.

Здравствуйте, igor-booch, Вы писали:

M>>И нужно разобраться, какие же проблемы хочется решать путем получения ресурсов в облаке.

IB>Я уже написал в исходном сообщении какие проблемы решают облака. Если Вы не согласны с этого нужно было и начинать.
IB>Построюсь. Сейчас информационные системы уровня предприятия выходят за рамки локальной сети здания. Бизнес становится распределенным, интеграция информационных систем повышается.
И "клиент" в этой интеграции — капля в море. Основная интеграция информационных систем выполняется на уровне "система-система". А там web services/soap/rest/rpc/etc... Это, конечно, тоже "веб", но ни к тонким, ни к толстым клиентам отношения не имеет. Девушка, сидящая в "банк-клинете" и сверяющая там проводки, все-таки не элемент интеграции предприятия с банком.

А "веб" сейчас часто используется по вполне прагматичным причинам. Веб-сервер обеспечивает дополнительный уровень проверок доступа (привелегий и т.п.). Отдать наружу логин с паролем к базе предприятия — это странное решение. Можно (и нужно все равно) рулить полномочиями в базе и т.п., но дополнительный уровень делает этот момент проще (хотя добавляет свои уязвимости). Толстые клиенты были в локальной сети тоже по соображениям безопасности (хоть там и пароль с открытым текстом, снаружи в базу никто не залезет и изучать не будет).

IB>Раньше единственным средством создания распределенных клиентов был Web.
Давайте определимся, что такое "распределенный клиент". Это много клиентов по всему миру? Ну да, это делалось (и будет делаться) через дополнительную прослойку между клиентом и базой. А со стороны "распределенного клиента" облака вообще не видно. Какая разница, что там за url-ом — облако или внешний адрес базы данных предприятия. А еще "распределенные клиенты" впервые были изобретены очень и очень давно. Были это "толстые приложения" и назывались "банк-клиент". Если мне не изменяет память, они дозванивалиь (да, по телефону через модем!) до банка и проводили нужные операции. И только гораздо позже появились "клиенты в браузере".

IB>Но Web разработка (тонкий клиент) дороже, чем для настольных приложений (толстый клиент). Если сравнить стоимость двух приложений с одинаковым набором возможностей, но отличающих только тем, что одно Web, а другое настольное приложение, то дороже будет Web.
А обосновать? С моей личной точки зрения, как раз веб-разработка дешевле. В браузере очень хорошие механизмы layout'ов. Подобное реализовывать в "толстом клиенте" не удобно. Ну да, можно взять какой-нибудь html-движок. И разницы между "страница в браузере" и "страница в толстом клиенте" уже не будет.

В толстых клиентах можно выполнять какие-то дополнительные операции врдое кэширования. Но, опять же, нужно изучать конкретные примеры. Может оказаться выгоднее держать "веб-сервер" с одним общим кэшем на всех, чем выдавать каждому клиенту его порцию данных, которые он потом закэширует.

Хотя есть одно неосопоримое преимущество у толстых клиентов по сравнению с веб. Это интеграция с инфраструктурой предприятия (active directory, outlook, прочие сервисы). Но в этом случае приложению, рассчитаному на работу в домене, облако никак не поможет.

IB>Да, это удешевлении при увеличении набора возможностей. Но в этом и заключается развитие технологий.
А вот с этим я не согласен. И лично я этого нигде не утверждал. Удешевление есть. Но там не "увеличение набора возможностей", а "другой баланс приоритетов в платформе" скорее всего. Т.е. что-то получаем, а что-то теряем. Другой набор компроммисов. В общем, в некоторых случаях может быть оправдано. Но это обычно ортогонально толщине клиента, который работает с данными.

Здравствуйте, igor-booch, Вы писали:

A>>Тут дело в том, что нужно менять подход к программированию, менять архитектуру толстого клиента, а это уже будет не толстый клиент.
IB>Основная идея облачных технологий заключается в том, что код клиента абстрагирован от того где физически находится нужный сервис (БД). Код толстого клиента не зависит от того где находится БД в облаке или локальной сети. Меняется только конфигурация: connection string.

Нет, вы путаете. Такое абстрагирование делается относительно легко, и точно так же connection string меняется на "внешний адрес базы" вместо "внутреннего. Ну и к облакам оно отношения не имеет.

Идея у облаков другая. Состоит она в том, что вы можете покупать ресурсы более "гранулировано", чем раньше. Вот раньше можно было у хостера купить "хостинг на одной машине". Был фиксирован объем хранилища, выделяемая память, выделяемая машинная память и т.п. Использовали вы эту мощность или нет — цена от этого не зависела. Примерно то же самое, что вы подключаетесь к электричеству и платите только за подведенную мощность. Есть у вас 10Квт гарантированные, за них и платите. Не важно, не делали вы ничего, или постоянно жгли электричество на полную мощность. А в облаке основная схема оплаты другая. Облако обычно предполагает оплату "по счетчику". Использовали 1 гигатакт процесора, за него и платите. Использовали 3,6 мегаджоулей электричества — и платите только за них. Или просто гораздо лучшая гранулярность (для диска) и какой-то суммарный учет (по вычислительной мощности).

Очевидно, что архитектуры облаков имеет некоторые ограничения. Например, это может быть более низкая скорость отклика на изменение загрузки (т.е. пока вас с загруженного хоста куда-нибудь на посвободнее мигрируют). Так что если нам важна для ряда задач гарантированное время отклика, придется искать облако с соответствующим сервисом. Ну и просто под конец месяца у всего облака может не оказаться достаточно ресурсов (все бросились месячные отчеты считать). Требования к безопасности — вообще отдельная песня.

Так что к "виду" клиента это отношения не имеет. Облако можно использовать и на серверах, обслуживающих веб. И в отдельных клиентах (легких и толстых). Технически это все делается обычно легко — просто меняются настройки. Точно так же, как при реогранизации сети внутри предприятия. Разница в первую очередь в оплате ресурсов, а потом уже в технических моментах. И "легче" в технических моментах не будет, будет просто "по-другому"

Здравствуйте, igor-booch, Вы писали:

IB>CAP-теорема: не доказана.

Доказана. Правда, в несколько отличной от первоначальной фомулировке.
В таких вопросах русской вики доверия почти нет, нужно сразу смотреть английскую.

Здравствуйте, igor-booch, Вы писали:

IB>Время пинга это такая же техническая проблема. С ростом сети дата центров она решится. Так как чем больше дата центров, тем больше вероятность что рядом с Вами находится один из них. Это вопрос времени.

Пришли мыши к сове и спрашивают, как им от котов спастись. Сова говорит: "Станьте ежиками." Мыши радуются, празднуют, потом подумали, возвращаются к сове и спрашивают: "Сова, а как же нам ежиками стать, мы же мыши?" А Сова им: "Мое дело — стратегия!".

M>И "клиент" в этой интеграции — капля в море. Основная интеграция информационных систем выполняется на уровне "система-система". Девушка, сидящая в "банк-клинете" и сверяющая там проводки, все-таки не элемент интеграции предприятия с банком.
Ну так при интеграции двух систем одна из них может выступать в роли сервера, другая в роли клиента. Причем клиент в этом случае (при использовании облачных технологий) может быть толстым и распределенным. Если каждая из систем будет выступать и в роли клиента и роли сервера, получите двунаправленное взаимодействие.

M>А там web services/soap/rest/rpc/etc... Это, конечно, тоже "веб", но ни к тонким, ни к толстым клиентам отношения не имеет.
Сейчас да, а я говорю про перспективу и тенденцию развития технологий.

M>А "веб" сейчас часто используется по вполне прагматичным причинам. Веб-сервер обеспечивает дополнительный уровень проверок доступа (привелегий и т.п.). Отдать наружу логин с паролем к базе предприятия — это странное решение. Можно (и нужно все равно) рулить полномочиями в базе и т.п., но дополнительный уровень делает этот момент проще (хотя добавляет свои уязвимости).
Как это проще? Вы создаете дополнительный слой. На это требуются дополнительные трудозатраты: и капитальные и эксплуатационные. По моим наблюдениям в 80% проектов возможности конфигурирования безопасности БД используются лишь на 20%. Почему бы не использовать средства обеспечения безопасности БД на 100%? Зачем усложнять, если технологии позволяют обойтись без дополнительного слоя? Средства обеспечения безопасности БД постоянно совершенствуются, не зря же в это вкладывают деньги.

IB>>Раньше единственным средством создания распределенных клиентов был Web.
M>Давайте определимся, что такое "распределенный клиент". Это много клиентов по всему миру? Ну да, это делалось (и будет делаться) через дополнительную прослойку между клиентом и базой.
А как же технический прогресс? Или Вы считаете, что существующие технологии и архитектуры это вершина эволюции и лучше уже не будет?

M>А обосновать? С моей личной точки зрения, как раз веб-разработка дешевле.
В web много кода пишется для обеспечения взаимодействия между клиентом (javascript) и сервером. В web вы вынуждены тратить время на создание и поддержку дополнительного слоя между клиентом и БД. Уточню что, чем богаче пользовательский интерфейс, чем дороже будет web по сравнению с толстым клиентом. http://ru.wikipedia.org/wiki/Rich_Internet_Application#.D0.9D.D0.B5.D0.B4.D0.BE.D1.81.D1.82.D0.B0.D1.82.D0.BA.D0.B8

M>В браузере очень хорошие механизмы layout'ов. Подобное реализовывать в "толстом клиенте" не удобно.
WPF, JavaFX

M>В толстых клиентах можно выполнять какие-то дополнительные операции врдое кэширования. Но, опять же, нужно изучать конкретные примеры. Может оказаться выгоднее держать "веб-сервер" с одним общим кэшем на всех, чем выдавать каждому клиенту его порцию данных, которые он потом закэширует.
Кэширование на клиенте было невыгодно, когда когда была дорогая память и вообще дорогое железо. Сейчас тенденция такова, что память дешевеет, быстродействие растет, а это делает резонным утолщение клиентов. Web был выгоден когда было дорогое железо. Сейчас Web не может на 100% использовать появившееся возможности увеличения быстродействия клиентов и многопоточность. А бизнес требует все более и более навороченный и в тоже время отзывчивый пользовательский интерфейс.

M>Нет, вы путаете. Такое абстрагирование делается относительно легко, и точно так же connection string меняется на "внешний адрес базы" вместо "внутреннего. Ну и к облакам оно отношения не имеет.

Я же писал уже, в случае облачных технологий connection string не к одной удаленной БД, а распределенному хранилищу.

IB>Ваша БД и серверное ПО будет распределено по физическим дата центрам, таким образом чтобы снизить нагрузку на каналы связи. Но для Вас, то есть Вашего толсто клиента, будет видна одна БД и один сервер приложений. То есть единая логическая точка доступа на множество физических хостов.

Про остальное тоже писал.

Здравствуйте, igor-booch, Вы писали:

M>>Нет, вы путаете. Такое абстрагирование делается относительно легко, и точно так же connection string меняется на "внешний адрес базы" вместо "внутреннего. Ну и к облакам оно отношения не имеет.

IB>Я же писал уже, в случае облачных технологий connection string не к одной удаленной БД, а распределенному хранилищу.
Как это реализзовано, можно поинтересоваться? Свой собственный протокол или все же стандартное TCP/IP?

СУВ, Aikin