Прежде всего, это будет новый подход к наполнению контентом, это будет четкость и однозначность, реальная поддержка клиентов, гео-кластеризация и аптайм близкий к 100%, и как следствие - повышенная защита от DDOS атак.

Концепт WEB 2.0 заключен в том, что пользователи сайта сами формируют его контент, а наиболее логично и просто делать это прямо из браузера. FTP портокол шагнет в прошлое, а все манипуляции по загрузке информации будут происходить в окне браузра. Все изменения как в содержимом так и во внешнем представлении сайта уже можно изменять визуально, а HTML 5 даст этому еще больше возможностей.

Обычный хостинг предоставляет клиентам технологии, без каких-либо гарантий. Не факт, что выбранная CMS будет работать, потому что несмотря на то, что стандарты технологий общеприняты, многие хостинг провайдеры производят ряд модификаций, связанных прежде всего с настройкой безопасности.
Поколение хостинга WEB 2.0 будет предоставлять клиентам сервисы. Наиболее популярные CMS, движки форумов, блогов и т.д. будут модифицированы под хостинг следующего поколения и предоставлять клиентам уже готовый предустановленный сервис, настройки которого могут быть изменены через браузер.

На хостинге WEB 2.0 небудет списка технологий, а будет список сервисов, которые четко и однозначно будут работать. Вопроса о том, пойдет или нет самописный скрипт - больше не возникнет. На него однозначный ответ будет - нет. Вопрос будет иным - а есть ли среди списка сервисов именно тот, который нужен клиенту?
Техподдержки как таковой, в том виде, в котором мы ее сейчас воспринимаем - больше небудет. Частично это связано с тем, что ортодоксальный хостинг, в котором для выполнения типичных задач требовались специальные знания и навыки - уйдет в прошлое и уступит хостингу следующего поколения место. Хороший пример - почтовый сервис от google.com - gmail. Он предоставляет такую надежность и комфорт, какой не могут дать устаревшие хостинг-провайдеры.

Конечно, может возникнуть вопрос, а откуда именно возьмут новые хостинг-провайдеры эти самые сервисы и зачем их модифицировать, если сейчас все работает как есть без разного рода модификаций? Ответ напрашивается сам собой - новые хостинг-провайдеры будут как минимум сотрудничать с авторами популярных CMS, и выпускать SDK комплекты для адаптаций CMS в свой репозитарий. Возможно что некоторые будут писать свои собственные сервисы или модифицировать различные движки с открытым исходным кодом.
Модификация нужна для переноса классических скриптов под платформу геораспределенного хостинга с повышенной отказоустойчивостью. Что же он будет собой представлять? Наиболее дешевым и практичным представляется следующая система:

1. Разделение системных и пользовательских данных
2. Система синхронизации системных данных
3. Система репликации пользовательских данных

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

Выделив системные файлы, их можно легко синхронизировать на сервера, распределенные по разным странам, например через классический rsync.
Еще один плюс подобной системы - любая модификация, обновление или исправление уязвимости - отражается сразу на всех клиентах, так как они используют ядро CMS, существующее в едином экземпляре.
Пользовательские данные логичнее всего хранить не в классической файловой системе, а в распределенной файловой системе, где нет работы с файлами а существует работа с объектами. Такой подход даст не только повышенную надежность, но и распределение нагрузки на все сервера.
А для надежности хранения БД и снижения нагрузки будет применятся привычная MySQL в режиме master-slave, где в все запросы на модификацию будут направлены на master сервер, а запросы на выборку - выполнятся на множестве slave-серверов.

Попробуем представить себе типичный сервер хостинга WEB 2.0:

* На переднем плане - nginx, отдающий статический контент
* За ним - apache, ставший уже классикой
* Для выполнения скриптов - fastcgi php
* MySQL сервер, который работает в режиме slave, но готов в любой момент стать master
* На разделе диска, размеченного под классической ФС хранится репозиторий сервисов
* В любой момент он может быть изменен и синхронизирован с остальными серверами через rsync
* Демон коммуникации между остальными серверами WEB 2.0
* Распределенная отказоустойчивая файловая система занимает оставшуюся часть диска

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

В настоящий момент, распределенной файловой системы с открытым исходным кодом, которая полностью подходит для системы хостинга WEB 2.0 к сожалению нет. Наиболее близкой является Hadoop HDFS, узким местом которого является Namenode.