Насчет морд к EC2 API — согласен. А вот про решения с выбором IaaS в бэк-энде не слышал. Присоединяюсь к mister_fog — хотелось бы подробностей на почитать.
На правах небольшого уточнения. Этого не было в исходной переведенной статье, и почему-то на сайте Deltacloud оно тоже не очень понятно описано. Deltacloud предоставляет три набора API:
1. Собственные API авторства Deltacloud. Они понятны и работают, но придумали их исключительно в рамках самого проекта Deltacloud.
2. CIMI (Cloud Infrastructure Management Interface). Эти API разрабатывает DMTF. Есть надежда, что они станут стандартом. Но работа еще в процессе.
3. Теперь еще появились API Amazon EC2. Так как Amazon часто воспринимается как стандарт де-факто среди публичных облаков, то идея красива. Если есть что-то уже написанное на API EC2, оно сможет через Deltacloud без переписывания работать с другим «облачным бэк-эндом». Осталось проверить, насколько полностью API EC2 реализованы.
То что главные мучения с дисками и сетью — да, согласен. Насчёт костылей, абстракций и низко/высоко-уровневости — всё-таки это зависит от того, какую задачу решаем.
В случае работы с одним наперёд заданным гипервизором libvirt не нужен. Если я планирую KVM-инфраструктуру и точно знаю, что кроме KVM в ней ничего не будет, то плодить лишние обёртки мне ни к чему. В этом случае можно и напрямую с процессами и гипервизором общаться — так правда часто удобнее.
Если же постановка такова, что гипервизоров изначально несколько (случай OpenStack), то всё равно придется как-то извращаться. В этот момент выбор небольшой — или взять libvirt со всеми его плюсами и минусами, или начинать писать свой libvirt. Я как-то третьего пути не вижу. Поэтому вполне понимаю, что люди предпочли свой не писать. Единственное, было бы хорошо, чтобы они при этом понимали все ограничения того, на чём решили основываться. Но в этом гадать бесполезно — время и будущие релизы покажут.
Ну почему же костыль? Дополнительный слой абстракции — да, безусловно. Что слой абстракции не всегда хорошо — тоже факт. Когда мы экспериментировали с динамическим выделением ресурсов машинам на KVM в зависимости от текущего и прогнозируемого потребления, libvirt сознательно не использовали, потому что он в жертву унификации не всё нужное пробрасывает.
Но в случае изначально мультивендорного OpenStack у них особо выбора нет. Поддерживать разные гипервизоры нужно, чтобы обеспечить выполнение заявленного «независимость от поставщика и свобода выбора». В итоге унификация необходима. Её можно делать низкоуровнево (а-ля libvirt) или втаскивать в высокоуровневую логику управлятора, который будет общаться с каждым гипервизором по-своему. Они выбрали libvirt — почему бы и нет, меньше велосипедов в итоге.
1. Собственные API авторства Deltacloud. Они понятны и работают, но придумали их исключительно в рамках самого проекта Deltacloud.
2. CIMI (Cloud Infrastructure Management Interface). Эти API разрабатывает DMTF. Есть надежда, что они станут стандартом. Но работа еще в процессе.
3. Теперь еще появились API Amazon EC2. Так как Amazon часто воспринимается как стандарт де-факто среди публичных облаков, то идея красива. Если есть что-то уже написанное на API EC2, оно сможет через Deltacloud без переписывания работать с другим «облачным бэк-эндом». Осталось проверить, насколько полностью API EC2 реализованы.
В случае работы с одним наперёд заданным гипервизором libvirt не нужен. Если я планирую KVM-инфраструктуру и точно знаю, что кроме KVM в ней ничего не будет, то плодить лишние обёртки мне ни к чему. В этом случае можно и напрямую с процессами и гипервизором общаться — так правда часто удобнее.
Если же постановка такова, что гипервизоров изначально несколько (случай OpenStack), то всё равно придется как-то извращаться. В этот момент выбор небольшой — или взять libvirt со всеми его плюсами и минусами, или начинать писать свой libvirt. Я как-то третьего пути не вижу. Поэтому вполне понимаю, что люди предпочли свой не писать. Единственное, было бы хорошо, чтобы они при этом понимали все ограничения того, на чём решили основываться. Но в этом гадать бесполезно — время и будущие релизы покажут.
Но в случае изначально мультивендорного OpenStack у них особо выбора нет. Поддерживать разные гипервизоры нужно, чтобы обеспечить выполнение заявленного «независимость от поставщика и свобода выбора». В итоге унификация необходима. Её можно делать низкоуровнево (а-ля libvirt) или втаскивать в высокоуровневую логику управлятора, который будет общаться с каждым гипервизором по-своему. Они выбрали libvirt — почему бы и нет, меньше велосипедов в итоге.