Развитие некоторых аспектов программного обеспечения, в большинстве случаев, вполне предсказуемо. Один из основных трендов — это постоянное увеличение уровня абстракции.Для наглядности, приведу пример с системами хранения данных. Итак, все началось с файлов. В самом начале мы использовали только файлы, где и хранили все наши данные, и обращались к ним напрямую из программы. Рано или поздно это всем надоело и мы перешли к СУБД. Количество рутинной работы уменьшилось, и мы обращались к серверу БД уже через SQL-запросы.
Но через какое-то время это стало тоже неудобно. Мы захотели иметь возможность переходить от одной СУБД к другой без кардинальных изменений исходного кода.
Мы разработали DAL — абстракцию, где низкоуровневый API для доступа к каждой базе данных разносился по драйверам, которые подключались по мере необходимости. А сам пользователь общался исключительно с высокоуровневыми объектами, получающие запросы и возвращающие результат. Но спустя некоторое время и эта схема перестала давать нам нужную гибкость.
P.S. Пользуясь случаем предлагаю заглянуть в мой личный и полностью некоммерческий блог, посвященный технологиям, психологии, философии и личному опыту: http://v673.com.
Мы начали создавать ORM, где общаться с базой данных уже не обязательно, нужно лишь изменять свойства и параметры определенных объектов, а сохранение их в базу абстракция уже брала на себя.
Появились облачные вычисления. Отличные преимущества, позволяющие отказаться от содержания своих серверов, слежения за работоспособностью, стабильностью штатом сотрудников и бекапом позволили компаниям отдать все заботы на аутсорс, вынося свои базы данных и файлы на облака, тем самым минимизируя затраты.
Возникла проблема: Как не привязываться к конкретной облачной системе, будь-то Amazon EC2 или RHEV-M намертво и, при необходимости, легко менять облачного поставщика? Судя из моего повествования легко можно предсказать появление системы, которая эту абстракцию и будет создавать. И она появилась!
Встречайте! Новый проект DeltaCloud от небезызвестной Red Hat. Он был анонсирован на недавней конференции 2009 Red Hat Summit.
С помощью Deltacloud REST API, при разработке системы, у Вас появляется возможность закладывать необходимую гибкость, возможность сохранять свои решения относительно независимыми и, при необходимости, легко менять облачного провайдера. А Deltacloud Proxy дает возможность разработчикам создавать собственные пользовательские интерфейсы, следить за состоянием аккаунтов, авторизацией пользователей и распределением ресурсов.
На данный момент поддерживается два провайдера:
- Amazon EC2
- Red Hat Enterprise Virtualization Manager (RHEV-M)
Разработчики обещают увеличение списка поддерживаемых провайдеров(конкретно обещают появление поддержки VMWare ESX и RackSpace), а также добавление готовых библиотек, позволяющих избежать непосредственного взаимодействия с REST API. Так, к примеру, уже готова библиотека для Ruby.
Уровнем выше, Deltacloud Portal предоставляет веб-интерфейс, позволяющий просматривать и управлять инстансами, легко перемещать свои данные из одного хранилища в другой, а также вести удобный мониторинг.
К слову, проект полностью свободный и open-source(LGPL, GPL). Задача Deltacloud, по словам разработчиков, защитить ваши проекты от изменений нативного API и условий представления услуг облачными провайдерами. На официальном сайте Deltacloud Вы также можете посмотреть видеоролики, где инженеры Red Hat рассказывают о этой системе.
Красивое решение и красивый подход. Проект, который вполне вероятно окажется востребованным на рынке. Остается пожелать разработчикам удачи, упорства и постоянного совершенствования продукта.
P.S. Друзья, если кому-то интересно это направление — свяжитесь со мной через twitter или другим способом: мне будет интересно пообщаться. Если интересны какие-либо нераскрытые направления в облачных вопросах — говорите, с удовольствием по-изучаю их и напишу об этом статью.
