28 января вечером GitHub был недоступен в течение двух часов и шести минут. Из-за сбоя в системе энергообеспечения главного дата-центра GitHub перезагрузилось около четверти серверов и сетевых устройств. В результате этого инцидента инфраструктура сервиса осталась в целом в рабочем состоянии, но были затронуты системы, от которых зависели приложения GitHub, что сделало невозможным доступ к ним со стороны пользователей. В ответ на любой запрос приходил ответ HTTP 503 («сервис недоступен»).
Оперативное предупреждение пользователей было осложнено тем, что большинство ChatOps систем находилось на перезапущенных серверах. В итоге, недоступность сервиса не была отображена на status.github.com в течение восьми минут, что ребята из GitHub считают абсолютно неприемлемым.
Эта ситуация заставила меня задуматься, а не является слишком наивной вера во всесильность и универсальность парадигмы DVCS?
Каждый год компания Perforce представляет традиционный январский пост с прогнозами развития индустрии VCS. В этом году ребята предсказывают развитие гибридных систем контроля версий. Эта парадигма подразумевает смесь привычного большинству разработчиков распределённого подхода (для push/merge/branch операций) и функций централизованных систем контроля версий (для хранения больших файлов и TBD).
К сожалению, сейчас на рынке VCS мало гибридных решений. Тут я могу сослаться на отчёт Gartner о продуктах в данной области. Согласно исследованию, около трети компаний-разработчиков пользуются DVCS решениями (вроде Git и Mercurial), другая треть применяют централизованные (Subversion). Оставшиеся 40% приходится на проприетарные продукты от IBM, Borland, Perforce, Serena, среди которых есть DVCS, VCS, HVCS системы.
Аналогичный традиционный Eclipse Community Survey (за 2014 год) показывает близкие к этому цифры за 2014 год: треть рынка за Subversion, 40% приходится на Git, GitHub и Mercurial, — оставшаяся часть рынка поделена между обозначенными выше компаниями.
Есть ещё древние данные (IDC 2012), которые показывают более подробное распределение рынка проприетарных решений: IBM (35%), CA Technologies (13%), Serena (10%) – лидеры рынка, Atlassian (6%), Microsoft (4,5%), Perforce (3%) – середнячки.
При этом из всех немногих гибридных решений самым крупным игроком является линейка Perforce Helix. Разработчики Helix опередили свой собственный прогноз и создали полноценную гибридную систему. IBM ClearCase полностью CVCS решение, также как Harvest Software Change Manager от CA. Serena Dimensions CM не имеет интеграции с привычным всем, как я писал выше, Git.
Итак, из приведенных выше исследований можно понять, что HVCS — относительно новая, пока еще не трендовая, но интересная и конкурентоспособная ветвь развития VCS. К сожалению, я не нашёл материалов на Хабре о мультипарадигменных технологиях VCS и о Helix, поэтому планирую углубиться в изучение продуктов и рассказать о будущем, которое, потенциально, наступило уже сегодня.
Я хочу ещё раз вернуться к мифу об универсальности и мощи распределенных систем. DVCS действительно позволяют одиноким разработчикам очень много делать локально и быстро (ограничивая скорость работы только возможностями файловой системы). Но, исключая этих ковбоев, что делать разработчикам, когда они хотят что-то забрать с сервера, а он недоступен?
Отпуск GitHub, пусть и краткосрочный, был для разработчиков чем-то вроде штормового предупреждения. Это, знаете, очень клёво, когда начинает дуть сильный ветер, и не нужно идти в школу. И это пустяково в случае личных или open-source проектов, но катастрофично для бизнеса.
Мне хочется обратиться к вашему мнению, верите ли вы в постепенное вытеснение «чистокровных» методологий VCS аналогичными мультипарадигмальными технологиями?
Комментарии (22)
dvor
04.03.2016 16:12+13распределенных систем
что делать разработчикам, когда они хотят что-то забрать с сервера, а он недоступен?
vasya$ git remote add server2 ssh://git@server2 vasya$ git push --all server2
petya$ git remote add server2 ssh://git@server2 petya$ git pull server2
?
Crandel
04.03.2016 16:17+9Множество компаний используют свои собственные гит/меркуриал сервера, в том числе с гитлабом в качестве оболочки. Вообще на бред похоже
jkeee
04.03.2016 16:33-1Если я чего-то не понимаю, то я был бы рад, если бы утверждение о бредовости размышлений было более аргументировано. )
Crandel
04.03.2016 16:36+1Эта парадигма подразумевает смесь привычного большинству разработчиков распределённого подхода (для push/merge/branch операций) и функций централизованных систем контроля версий (для хранения больших файлов и TBD).
Вообще непонятно, о чем идет речь? вы же описываете типичное поведение гитхаба и гитлаба. В чем разница?
AMDmi3
04.03.2016 16:39+9> Эта ситуация заставила меня задуматься, а не является слишком наивной вера во всесильность и универсальность парадигмы DVCS?
Не является, потому что DVCS тут вообще не при чём. Упал централизованный GitHub, и только.
В остальном, вообще не сказано что это за гибридные VCS такие, и что они могут дать чего не может git. А последний как раз позволяет любые надёжные схемы, от зеркал до прямого обмена изменениями между разработками, на то он и Dvcs.
dim_s
04.03.2016 16:40+4Если представить, что GitHub использовал бы например SVN, централизованную систему, ничего бы не поменялось. Как раз таки гитхаб делает из гита немного централизованную систему, это проблема не гита, а конкретно github'a. К тому же, если все разработчики работают локально в одной сети, то можно быстро сделать локальный репозиторий одного разработчика "центральным", делая пуши ему.
Это проблемы централизованных систем и гибридных, гибридные системы добавляют централизации, из-за которой-то и возникают выше описанные проблемы.jkeee
04.03.2016 16:55-1То есть в целом распределенные системы всё также прекрасны и идеальны, а любое добавление централизованности эту утопию рушит?
lexore
04.03.2016 17:23+10Да. Мне кажется, падение github'а это прекрасно проиллюстрировало. И вы знаете, ваша точка зрения, мягко говоря, не понятна.
Со стороны это выглядит так:
- Приупал очень популярный git сервер, с кучей дополнительных централизованных сервисов. В результате именно дополнительные централизованные сервисы и пострадали.
- Сами репозитории git не пострадал в силу своей распределенности (ну или пострадали те пользователи, кто не мог сделать git remote add).
- И вы спрашиваете у сообщества "а может добавим git централизованности, чтобы он не пострадал?"
Простите, но где логика?
Сейчас git не пострадал, но вы задумываетесь "что-то тут не так".
Если добавить централизованности, то да, что-то пострадает.
P.S.
Ещё хочу напомнить, что github — это не столько git сервер.
Это хостинг для проектов с кучей инструментов для разработки: веб интерфейс к git, wiki, трекер ошибок, форум и т.д. и т.п.
Эти сервисы централизованы и их недоступность конечно же мешает разработке.
Но они, само собой, не являются VCS.
semenyakinVS
04.03.2016 17:55+8А что такое категория "GitHub" на представленном графике? По-моему, это не совсем корректно.
Это всё равно, что писать сравнение использования языков программирования и в перечисление включать "MinGW".
develop7
05.03.2016 07:57+3Возможно, респонденты, не отличающие хостинг репозиториев от VCS от клиента к ней.
semenyakinVS
05.03.2016 12:52+1Самое забавное, что я не в первый раз такую классификацию вижу — когда GitHub в отдельную от Git категорию кладут. Интересно почему так повелось.
k12th
04.03.2016 18:08+6Падение гитхаба — не проблема DVCS вообще никаким боком. Если бы gmail упал, никто не стал бы писать бред, что де электронная почта ненадежна и нужны «гибридные решения».
Если бы оно продлилось дольше — ну что ж,git remote add bitbucket https://username@bitbucket.org/— и я не уверен, что это возможно с SVN или мифическим «гибридным решением» (ладно, назовем вещи своими именами — с Perforce).
aobondar
Либо я дурак, либо лыжи не едут: т. е. в связи с падением гитхаба, из-за которого в течении некоторого времени разраобтчики не могли синхронизироваться с центральным репозиторием, вы предлагаете смотреть в сторону более централизованных решений, падение которых вообще бы парализовало работу?
jkeee
Я не предлагаю, а скорее хочу обратиться к сообществу, видите ли вы стабильность в текущей ситуации и что всё «ок», или действительно назревает какой-то сдвиг от чистых распределенных/централизованных систем в пользу гибридных.
Это скорее посыл порассуждать на эту тему.
aobondar
Ну да, но на мой взгляд данная ситуация — хрестоматийная иллюстрация недостатков централизованных/гибридных схем, и гит позволил пройти через этот блекаут с минимально возможными потерями. Поразмыслить то всегда полезно, но на мой взгляд вы тут свои точку зрения проиллюстрировали крайне неудачным примером
vintage
Централизованные системы контроля версий — это частный случай децентрализованных. Потому как звезда — это частный случай графа. Что такое "гибридные" системы в этом контексте — ума не приложу.