Автор: Илья Стечкин
Про чудовище доктора Франкенштейна, который возжелал даровать жизнь мертвой материи, слышали многие. Как вы помните, кончилось все печально — гибелью ученого и его близких. Да и самого чудовища. Пусть эта история послужит предостережением разработчикам, которые пытаются отобрать жизнь у OpenStack’а, создающим проекты без учета логики развития экосистемы.
Сегодня уже никто не сомневается в том, что облака нужны не только идеалистам-романтикам, но и бизнесменам. Коммунальные вычисления — умное название облачных технологий — пригодятся тем, кто предоставляет банковские услуги, занимается логистикой, лечит больных, торгует, разрабатывает программные продукты, анализирует большие массивы данных, организует мероприятия… Даже те, кто пишет тексты или постит котиков в социальных сетях — используют облака, хотя и не подозревают об этом.
Но облако — это, в первую очередь, архитектура хранения и обработки данных. Принципиально важно понимать, что облако предполагает переход с физических серверов на виртуальные машины. Иными словами вы получаете возможность более эффективно использовать существующую инфраструктуру, парк имеющегося оборудования; оперируете логическими узлами, а не физическими серверами. И соорудить такую конструкцию можете в своем собственном ЦОДе. Тогда данные не будут покидать компанию, безопасность будет ровно на том уровне, которую вы сами в состоянии обеспечить, но при этом все преимущества облака будут в вашем распоряжении. Это называется частным (или приватным) облаком.
Существуют сценарии, при которых критически важные данные хранятся в частном облаке, а приложения, использующие эти данные, существуют в публичном облаке. Например, у вас есть данные по стоимости вашей продукции, включающие в себя сведения о принципах ценообразования. Очевидно, эти сведения составляют коммерческую тайну. Но изменения цены объектов продажи должны отражаться в онлайн-каталоге. В этом случае сам каталог, представляющий собой перечень продуктов и поля для отображения цены, а также формы онлайн-заказа могут существовать в открытом облаке, так как эта информация не является секретной. Изменения цены могут автоматически переноситься из частного облака в публичное. И, наоборот, заполненные формы заказов могут автоматически переправляться из публичного облака в частное, чтобы обеспечить лучшую защиту персональных данных клиентов. Такой “симбиоз” приватного и публичного облаков называется “гибридным облаком”.
Для построения частных и гибридных облаков существуют как открытые, так и проприетарные решения. Однако проблема последних в том, что они, в большинстве случаев, разработаны компаниями, которые могут стать заложниками “санкционной войны”. Другими словами нет никаких гарантий, что очередной виток санкций не закроет компаниям-клиентам доступ к обновлениям и службам поддержки поставщиков облачных решений. Вероятно поэтому все больше внимания уделяется открытым облачным платформам, среди которых очевидным лидером является OpenStack.
Можно понять энтузиастов из регионов, которые пытаются “оседлать волну” и предложить свои услуги по созданию облака тем или иным крупным компаниям. Это их шанс прорваться на большой рынок. Сложнее понять именитые ИТ-компании, предлагающие такие же поделки-однодневки, заслужившие прозвище “франкенстеки”. Клиент оказывается введенным в заблуждение и в расходы. Это вредит как имиджу компаний, так и концепции открытого кода. Ведь основным преимуществом открытого кода для пользователей является возможность сэкономить на разработке и внедрении решения, а для разработчиков — возможность совместными усилиями сократить сроки и себестоимость создания продукта. Именно такое “коллективное творчество” позволяет предлагать качественный продукт, способный конкурировать с решениями крупных вендоров за меньшие деньги.
В романе Мэри Шелли ученый Виктор Франкенштейн создает живое из неживого. В нашем случае все происходит наоборот. Создатели “франкенстеков” превращают живой продукт, который может развиваться и расти — в зомби. Такие проекты после “рождения” обречены оставаться на одном и том же уровне развития, в то время как вся экосистема OpenStack эволюционирует каждые полгода — в соответствии с релиз-циклом.
Разработчики “франкенстеков” из всего функционала OpenStack оставляют только тот, который нужен заказчику в настоящий момент. Представьте себе кубик Рубика, который крутится только в одну сторону и только одной гранью. Нелепый артефакт получается, не правда ли?
Когда клиент формулирует разработчикам ТЗ, он заботится о решении задач, которые стоят перед ним здесь и сейчас, это нормально. Ненормально, когда разработчики упускают из вида дальнейшую эволюцию экосистемы, продуктом жизнедеятельности которой они пользуются, решая текущую задачу клиента.
Между тем, как уже было сказано, раз в полгода OpenStack меняется, появляются новые функции, правятся старые баги, открываются возможности, которых не было в предыдущих версиях продукта. И, наоборот, некоторые возможности перестают поддерживаться. Это означает, что через шесть месяцев клиент может оказаться у разбитого корыта.
На создание “облака” заказчик тратит существенные средства. Если продукт сделан с учетом особенностей экосистемы, то поддерживать его сможет любая компания, специализирующаяся на OpenStack. А поддержка любому программному продукту требуется: как минимум речь идет о своевременной установке апгрейдов, секьюрити апдейтов, обучении сотрудников заказчика работе с продуктом… “Франкенстек” полностью зависит от своего создателя. Он исключен из процесса эволюции экосистемы, так что для внедрения новых “фишек” из очередного релиза потребуется инвестировать столько же денег, сколько в первоначальную инсталляцию.
Однажды несколько активных контрибуторов OpenStack создали компанию Piston. Они решили, что смогут обогнать сообщество разработчиков и сделать на основе “ванильного” OpenStack проприетарный коммерческий продукт. Они понимали как функционирует сообщество и сделали осознанный выбор. Эксперимент дал отрицательные результаты, предоставив сообществу возможность убедиться в том, что самостоятельное “допиливание”, без учета интересов большинства участников процесса разработки, ведет к нежелательным последствиям. Компания Piston оказалась на грани банкротства и была приобретена ИТ-гигантом Cisco, “фракенстек” погубил своего создателя.
К сожалению, многие российские разработчики проигнорировали опыт заокеанских коллег. И продолжают заниматься самодеятельностью, последовательно превращая живой продукт в мертвую сущность, паразитирующую на бюджетах заказчика.
Между тем, заказчик, скорее всего, не одинок в поисках решений тех или иных задач. А значит, продукты, разработанные для клиента, могут стать частью экосистемы OpenStack. А значит будут поддерживаться и совершенствоваться всем сообществом. Есть, правда, нюанс: для этого компания-разработчик должна обладать весом в сообществе, чтобы заинтересовать проектом других игроков. От команды, состоящей из 100 инженеров, не стоит ожидать разносторонней экспертизы, поддержки всех компонентов экосистемы, возможности заниматься внедрением продукта, обучением сотрудников клиентов, поддержкой как предыдущих, так и текущей версий OpenStack.
Впрочем, сотня инженеров вполне может справиться с внедрением решения, разработанного кем-то из “локомотивов” сообщества. Определить состав “паровозного депо” просто. Достаточно открыть сервис Stackalytics.
Еще раз напомним, что клиенту, по факту внедрения решения на базе OpenStack, равно как и любого проприетарного решения, потребуется поддержка. Например, может возникнуть потребность в переходе на новые версии продукта. Желательно, чтобы этот процесс проходил безболезненно и без дополнительных затрат.
Простой пример: вы сделали драйвер для какого-то проприетарного стораджа. Проходит полгода, наступает время обновления системы, администраторы производят апгрейд системы, и тут выясняется, что драйвер-то не работает… А за сторадж были заплачены серьезные деньги. Причина в том, что в ядре системы произошли изменения, но про драйвер никто не подумал. Потому что о его существовании сообщество не имело информации, он был сделан “на коленке” в процессе “допиливания” той версии дистрибутива, которая была актуальна на момент сдачи проекта. А ведь вы, наверняка, не единственный клиент производителя этого стораджа. И еще стопятьсот компаний были бы рады иметь такой драйвер, да еще и в рабочем состоянии. И если бы его делали всем миром, то, во-первых, для каждой из заинтересованных компаний он вышел бы существенно дешевле, а во-вторых, сообщество позаботилось бы о том, чтобы изготовить соответствующий CI и проверить его на любую сборку: эта схема реально работает, что легко наблюдать все в том же Stackalytics в разделе Vendor Drivers.
Подведем итог: среднестатистическому пользователю OpenStack нужен представитель в сообществе. Компания, которая осуществляет внедрение, благодаря партнерским отношениям с “локомотивом”, может представлять интересы своего клиента. Таким образом, если разработчик адекватно оценивает свои силы и заботиться не только о сиюминутной выгоде, но и о благе своего клиента, он приносит пользу всему сообществу. И наоборот: если он заботится о благе сообщества, то, неизбежно принесет пользу клиенту, облегчив его жизнь в будущем. Этим и отличается живой и развивающийся OpenStack от мертвого, холодного и жадного до клиентских денег “франкенстека”.
Про чудовище доктора Франкенштейна, который возжелал даровать жизнь мертвой материи, слышали многие. Как вы помните, кончилось все печально — гибелью ученого и его близких. Да и самого чудовища. Пусть эта история послужит предостережением разработчикам, которые пытаются отобрать жизнь у OpenStack’а, создающим проекты без учета логики развития экосистемы.
“Спасибо, Кэп!” или Несколько банальностей про облака
Сегодня уже никто не сомневается в том, что облака нужны не только идеалистам-романтикам, но и бизнесменам. Коммунальные вычисления — умное название облачных технологий — пригодятся тем, кто предоставляет банковские услуги, занимается логистикой, лечит больных, торгует, разрабатывает программные продукты, анализирует большие массивы данных, организует мероприятия… Даже те, кто пишет тексты или постит котиков в социальных сетях — используют облака, хотя и не подозревают об этом.
Но облако — это, в первую очередь, архитектура хранения и обработки данных. Принципиально важно понимать, что облако предполагает переход с физических серверов на виртуальные машины. Иными словами вы получаете возможность более эффективно использовать существующую инфраструктуру, парк имеющегося оборудования; оперируете логическими узлами, а не физическими серверами. И соорудить такую конструкцию можете в своем собственном ЦОДе. Тогда данные не будут покидать компанию, безопасность будет ровно на том уровне, которую вы сами в состоянии обеспечить, но при этом все преимущества облака будут в вашем распоряжении. Это называется частным (или приватным) облаком.
Существуют сценарии, при которых критически важные данные хранятся в частном облаке, а приложения, использующие эти данные, существуют в публичном облаке. Например, у вас есть данные по стоимости вашей продукции, включающие в себя сведения о принципах ценообразования. Очевидно, эти сведения составляют коммерческую тайну. Но изменения цены объектов продажи должны отражаться в онлайн-каталоге. В этом случае сам каталог, представляющий собой перечень продуктов и поля для отображения цены, а также формы онлайн-заказа могут существовать в открытом облаке, так как эта информация не является секретной. Изменения цены могут автоматически переноситься из частного облака в публичное. И, наоборот, заполненные формы заказов могут автоматически переправляться из публичного облака в частное, чтобы обеспечить лучшую защиту персональных данных клиентов. Такой “симбиоз” приватного и публичного облаков называется “гибридным облаком”.
Для построения частных и гибридных облаков существуют как открытые, так и проприетарные решения. Однако проблема последних в том, что они, в большинстве случаев, разработаны компаниями, которые могут стать заложниками “санкционной войны”. Другими словами нет никаких гарантий, что очередной виток санкций не закроет компаниям-клиентам доступ к обновлениям и службам поддержки поставщиков облачных решений. Вероятно поэтому все больше внимания уделяется открытым облачным платформам, среди которых очевидным лидером является OpenStack.
Можно понять энтузиастов из регионов, которые пытаются “оседлать волну” и предложить свои услуги по созданию облака тем или иным крупным компаниям. Это их шанс прорваться на большой рынок. Сложнее понять именитые ИТ-компании, предлагающие такие же поделки-однодневки, заслужившие прозвище “франкенстеки”. Клиент оказывается введенным в заблуждение и в расходы. Это вредит как имиджу компаний, так и концепции открытого кода. Ведь основным преимуществом открытого кода для пользователей является возможность сэкономить на разработке и внедрении решения, а для разработчиков — возможность совместными усилиями сократить сроки и себестоимость создания продукта. Именно такое “коллективное творчество” позволяет предлагать качественный продукт, способный конкурировать с решениями крупных вендоров за меньшие деньги.
Что такое “Франкенстек” и чем он опасен
В романе Мэри Шелли ученый Виктор Франкенштейн создает живое из неживого. В нашем случае все происходит наоборот. Создатели “франкенстеков” превращают живой продукт, который может развиваться и расти — в зомби. Такие проекты после “рождения” обречены оставаться на одном и том же уровне развития, в то время как вся экосистема OpenStack эволюционирует каждые полгода — в соответствии с релиз-циклом.
Разработчики “франкенстеков” из всего функционала OpenStack оставляют только тот, который нужен заказчику в настоящий момент. Представьте себе кубик Рубика, который крутится только в одну сторону и только одной гранью. Нелепый артефакт получается, не правда ли?
Когда клиент формулирует разработчикам ТЗ, он заботится о решении задач, которые стоят перед ним здесь и сейчас, это нормально. Ненормально, когда разработчики упускают из вида дальнейшую эволюцию экосистемы, продуктом жизнедеятельности которой они пользуются, решая текущую задачу клиента.
Между тем, как уже было сказано, раз в полгода OpenStack меняется, появляются новые функции, правятся старые баги, открываются возможности, которых не было в предыдущих версиях продукта. И, наоборот, некоторые возможности перестают поддерживаться. Это означает, что через шесть месяцев клиент может оказаться у разбитого корыта.
На создание “облака” заказчик тратит существенные средства. Если продукт сделан с учетом особенностей экосистемы, то поддерживать его сможет любая компания, специализирующаяся на OpenStack. А поддержка любому программному продукту требуется: как минимум речь идет о своевременной установке апгрейдов, секьюрити апдейтов, обучении сотрудников заказчика работе с продуктом… “Франкенстек” полностью зависит от своего создателя. Он исключен из процесса эволюции экосистемы, так что для внедрения новых “фишек” из очередного релиза потребуется инвестировать столько же денег, сколько в первоначальную инсталляцию.
Upstream: правильный выбор
Однажды несколько активных контрибуторов OpenStack создали компанию Piston. Они решили, что смогут обогнать сообщество разработчиков и сделать на основе “ванильного” OpenStack проприетарный коммерческий продукт. Они понимали как функционирует сообщество и сделали осознанный выбор. Эксперимент дал отрицательные результаты, предоставив сообществу возможность убедиться в том, что самостоятельное “допиливание”, без учета интересов большинства участников процесса разработки, ведет к нежелательным последствиям. Компания Piston оказалась на грани банкротства и была приобретена ИТ-гигантом Cisco, “фракенстек” погубил своего создателя.
К сожалению, многие российские разработчики проигнорировали опыт заокеанских коллег. И продолжают заниматься самодеятельностью, последовательно превращая живой продукт в мертвую сущность, паразитирующую на бюджетах заказчика.
Между тем, заказчик, скорее всего, не одинок в поисках решений тех или иных задач. А значит, продукты, разработанные для клиента, могут стать частью экосистемы OpenStack. А значит будут поддерживаться и совершенствоваться всем сообществом. Есть, правда, нюанс: для этого компания-разработчик должна обладать весом в сообществе, чтобы заинтересовать проектом других игроков. От команды, состоящей из 100 инженеров, не стоит ожидать разносторонней экспертизы, поддержки всех компонентов экосистемы, возможности заниматься внедрением продукта, обучением сотрудников клиентов, поддержкой как предыдущих, так и текущей версий OpenStack.
Впрочем, сотня инженеров вполне может справиться с внедрением решения, разработанного кем-то из “локомотивов” сообщества. Определить состав “паровозного депо” просто. Достаточно открыть сервис Stackalytics.
Еще раз напомним, что клиенту, по факту внедрения решения на базе OpenStack, равно как и любого проприетарного решения, потребуется поддержка. Например, может возникнуть потребность в переходе на новые версии продукта. Желательно, чтобы этот процесс проходил безболезненно и без дополнительных затрат.
Простой пример: вы сделали драйвер для какого-то проприетарного стораджа. Проходит полгода, наступает время обновления системы, администраторы производят апгрейд системы, и тут выясняется, что драйвер-то не работает… А за сторадж были заплачены серьезные деньги. Причина в том, что в ядре системы произошли изменения, но про драйвер никто не подумал. Потому что о его существовании сообщество не имело информации, он был сделан “на коленке” в процессе “допиливания” той версии дистрибутива, которая была актуальна на момент сдачи проекта. А ведь вы, наверняка, не единственный клиент производителя этого стораджа. И еще стопятьсот компаний были бы рады иметь такой драйвер, да еще и в рабочем состоянии. И если бы его делали всем миром, то, во-первых, для каждой из заинтересованных компаний он вышел бы существенно дешевле, а во-вторых, сообщество позаботилось бы о том, чтобы изготовить соответствующий CI и проверить его на любую сборку: эта схема реально работает, что легко наблюдать все в том же Stackalytics в разделе Vendor Drivers.
Подведем итог: среднестатистическому пользователю OpenStack нужен представитель в сообществе. Компания, которая осуществляет внедрение, благодаря партнерским отношениям с “локомотивом”, может представлять интересы своего клиента. Таким образом, если разработчик адекватно оценивает свои силы и заботиться не только о сиюминутной выгоде, но и о благе своего клиента, он приносит пользу всему сообществу. И наоборот: если он заботится о благе сообщества, то, неизбежно принесет пользу клиенту, облегчив его жизнь в будущем. Этим и отличается живой и развивающийся OpenStack от мертвого, холодного и жадного до клиентских денег “франкенстека”.