Слияния и объединения
Опубликовано 01.9.2015 11:05 пользователем Peter Lemenkov
VMware уже просто кричит о контейнерах в своем продукте. Популярность OpenStack пошла им на пользу, как мы видим.
Если честно, немного страшновато - откроешь какой-нибудь ZDNet или TheRegister, и там в каждой статье контейнер на контейнере, и экcперты, прославляющие этот величайший технологический прорыв Человечества со времен электричества. Мы-то знаем, что "контейнер", это обычный процесс, к которому в таблице процессов добавлены метки "namespace" и "control groups", которые учитываются при его работе, но люди, принимающие решения, похоже этого не знают, и всерьез сравнивают с виртуализацией и кластерами "дооблачных" времен. Есть растущее ощущение, что ушедший в ультразвук энтузиазм по поводу контейнеров обернется ужасающим разочарованием. Но пока этого не произошло, давайте наслаждаться открывшимися возможностями.
Так вот, VMware теперь рекламирует не виртуализацию, а контейнеры. Нам это нравится, т.к. это благоприятно сказывается на блудном сыне VMware, компании Pivotal, которая и помогает VMware создавать новую платформу (благо у них уже есть открытая платформа - Cloud Foundry). Для нас Pivotal, конечно, это прежде всего люди, разрабатывающие нашу любимую шину сообщений - RabbitMQ. На базе нее построен обмен сообщениями в OpenStack, и хотя есть попытки использовать конкурирующие AMQP-решения (Qpid), RabbitMQ с места просто так не сдвинуть. Он написан на Erlang, что заведомо повышает качество кода и надежность системы. Нужно отметить, что рядом лиц затрачиваются огромные усилия по включению варианта на базе ZeroMQ, но есть основания предполагать, что это не взлетит никогда. Если кто не в курсе, то у ZeroMQ помимо ряда социально-организационных проблем, есть серьезные недостатки и ограничения, которые следует учитывать. Наши друзья и коллеги, в т.ч. и участники Moscow Erlang User Group, как-то скинулись и переписали ряд особо гадких особенностей ZeroMQ. Получилось внушительно.
Коллеги узнали, что ты решил использовать ZeroMQ
Конечно, с RabbitMQ есть нюансы использования, все-таки CAP-теорему так просто не объехать, но все ведущие компании-разработчики OpenStack сейчас нанимают Erlang-разработчиков, и можно ожидать, что в ближайшее время ситуация улучшится. Сейчас RabbitMQ рассматривается ими как загадочная шкатулка с музыкой, и даже в Red Hat проблемы с ним решаются извне, не трогая код продукта, а привычно перенастраивая окружение от ядра до Glibc.
Интересно, что VMware, похоже понимает, что главное в "контейнерах", это не сами "контейнеры", а их обвязка - средства управления, живой миграции, failover, развертывание, сетевые возможности (SDN) и многое другое. Недаром она привлекает других именно этими возможностями своих проприетарных продуктов. Тем не менее, не только они тут играются. Mirantis в последнее время дружит со всеми - Mirantis и CoreOS, Mirantis и Intel, и даже Mirantis и Goldman Sachs (Голдманы, как и все финансисты, очень любят открытое, даже оборудование). Некоторые даже всерьез используют термин OpenStack Wars (как Unix Wars, только про OpenStack), но в мире OSS воевать непросто да и бессмысленно - лучше сотрудничать.
Если честно, немного страшновато - откроешь какой-нибудь ZDNet или TheRegister, и там в каждой статье контейнер на контейнере, и экcперты, прославляющие этот величайший технологический прорыв Человечества со времен электричества. Мы-то знаем, что "контейнер", это обычный процесс, к которому в таблице процессов добавлены метки "namespace" и "control groups", которые учитываются при его работе, но люди, принимающие решения, похоже этого не знают, и всерьез сравнивают с виртуализацией и кластерами "дооблачных" времен. Есть растущее ощущение, что ушедший в ультразвук энтузиазм по поводу контейнеров обернется ужасающим разочарованием. Но пока этого не произошло, давайте наслаждаться открывшимися возможностями.
Так вот, VMware теперь рекламирует не виртуализацию, а контейнеры. Нам это нравится, т.к. это благоприятно сказывается на блудном сыне VMware, компании Pivotal, которая и помогает VMware создавать новую платформу (благо у них уже есть открытая платформа - Cloud Foundry). Для нас Pivotal, конечно, это прежде всего люди, разрабатывающие нашу любимую шину сообщений - RabbitMQ. На базе нее построен обмен сообщениями в OpenStack, и хотя есть попытки использовать конкурирующие AMQP-решения (Qpid), RabbitMQ с места просто так не сдвинуть. Он написан на Erlang, что заведомо повышает качество кода и надежность системы. Нужно отметить, что рядом лиц затрачиваются огромные усилия по включению варианта на базе ZeroMQ, но есть основания предполагать, что это не взлетит никогда. Если кто не в курсе, то у ZeroMQ помимо ряда социально-организационных проблем, есть серьезные недостатки и ограничения, которые следует учитывать. Наши друзья и коллеги, в т.ч. и участники Moscow Erlang User Group, как-то скинулись и переписали ряд особо гадких особенностей ZeroMQ. Получилось внушительно.
Коллеги узнали, что ты решил использовать ZeroMQ
Конечно, с RabbitMQ есть нюансы использования, все-таки CAP-теорему так просто не объехать, но все ведущие компании-разработчики OpenStack сейчас нанимают Erlang-разработчиков, и можно ожидать, что в ближайшее время ситуация улучшится. Сейчас RabbitMQ рассматривается ими как загадочная шкатулка с музыкой, и даже в Red Hat проблемы с ним решаются извне, не трогая код продукта, а привычно перенастраивая окружение от ядра до Glibc.
Интересно, что VMware, похоже понимает, что главное в "контейнерах", это не сами "контейнеры", а их обвязка - средства управления, живой миграции, failover, развертывание, сетевые возможности (SDN) и многое другое. Недаром она привлекает других именно этими возможностями своих проприетарных продуктов. Тем не менее, не только они тут играются. Mirantis в последнее время дружит со всеми - Mirantis и CoreOS, Mirantis и Intel, и даже Mirantis и Goldman Sachs (Голдманы, как и все финансисты, очень любят открытое, даже оборудование). Некоторые даже всерьез используют термин OpenStack Wars (как Unix Wars, только про OpenStack), но в мире OSS воевать непросто да и бессмысленно - лучше сотрудничать.