Для профессионалов в тестировании! >>>TestingStage2018>>> Продажа билетов на конференцию открыта. Успей купить!
×Закрыть

Enterprise разработка накануне провала традиционных методов

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 в большинстве своем никакого отношения. Они имеют экономическое и бизнес-образование, соответствующий набор знаний и круг интересов. И даже если вы вдруг прорветесь с описанием проблем разработки на высший уровень, то вас там, скорее всего, просто не поймут. Высший руководитель задаст вам всего один вопрос: «Мы деньги делаем и будем продолжать делать?». Если вы ответите утвердительно на оба вопроса, то он вас отправит на уровень ниже, где уже понятно, как это решается. Если вы ответите отрицательно, то на ковер будет вызван представитель этого уровня, показательно выдран и отпущен с наставлением — сделать так, чтобы поток денег не заканчивался. Как решают проблемы представители среднего уровня — я рассказывал двумя абзацами выше.

Ну так что — все безнадежно? Я так не думаю. Но подробнее я расскажу об этом во второй части статьи.

LinkedIn

65 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Например, размер одного из модулей (проекта) в рамках единого Enterprise-приложения обычно около 300-500 Мб исходных кодов. И такой объем информации невозможно взять и запихать ни в одну голову: как бы вы ни старались, часть уже запиханного будет вываливаться из головы. Это СЛИШКОМ много.

Обычно в 300-500 Мб входит следующее:
* исходный код, который, за редким исключением, не будет превышать 50Мб
* бинарники — либы, тулзы и куча другого накопившегося г-на
* дока разного формата
* куча данных для тестов, если они есть. Например, вы писали, что кто-то там 4Гб файлов гоняет, так вот, модуль, который гоняет эти файлы, в репозитории может весить более 4Гб

Так что в этом вопросе не все так плохо, как кажется на первый взгляд.

Золоті слова:
«Дело в том, что по своей природе человек любит изменения и настроение у всего коллектива от изменений улучшается. Вот люди и начинают работать лучше. А их руководители тут же решают, что это эффект новой методологии.
Через некоторое время эффект от новой методологии перестает сказываться, и тут же руководители программистов уезжают на новую конференцию или читают новую книгу и добывают там новый золотой молоток. Цикл повторяется.»

500мбайт / 50 ~ 10M SLOC?!

1 модуль?

Нужно именно человек 50 в течение 2 лет, чтоб столько наколбасить. И то, это вряд ли вообще доедет до прода — потонет в багах

90% финансовых транзакций в мире все еще на Коболе. сколько лет Коболу, например?)

А при чем тут количество лет Коболу к непрерывной разработке модуля на коболе? Или вы считаете, что все проекты на коболе до сих активно разрабатываются уже, ни мало ни много, 58 лет?

статья ни о чем

Зависит от продолжения. Если там будет обзор рецептов от безнадеги, то эта статья превращается в годное вступление с перечислением проблем.

Могу предположить часть решения проблемы в том, чтобы с каждым новым изменением как-то улучшать код: уменьшая связность, повышая читаемость, полностью покрывая его тестами, и т.д. Всё отрефакторить не получится, но можно делать это локально по ходу разработки. Если с момента осознания проблемы каждый после себя оставит код в лучшем состоянии, чем он был до этого, долгосрочный результат должен быть положительным. Правило бойскаута: «оставь место стоянки чище, чем оно было до твоего прихода».

Конечно, этого должны захотеть и разработчики, и менеджеры, выделяя чуть больше времени на каждую задачу...

Публичные и частные компании не будут афишировать свои фейлы, так как это может испортить их бизнес репутацию.
Но у нас есть замечательный кейс внедрения зарплатной системы для госслужащих в калифорнии.

Дано: The California State Controller’s Office (SCO) is currently running on an old COBOL-based payroll system that dates back to the 1970s
Проект начали в 1990х. Спустя 250 млн в 2013 калифорния сдалась и подала на sap в суд, который был выигран в 2016 — добились возврата части денег.

www.computerworld.com/...​oll-software-project.html

А кобол и ныне там...

Да-да, 4 Гб XML в архиве. Как вам такая интеграция?

Нормально такая интеграция. Кого теперь напугаешь четырьмя гигабайтами? Две серии Game of Thrones в HD.

Биг — то когда хотя бы два сезона...

Кстати таки с учётом разнообразия ГГ и просто убиенные таки только доля шутки.

Скачать 4 ГБ это не проблема.
Даже скачивать их каждый час не большая проблема.
Предположим, это проецируется на таблицу, исходя из 100 байт на запись.
Оп, а у нас тут внезапно 11К транзакций в базу данных в секунду....

Дело в том, что по своей природе человек любит изменения и настроение у всего коллектива от изменений улучшается.

Это утверждение весьма сомнительно, на чём оно базируется, позвольте узнать?

Базируется на том, что каждый вечер кушать пельмени быстро надоедает, хочется что-то новое.

Согласен, везде натыкался только на противоположные утверждения.

«Люди ненавидят перемены... и это потому, что люди ненавидят перемены... я хочу быть уверен, что вы понимаете меня. Люди действительно ненавидят перемены. Они воистину их ненавидят.»
Стив Макменамин. The Atlantic Systems Guild (1996)

так в том и дело, люди любят не перемены, а видимость перемен, и потом после смеха над инновациями руководства — вернуться к делам ,"как обычно"..
Но без этих видимостей перемен -возникает стресс от монотонности и замыливания глаз..

Enterprise-системы становятся все сложнее, повышается монолитность, гетерогенность.

Это из какого года наблюдения?

Готовы ли разработчики к этим вызовам? Я думаю, что нет.

Уверяю, что не все так думают.

Вместо того, чтобы работать над серьезными вызовами, разработчики гоняются за новыми сверкающими фреймворками, чем только ухудшают ситуацию.

«Яка сім’я — таке і сонечко».
Где-то наверное гоняются, однозначно. :)

Высшее руководство Enterprise-компаний вообще не имеет к миру IT в большинстве своем никакого отношения.

Даже если менеджер еще 2-3 года назаж сам кодил, тот факт что сейчас он отвечает за огромный отдел от которого зависит многомиллионный доходы сразу меняет мышление.

— «It’s just a technical problem» и количество закопанных склетов по дороге не интересно

экзистенциальный ужас энтерпрайза

если б только энтерпрайза.. :)

среднестатистический случай — собираем 4-5 девов, которые до этого вместе не работали (парочку вообще только что наняли на рынке, т.к. своих не хватало), даём им проект на полгода чуть сложнее чем, условно, формочки наклепать и смотрим что получится на выходе. а там тебе будет и зоопарк подходов, и сложность, и легаси, и отсутсвие полного понимания всего проекта у отдельно взятого члена команды. а ведь кому-то это потом сапортить.

Более того, я часто люблю рассказывать такой пример. В США (вроде бы не самой отсталой стране мире, особенно в техническом плане) до сих пор все компании, связанные с телевизионным вещанием, синхронизируют свои программы передач с помощью выкачивания файлов (!) по FTP (!!!). Да-да, 4 Гб XML в архиве. Как вам такая интеграция?

а что тут такого странного? В развитых странах как раз чаще встречаются более олдскульные технологии, так как внедрены были раньше и работают. Или автор предпочел бы вместо архивированного xml запросы такого же размера SOAP, который был так популярен в начале 2000х? Или может ванильным RESTом его получить, следуя моде десятилетней давности? Хотя в конце концов в правильном энтерпрайзе все равно будут стоять адаптеры, конвертирующие во внутреннее представление, так что тоже не суть важно.

В большинстве случаев разработчики Enterprise-приложений находятся в жестких тисках надежности, сроков, совместимости и масштабируемости. И варианта поэкспериментировать — а вдруг вот эта библиотечка Х, пусть она и пре-альфа версия, отлично же подходит — практически никогда нет. Цена ошибки слишком велика. Нужно сделать так, чтобы работало, и нужно сделать так, чтобы гарантированно работало.

как-то слабо коррелирует с моим лично опытом. Как раз найти что-то экзотическое, что казалось вот-вот взлетит 5-10 лет назад, но так и кануло в лету — самое обычное дело в Энтерпрайз легаси, даже в Mission critical частях.

Как видно по графику ниже, объем данных, хранимых в системах, экспоненциально возрастает и рано или поздно (скорее всего — рано) превысит возможности текущих монолитных приложений и реляционных баз, используемых как общее хранилище на множество модулей системы

как бы уже сложно встретить более-менее современный Энтерпрайз совсем без хадупа или просто nosql. Как только ценник вендора традиционных RDBMS начинает расти экспоненциально, энтерпрайзы становятся очень сговорчивы на нетрадиционность.

Объемы же кода Enterprise-приложений примерно такие. Один модуль — 300-500 Мб исходников. Это модуль, который развивала на протяжении 10 лет команда из 3-5 разработчиков. Модулей таких — от полусотни до тысячи. То есть все приложение — это навскидку что-то порядка терабайт-десятков терабайт исходников.

это вы с теми классическими индусскими аутсорсерами наверное встретились, которым за строки кода премии выдавали.

Ну вы же понимаете, что систему размером в терабайт (хотя бы) исходников нельзя просто взять и выкинуть, и написать заново. Как будет работать компания без своей системы? А если компания будет продолжать работать на старой системе, то значит либо изменения в старой системе не делать ( предлагаю любопытным самим представить результаты работы компании, которая несколько лет игнорирует запросы рынка), либо изменять ОБЕ системы — и старую и новую параллельно. Предлагаю также прикинуть, как это вообще сделать, если мы уже договорились, что анализ системы целиком невозможен.

проблема стара и известна. Индустрия понемногу научилась с ней работать, и полностью за один присест большие системы никто в своем уме не переписывает уже. По кускам вполне расчленяется на те же микросервисы, никакого апокалипсиса.

Тема, конечно, вообще интересная, но к сожалению автор слишком обобщает на основе ограниченного опыта, и тяготеет к необоснованным утрвеждениям. Тем не менее, с нетерпением ждем второй части с нетрадиционной медициной ,)

Краткий персказ видоса:
1) вы проработали 20 лет в индустрии (это вы так говорите)
2) вы ни разу не сталкивались с энтерпрайзом (это понятно из того что вы предлагаете решения, которые уже 20 лет как внедренны в энтерпрайзах)
3) вы учите людей и ваши студенты факапят (по вашему утверждению)
4) пункты 2 и 3 не останвливают вас от давания советов
5) вы не очень-то и разобрались что такое микросервисы (почему-то СОА и микросервисы у вас рядом), не смотря на то что эта тема активно обсуждается последние несколько лет

Еще один момент на котором следует акцентировать внимание.
Изложенный ниже консерн решается давно и успешно, не следует сгущать краски

"
И последний аспект, вернее проблема, о которой я хотел бы сказать, — это объем данных. Вы просто должны понимать, что как бы я тут не упражнялся в красноречии, предрекая грядущий Апокалипсис, все это безобразие худо-бедно работает и справляется со своими обязанностями. Поэтому на сегодняшний момент нет (вернее не было) никаких поводов устраивать панику, если бы не этот аспект. Как видно по графику ниже, объем данных, хранимых в системах, экспоненциально возрастает и рано или поздно (скорее всего — рано) превысит возможности текущих монолитных приложений и реляционных баз, используемых как общее хранилище на множество модулей системы.
Приближая, естественно, момент апокалипсиса.
"

Упоминание концепции распределенных баз данных, дата лейк сделают Ваше следующую статью грамотней.
А так похоже на прогноз погоды ;)

Я думаю что автор явно не в теме настоящего ентрерпрайза
"
Более того, я часто люблю рассказывать такой пример. В США (вроде бы не самой отсталой стране мире, особенно в техническом плане) до сих пор все компании, связанные с телевизионным вещанием, синхронизируют свои программы передач с помощью выкачивания файлов (!) по FTP (!!!). Да-да, 4 Гб XML в архиве. Как вам такая интеграция? Самые дикие случаи я из уважения к бывшим клиентам (и из-за NDA) вам рассказать не могу. Но поверьте, там вообще на самом деле СТРАШНО. Просто В2В — это раз настроено и работает до конца века, это даже не пять лет.
"
Для затравки скажу что счас делаем миграцию с мейнфрейма на редшифт миграцию одного dataflow. Размер недельного архива > 100GB. И да интеграция in/out через FTP/S3. Что то придумали получше для терабайтных объемов ?

Да и насчет объема исходных кодов — аффтор ошибается.

Вынужден вас огорчить. Высшее руководство Enterprise-компаний вообще не имеет к миру IT в большинстве своем никакого отношения.

It depends. Если бизнес торгует данными (а таких все больше) то данный стейтмент не имеет смысла

PS. В целом энтерпрайз не так уж и страшен.

США как раз отстает как ни прискорбно во многих аспектах — например скорость и цена интернета с той же Кремниевой Долине. То, что это до сих пор работает не является показателем ничего кроме того, что людям приходится платить все больше и больше по обслуживанию технического долга.

Как скорость и цена интеренета коррелирует с техническим прогрессом или используемыми технологими ?
Дабы не плодить длинный тред, отмечу сразу — если инфраструктура и сервисы в клауде — то скорость интерета не важна.

Я привел один из кричащих примеров. Что я имею в виду — то, что пример США не надо принимать как правильный, может быть странам типа Украины как раз проще — у них можно сделать лучше потому что можно начать так сказать с чистого листа.

людям приходится платить все больше и больше по обслуживанию технического долга.

Так их устраивает платить, это просто строчка в бюджете.
но когда вместо 50 человек проект начинает поддерживать 200 внезапно может оказываеться что количество долга увеличивается быстрее чем раньше

И да интеграция in/out через FTP/S3. Что то придумали получше для терабайтных объемов ?

HTTP кроет FTP сейчас по всем нужным сейчас возможностям и при этом имеет ещё множество других, начиная со значительно легче прикручиваемого TLS. И таки да, и для терабайтных объёмов.

А для 100GB недельного архива вообще лучше масса других методов начиная с регулярного rsync — будет меньше необходимости качать всю неделю за раз.

Да и насчет объема исходных кодов — аффтор ошибается.

Это может быть.

PS. В целом энтерпрайз не так уж и страшен.

Да, он просто «ужас-ужас».

SFTP такой же ж стандарт как и HTTPS который в случае сабжевого применения ни с боку припёку в виду отсутствия необходимости множественного внешнего клиентского доступа.

Каким местом там вообще rsync который вообще не для этого с одной стороны а с другой точно так же ж никаким местом к тому же ж TLS уже вообще непонятно от слова вообще.

SFTP такой же ж стандарт как и HTTPS который в случае сабжевого применения ни с боку припёку в виду отсутствия необходимости множественного внешнего клиентского доступа.

1. Что Вы имели в виду под SFTP? Simple File Transfer Protocol? SSH File Transfer Protocol? Если речь про FTP+TLS, то его обычно называют FTPS.
2. У FTP[S] множество устарелостей в виде режимов, которые в мире 8-битности никому нафиг не нужны, отдельного соединения (проблемы с NAT), и т.п.
Чем Вам не подошёл HTTPS с готовыми модулями для файлового хранилища — не понимаю. Разве что опять же совместимость, но уже с опытом конкретного админа.

Каким местом там вообще rsync который вообще не для этого

Именно для этого: инкрементальная передача файла или дерева файлов. Если у вас нечто в виде лога, накапливающееся (в основном дописью, разве что заголовки правятся) в течение недели, лучше регулярно синхронизировать более мелкими порциями.
Вот если вы не можете представить передаваемое в таком виде (например, требуется финальный экспорт по итогам недели в упорядочённом и препарированном виде) — да, он не подходит. Хотя и тут иногда можно выкрутиться.

к тому же ж TLS уже вообще непонятно от слова вообще.

Что именно непонятно?

Я думаю что основная проблема ынтырпрайза (для нас девелоперов) в том, что IT это не основной бизнес — это cost center. Примерно как бухгалтерия или охрана. Оттуда все эти сроки, бюджеты, дедлайны, говноменеджеры, убогие технологии и далее по списку.

Точно. Не дай бог работать программистом в том же обычном банке в США. Индусы на визе, страшная текучка, и тупая-тупая работа.

Не хватает очень важного пункта — раздутого штата, когда над проектом работает 100 человек, из них человек 10-15 занимаются исключительно «менеджментом» остальных людей, хотя при правильном подходе и подборе хороших профессионалов зачастую можно обойтись 15-20 людьми и самоорганизацией команд.

А потом один из этих профессионалов увольняется)

Ну увольняется и что? Ищут нового, делов-то.

над проектом работает 100 человек, из них человек 10-15 занимаются исключительно «менеджментом» остальных людей

если всего 15 — это точно еще не энтерпрайз

Ну он же ж и сказал что реально же ж

можно обойтись 15-20 людьми

Остальные из 100 как раз и есть «из этих» даже если формально они «инженерАми» числятся... ))

я к тому, что в энтерпрайзе соотношение тех кто руками водит к тем кто руками что-то делает — часто 10 к 1

можно обойтись 15-20 людьми

Ну пусть будет «можно обойтись 5-10 людьми».

Это с точки зрения программистов руками делают только те, кто непосредственно программирует. Перекосы восприятия. На самом деле это не совсем так.
Я говорил про другое — существует такой эффект, что чем больше в компании людей, тем больше требуется людей. На каждую функцию выделяется отдельный человек на полный день. С менеджерами вообще беда зачастую. Там где есть задачи по менеджменту на 5-10 часов в неделю на команду из 5-7 людей садят отдельного человека на полный день и он, сознательный профессионал, начинает «менеджить» — нужно же работу свою выполнять. Гонять там программистов, придумывать новые методологии, репорты заставлять писать, работать над утилизацией времени программистов :)
Я вот встречал реальную ситуацию, когда команда саппорта старой версии одного продукта состоит из 4 человек и полновесного менеджера над ними. А то как же без менеджера? Они же не могут сами обработать репорты о багах и выкатить хотфикс.

Объемы же кода Enterprise-приложений примерно такие. Один модуль — 300-500 Мб исходников. Это модуль, который развивала на протяжении 10 лет команда из 3-5 разработчиков. Модулей таких — от полусотни до тысячи. То есть все приложение — это навскидку что-то порядка терабайт-десятков терабайт исходников.

Щито? терабайты исходников?.. Я помню как кто-то в торрентах выложил исходники windows 2000 — там было мегабайт 600 исходников, в любом случае меньше 1 гигабайта. Там тысячи человеко-лет работы.

Linux Kernel и тот кажется меньше 1 гигабайта... сколько тысяч человеко-лет работы там?..

Я думаю вы ошиблись примерно в тысячу раз. Один модуль в энтерпрайзе это что-то между 100к и 1млн строк кода.

Интересно будет почитать вторую часть...

А я вполне верю. Там много кода, который уже никто не знает что он делает и много сгенерированного. Туда попадают медиа файлы, вся череда разных уже скомпилированных предыдущих версий, короче если почистить то можно уменьшит в разы, но это никто не делает потому что смотри выше никто уже не знает что оно делает и лучше не трогать...

В классическом энтерпрайзе система в которой 5Гб кода-норма бытия. И это один какой то сервис, из сотен других

Под описанием проблем готов подписаться. Действительно если организация развивается, то ИТ структура с неизбежностью тоже развивается. И вот основной вопрос — есть ли стратегия развития организации и есть ли внутри нее стратегия развития ИТ. Если нет — отсюда вот то самое красивое слово — гетерогенность и связанные с ней проблемы. Причем не только на уровне кода, но и на уровне различных информационных систем/подсистем, использумых внутри организации.

«стратегія розвитку організації» — це, де-факто, минуле століття. Зараз за 10 років змінюється керівництво, виконавці, ринки, технології і т.д.

поэтому в «правильных» организациях стратегию пересматривают немного чаще :)

Проблема энтерпрайза — часто меняющиеся плохо сформулированные бизнестребования и сжатые сроки. Остальное вторично.

Проблема энтерпрайза — часто меняющиеся плохо сформулированные бизнестребования и сжатые сроки.

Это не проблема, это граничные условия задачи, данность фактически...

Проблема в том, что полностью сформулированные ваши бизнестребования и времени сколько «надо» => смерть в условиях рынка

График очень старый — за 2012 год, и показывает он прогноз

Один модуль — 300-500 Мб исходников. Это модуль, который развивала на протяжении 10 лет команда из 3-5 разработчиков.

То есть, это примерно 10Мб кода в год на одного разраба. Около 78 символов в минуту.

Вы не учитываете священный копипейст. Особенно в юнит тестах, где его иногда 80%, а самих тестов в 2 раза больше, чем того кода

Тогда любое число можно показывать, чтобы все еще больше ужасались.

вот поэтому я и не работаю на ентерпрайз

Ну кому-то же надо это делать?

ну, зарплаты та выше. Но если вас это не волнует.... :)

не знаю, не знаю, я бы не сказал что сильно отличаются

да ладно, мне кажется поддерживать это унылое не надо много ума, поэтому платят средне чтоб набрать средних людей и затыкать ими щели когда будет течь.

Подписаться на комментарии