Pull to refresh

Comments 21

Просто настоящей боли пост.
С нетерпением жду, как Вы все это разгребли (сам был в той же ситуации, но тоже вышел из нее с щитом)
Продолжение: https://habrahabr.ru/post/317408/
Интересно, продолжайте! На самом деле, это естественный ход вещей. Стартап за 2 года подрос, набрал клиентов, теперь задумался о качестве услуг и процессов, масштабировании и гибкости не в ущерб имеющимся клиентам. Можно лишь поздравить! Не все доживают.
Продолжение: https://habrahabr.ru/post/317408/
Да, Gentoo это мило и прекрасно на проде. А могла быть слакварь :)
Кто-то от Gentoo плюется, кто-то от Slackware, мы вот от CentOS с его dracut плевались, когда при создании снапшота lvm — он отказывался грузиться. Не важно в принципе какой дистрибутив используется, все зависит от того сколько процентов в команде могут с ним нормально управляться, если только один человек, то беда…
Ну количество человеко-часов затраченое на поддержку Gentoo всё-ж поболее будет, чем на поддержку rpm- или deb-based дистрибутива. «Какой дистрибутив» в контексте «Debian или CentOS» и правда не имеет значения, но вот «source-based или binary» — очень даже. Я про это немного во второй части пишу.
Мы в нашем приложении автоматически при каждой сборке создаем около 120 пакетов. Релизимся примерно 2-3 раза в день. Плюс около 30-40 билдов тестеров и столько же дев. Пакеты не простые: каждый апгрейд умный и делает все как надо при помощи pre/post inst/rm скриптов, включая миграции SQL.
Сделаете тоже самое на Gentoo?
Очень интересно, жду продолжения, всегда тяготел к подобным историям.
Боль с Gentoo на сервере ощутил на себе.
Продолжение: https://habrahabr.ru/post/317408/
Вопрос скорее не к администраторам, а к разработчикам:
— В какой ситуации такая архитектура имеет смысла?
— Зачем срез состояний хранить в Redis?
— Зачем шина?
— Зачем вообще такое кол-во баз данных?
— Зачем хранить состояния в NoSQL базах?

Я в следующей части пройдусь по некоторым моментам из списка.
Продолжение: https://habrahabr.ru/post/317408/
Попытаюсь угадать: не удовлетворяет условиям масштабируемости (хороша для сообщений точка-точка), надежности (сообщения не персистентны).
Плохо угадываете. Если инструмент не подходит по своим характеристикам, его просто не будут использовать. Или как вы себе представляете, люди взяли 0mq, а через год поняли что персистентности нет?
Очень интересно. Пишите еще.

А как там по производительности?
Какую нагрузку держал такой зоопарк на таком железе в начале вашей разборки?
А были ли средства отказоустойчивость обеспечивающие? Падение одного сервера не рушило систему?

То ест весь этот зоопарк хоть как-то себя оправдывал или нет?
Плохо всё было по производительности. Упёрлись в пару говённо сделаных реализаций, и при 400-500 пользователей динамическая часть сайта тормозила страшно.
Отказоустойчивости не было, если падал один сервис — ложилось всё.

Продолжение: https://habrahabr.ru/post/317408/
У меня объяснение это всему одно (особенно насчет админки): девопс просто принципиально не хотел пользовать PHP как несерьезный, и ему даже было невдомек, что он просто идеально подходит для таких задач. В конечном итоге сам себя в лужу и посадил.
Ну, с PHP я бы так не горячился. Питон/Перл, да тот же Руби, на котором остальной проект писан — было бы идеальным решением (не потому, что PHP плох, но потому, что Питон и Перл есть вообще везде, Руби — язык проекта, т.е. тоже в наличии по-умолчанию).
А, ну это да, и правда, Раби из коробки, да еще и на рельсах. Нет, насчет PHP все понимаю, просто надо смотреть сколько лет сему стартапу, лично я начинал свой крупный проект (у меня CMS) еще в те времена, когда писать что-либо для веба на чем-либо, отличном от PHP, считалось самоубийством. Нет, это было не так давно, просто те же Питон и Раби еще не завоевали свою популярность в этой области.
Sign up to leave a comment.

Articles