Enterprise-системы становятся все сложнее, повышается монолитность, гетерогенность. Объемы данных растут в геометрической прогрессии. Готовы ли разработчики к этим вызовам? Я думаю, что нет. Вместо того, чтобы работать над серьезными вызовами, разработчики гоняются за новыми сверкающими фреймворками, чем только ухудшают ситуацию.
В этой статье мы рассмотрим основные проблемы Enterprise-приложений, оценим, какие (не совсем адекватные) решения предлагает индустрия сейчас, а в следующей статье я напишу, что, по моему скромному мнению, действительно нужно делать, чтобы справиться с этими проблемами.
Почему вообще мы рассматриваем Enterprise
Не все читатели этой статьи — разработчики Enterprise-приложений. Однако я все-таки настаиваю, что нам надо обратить внимание на проблемы Enterprise-приложений в первую очередь. Почему? По многим причинам, которые я перечислю ниже, но все они ведут к тому, что именно Enterprise — то самое место, где все вызовы складываются друг с другом и где первым порвется, когда настанет час Х.
Итак, основные отличительные особенности Enterprise-приложений это:
- Сложность;
- Большие объемы данных;
- Сложные и многообразные интеграции;
- Распределенность;
- Критичность для поддерживаемого бизнеса;
- Высокая стоимость ошибки.
В большинстве случаев разработчики Enterprise-приложений находятся в жестких тисках надежности, сроков, совместимости и масштабируемости. И варианта поэкспериментировать — а вдруг вот эта библиотечка Х, пусть она и пре-альфа версия, отлично же подходит — практически никогда нет. Цена ошибки слишком велика. Нужно сделать так, чтобы работало, и нужно сделать так, чтобы гарантированно работало.
С точки зрения Enterprise, маленькие проекты (до года человеко-часов) — это экспериментальные площадки, на которых можно опробовать новую технологию или новый фреймворк, но настоящий потенциал технологии проверяется только в настоящем кровавом Enterprise.
Следствием всего вышесказанного является также и то, что прежде, чем попасть в настоящую Enterprise-разработку, технология (фреймворк, библиотека) должна отлежаться и доказать свою жизнеспособность. В большинстве случаев такой срок составляет пять лет. Если что-то прожило 5 лет, значит его уже можно начинать использовать — значит завтра уж точно не умрет.
Надеюсь, я убедил, что для нахождения проблем отрасли надо смотреть именно на Enterprise-приложения. Так давайте на них посмотрим.
Проблемы Enterprise-приложений
Самая главная проблема Enterprise-приложений — это сложность. Сложность предметной области и, как следствие, — сложность самих приложений. И это не абстрактное понятие. Например, размер одного из модулей (проекта) в рамках единого Enterprise-приложения обычно около 300-500 Мб исходных кодов. И такой объем информации невозможно взять и запихать ни в одну голову: как бы вы ни старались, часть уже запиханного будет вываливаться из головы. Это СЛИШКОМ много.
Проблема осложняется тем, что все известные мне Enterprise-приложения живут, как трава у дороги: каждый отдельный модуль (проект) растет сам по себе, его разработчики контактируют максимум с разработчиками соседних модулей (и это далеко не всегда), но никогда не видят всей картины приложения в целом. Поэтому в одном модуле применяются одни подходы, в другом — совершенно другие для решения однотипных (а иногда одних и тех же) задач.
Более того — по мере написания системы меняется и сам бизнес, и требования к системе. Так что не получится взять и начать анализировать систему: пока вы анализируете какую-то часть, другая, уже проанализированная часть меняется вследствие изменения задач, которые она призвана решать.
Следующая проблема Enterprise-приложений — монолитность. То есть свойство, не дающее возможности рассматривать какую-нибудь часть системы в отрыве от всего остального, не позволяющее взять и заменить один модуль другим. Вы не можете взять и просто переписать какой-то модуль с нуля. В нем УЖЕ зашиты интеграции с десятком соседних модулей и неявные зависимости от еще десятка других модулей, которые вы можете просто случайно не заметить, и только спустя долгое время выяснится, что какая-то интеграция (о существовании которой вы никогда и не знали) перестала уже достаточно давно работать. И это будет настоящий трындец.
Не менее важная проблема Enterprise-систем — это гетерогенность. Гетерогенность в среде разработчиков принято переводить как «зоопарк». Первым делом практически на каждом проекте новый enterprise-разработчик слышит от коллеги, вводящего его в курс проекта: «У нас тут вообще зоопарк». В смысле у нас тут полный зоопарк из серверов, технологий, языков программирования, фреймворков, библиотек и даже подходов к решению однотипных задач. Даже если используется один и тот же софт, то в разных местах используются разные версии. И это свойство, естественно, также накладывается на предыдущие проблемы. Мало того, что система сложная и монолитная, так она еще и состоит из разнородных кусочков, что не позволяет абстрагироваться от деталей реализации и подняться на более высокий уровень понимания.
Гетерогенность — свойство систем, которое самоотверженно игнорируется нашим разработческим сообществом. Я бы сказал, разработчики даже кичатся тем, что у них настолько все перепутано, столько технологий и всякого такого.
Следующая проблема — это внешние интеграции. Мало того, что Enterprise-приложение сложное, мало того, что оно состоит из разнородных частей и еще устроено так, что невозможно его взять и проанализировать кусочек за кусочком, так оно еще и интегрируется с другими такими же здоровыми, запутанными и монолитными приложениями. И по-хорошему, надо бы анализировать приложение не в гордом одиночестве, а в привязке к логике интеграции, что явно не упрощает дело 🙂
Более того, я часто люблю рассказывать такой пример. В США (вроде бы не самой отсталой стране мире, особенно в техническом плане) до сих пор все компании, связанные с телевизионным вещанием, синхронизируют свои программы передач с помощью выкачивания файлов (!) по FTP (!!!). Да-да, 4 Гб XML в архиве. Как вам такая интеграция? Самые дикие случаи я из уважения к бывшим клиентам (и из-за NDA) вам рассказать не могу. Но поверьте, там вообще на самом деле СТРАШНО. Просто В2В — это раз настроено и работает до конца века, это даже не пять лет.
И последний аспект, вернее проблема, о которой я хотел бы сказать, — это объем данных. Вы просто должны понимать, что как бы я тут не упражнялся в красноречии, предрекая грядущий Апокалипсис, все это безобразие худо-бедно работает и справляется со своими обязанностями. Поэтому на сегодняшний момент нет (вернее не было) никаких поводов устраивать панику, если бы не этот аспект. Как видно по графику ниже, объем данных, хранимых в системах, экспоненциально возрастает и рано или поздно (скорее всего — рано) превысит возможности текущих монолитных приложений и реляционных баз, используемых как общее хранилище на множество модулей системы.
Откуда берется такой поток данных? Тут все очень просто. Во-первых, практически все данные, один раз попавшие в Enterprise-систему остаются там навечно. Во-вторых, каждый день бизнес придумывает все новые способы получения дополнительных данных. И все эти данные складируются и складируются 🙂 Приближая, естественно, момент апокалипсиса.
И как вы понимаете, смена парадигмы хранения данных приведет к неработоспособности всех накопленных за долгие годы решений, многие из которых работают вообще без никакой документации, а иногда даже исходного кода.
Объемы же кода Enterprise-приложений примерно такие. Один модуль — 300-500 Мб исходников. Это модуль, который развивала на протяжении 10 лет команда из 3-5 разработчиков. Модулей таких — от полусотни до тысячи. То есть все приложение — это навскидку что-то порядка терабайт-десятков терабайт исходников.
Вы понимаете, это не то, что можно просто взять и переписать. Это не то, что можно в какие-то представимые временные рамки отрефакторить. И с этим всем надо что-то делать.
Разработчики регулярно поднимают еще одну проблему — legacy code. Я лично это вообще проблемой не считаю. Особенно на фоне всего предыдущего. Это просто свойство Enterprise-систем. Вы не можете взять и написать такое приложение за месяц, за год, даже за несколько лет силами одной команды разработчиков. Все равно это пишется годами, а часто десятилетиями, причем силами многих и часто разрозненных команд разработчиков.
Но тут работает одна особенность человеческой психологии: ищем не там, где потеряли, а там, где светло. Что делать со старым кодом — любой программист знает — конечно, выкинуть его и написать заново! Как говорится, у вашей системы есть один ключевой недостаток — она написана не нами. И программисты, естественно, проблему legacy кода выпячивают наперед — чтобы была понятная задача.
Ну вы же понимаете, что систему размером в терабайт (хотя бы) исходников нельзя просто взять и выкинуть, и написать заново. Как будет работать компания без своей системы? А если компания будет продолжать работать на старой системе, то значит либо изменения в старой системе не делать ( предлагаю любопытным самим представить результаты работы компании, которая несколько лет игнорирует запросы рынка), либо изменять ОБЕ системы — и старую и новую параллельно. Предлагаю также прикинуть, как это вообще сделать, если мы уже договорились, что анализ системы целиком невозможен.
Как все это решается сейчас
Сначала большими мазками.
Программисты, наткнувшись на любую проблему, естественно, первым делом тянутся за любимым золотым молотком — новым, желательно только что вышедшим фреймворком, а еще лучше — новым языком, в котором (конечно же!) эта проблема невозможна. К чему это приводит — и так понятно — повышается гетерогенность (да-да, а вы думали, откуда вообще берется этот зоопарк на проектах?). И, естественно, в новых языках/фреймворках есть ДРУГИЕ проблемы, которых не было в старых. И не факт, что проблем становится меньше. Возможно, даже больше. Просто это ДРУГИЕ проблемы.
Руководство (тимлиды и проектные менеджеры), конечно же, знает о таком свойстве любимого программистами решения. В большинстве своем лиды сами из программистов/тестировщиков. Поэтому они не дают по каждому чиху хвататься за новый золотой молоток. На что программисты возмущаются в курилках и ругают бестолковое начальство.
Но у ПМов/тимлидов тоже есть их любимый золотой молоток — это методологии разработки. И этими методологиями они увлекаются не хуже, чем программисты новыми фреймворками. И точно так же любят их засовывать в любой проект по любому поводу. Самое смешное, что эти методики работают. Дело в том, что по своей природе человек любит изменения и настроение у всего коллектива от изменений улучшается. Вот люди и начинают работать лучше. А их руководители тут же решают, что это эффект новой методологии.
Через некоторое время эффект от новой методологии перестает сказываться, и тут же руководители программистов уезжают на новую конференцию или читают новую книгу и добывают там новый золотой молоток. Цикл повторяется.
Пока выглядит так, что на низовом уровне (программисты и их непосредственное руководство) никто перечисленные проблемы решать не собирается. Так может быть эту проблему решают на высшем уровне?
Вынужден вас огорчить. Высшее руководство Enterprise-компаний вообще не имеет к миру IT в большинстве своем никакого отношения. Они имеют экономическое и бизнес-образование, соответствующий набор знаний и круг интересов. И даже если вы вдруг прорветесь с описанием проблем разработки на высший уровень, то вас там, скорее всего, просто не поймут. Высший руководитель задаст вам всего один вопрос: «Мы деньги делаем и будем продолжать делать?». Если вы ответите утвердительно на оба вопроса, то он вас отправит на уровень ниже, где уже понятно, как это решается. Если вы ответите отрицательно, то на ковер будет вызван представитель этого уровня, показательно выдран и отпущен с наставлением — сделать так, чтобы поток денег не заканчивался. Как решают проблемы представители среднего уровня — я рассказывал двумя абзацами выше.
Ну так что — все безнадежно? Я так не думаю. Но подробнее я расскажу об этом во второй части статьи.
