Comments 23
С одной стороны всё верно и хорошо сказано, с другой — это понимает каждый вменяемый айтишник, даже не важно, какого профиля. То есть выводы КО.
Просто не все могут грамотно обосновать руководству необходимость апгрейда системы, если не своими, то сторонними силами. То есть тупо подготовить расчет рисков для бизнеса.
И если админ способен это сделать, то это уже не админ, а тянет на начальника IT-отдела, которого может и не быть в организации, т.е. простыми словами он вырос до уровня, когда пора валить. Так и происходит, и дальше всё по кругу.
Просто не все могут грамотно обосновать руководству необходимость апгрейда системы, если не своими, то сторонними силами. То есть тупо подготовить расчет рисков для бизнеса.
И если админ способен это сделать, то это уже не админ, а тянет на начальника IT-отдела, которого может и не быть в организации, т.е. простыми словами он вырос до уровня, когда пора валить. Так и происходит, и дальше всё по кругу.
Юрий, это размышления, в основном, адресованные собственникам и руководителям, я не айтишникам…
Сплошь и рядом приходится видеть подход «работает ведь, тут подкрутите, там почините»…
Сплошь и рядом приходится видеть подход «работает ведь, тут подкрутите, там почините»…
Ну, собственники и руководители, читающие хабр, в большинстве своём достаточно продвинутые и адекватные люди, и тоже должны это понимать, ИМХО.
Руководители, как и айтишники, всё это прекрасно понимают. Но, зачастую, руководители имеют свои интересы, отличные от интересов собственника и отличные интересов предприятия, и решения они принимают исходя именно из своих личных интересов. Увы, Аминь.
Если я понял правильно
Сколько трубы не меняй — дерьмо остается тем же.
Сколько трубы не меняй — дерьмо остается тем же.
Но время делает свое дело, и любая система начинает сбоить: от возросшей нагрузки (вон сколько народу), от старости труб и вентилей, от криворукого обслуживания.
А ничего, что (адекватно спроектированные) программные системы, в отличие от труб и вентилей, стареть не должны?
Часто бывает, что система проектируется под определенные задачи/нагрузку, а бизнес через какое-то количество лет вносит свои коррективы — теперь latency важнее чем throughput, к примеру, или еще что-то в этом роде, а система была заточена изначально делать что-то противоположное. и подкрутить где-то что-то, потьюнить индексы или еще как-то переточить существующий продукт может не выйти, нужна другая архитектура.
Вот только это не значит, что система устарела, это значит, что она находится за пределами проектных параметров.
И, в общем-то, это не всегда значит, что старую систему надо выкинуть и обязательно сделать новую, иногда и эволюционный путь возможен.
иногда и эволюционный путь возможен.
Ключевое слово — «иногда». Если разработчики заложили возможность этой эволюции. Чаще как, надо здесь и сейчас, а дальше трава не расти…
Если система не удовлетворяет сегодняшним требованиям бизнеса (хотя еще год назад она им удовлетворяла), значит она устарела. А что, если не это, термин «устаревание» по-вашему означает?
Ну спроектировали систему, к примеру — небольшой интернет-магазин. База данных — какой-нибудь MS-SQL сервер, ну фронтенд какой-то на ASP.NET, может даже мидл-лэйер есть с вебсервисами, куда потом можно будет прикрутить мобильный клиент. А через 5 лет оказалось, что вырос магазин до уровня Amazon.com, что нужна абсолютно другая архитектура, чтобы это все обслуживать — и набор фронтендов в датацентрах ближе к покупателям, и распределенная база типа Spanner-а со своей георепликацией, паксосом и прочими плюшками, и т.д. Да, можно сказать, что «давно созданная система находится за пределами проектных параметров». Но при этом все же справедливо, что система устарела.
Ну спроектировали систему, к примеру — небольшой интернет-магазин. База данных — какой-нибудь MS-SQL сервер, ну фронтенд какой-то на ASP.NET, может даже мидл-лэйер есть с вебсервисами, куда потом можно будет прикрутить мобильный клиент. А через 5 лет оказалось, что вырос магазин до уровня Amazon.com, что нужна абсолютно другая архитектура, чтобы это все обслуживать — и набор фронтендов в датацентрах ближе к покупателям, и распределенная база типа Spanner-а со своей георепликацией, паксосом и прочими плюшками, и т.д. Да, можно сказать, что «давно созданная система находится за пределами проектных параметров». Но при этом все же справедливо, что система устарела.
Если система не удовлетворяет сегодняшним требованиям бизнеса (хотя еще год назад она им удовлетворяла), значит она устарела.
Нет, это значит, что требования изменились. В противовес "физическим" конструкциям, которые устаревают сами по себе, безотносительно требований.
Ну хорошо, если вам так сильно нравится называть это другими словами, давайте будем говорить, что не система устарела, а требования изменились. Факта того, что нужна другая система в новых реалиях, это не меняет. В статье все же рассматривается вариант, когда объем в трубах растет (что способствует росту зарплат создателей). То есть нагрузка на систему растет и при этом не сказано, была ли система спроектирована выдерживать нагрузку такого уровня. Это ведь не просто «физическая» конструкция, которую рассчитали выдерживать какую-то нагрузку, и она со временем эту нагрузку перестала выдерживать — в этом случае было бы справедливо сказать, что она не спроектирована адекватно.
Факта того, что нужна другая система в новых реалиях, это не меняет.
может быть нужна. В вашем конкретном примере новые требования радикально отличаются от предыдущих, но много ли таких изменений на общем фоне?
В статье все же рассматривается вариант, когда объем в трубах растет
В статье сказано — именно это я цитировал — что любая система начинает сбоить. Что, в общем-то, является типичным обоснованием для "а давайте все перепишем заново" вместо вдумчивого разбора, как на самом деле можно решить проблему.
нужна другая архитектура
Ну да, либо на костылях как в картинке. О том и статья.
Сергей, стареют, к сожалению, и грамотно спроектированные системы…
Софт, по мере развития, становится все более прожорливым и железо 5-ти летней давности не всегда с ним справляется…
А потом… появляются новые возможности, которые невозможно игнорировать. Люди приходят на работу со своими гаджетами и многие руководители это поощряют — быть всегда на связи, а спроектированная лет 7-10 назад система просто не сможет их принять в свой состав…
А главная беда в том что адекватно спроектированных систем мало. В основном они растут как получится, без генерального плана. Конечно же, есть исключения, но их не так много, к сожаления.
Софт, по мере развития, становится все более прожорливым и железо 5-ти летней давности не всегда с ним справляется…
А потом… появляются новые возможности, которые невозможно игнорировать. Люди приходят на работу со своими гаджетами и многие руководители это поощряют — быть всегда на связи, а спроектированная лет 7-10 назад система просто не сможет их принять в свой состав…
А главная беда в том что адекватно спроектированных систем мало. В основном они растут как получится, без генерального плана. Конечно же, есть исключения, но их не так много, к сожаления.
Софт, по мере развития, становится все более прожорливым
А откуда у вас внезапно берется развитие софта без соответствующего допроектирования? Типичная ошибка развития, которую нельзя исправить желанием каждый раз писать заново.
Адекватно спроектированные системы — очень абстрактное понятие.
Во многих организациях изначально все было спроектировано под определенные цели и задачи. Но со временем цели и задачи поменялись, что вызвало необходимость «вот прямо вчера» прикручивать к имеющимся системам дополнительные вещи. За несколько лет такого процесса получается как раз та самая «старая канализация».
Во многих организациях изначально все было спроектировано под определенные цели и задачи. Но со временем цели и задачи поменялись, что вызвало необходимость «вот прямо вчера» прикручивать к имеющимся системам дополнительные вещи. За несколько лет такого процесса получается как раз та самая «старая канализация».
Sign up to leave a comment.
Про информационные системы и старые канализационные трубы