LINUX.ORG.RU

Enterprise vs. non-enterprise

 ,


0

5

Всем привет. Как поживаешь, /development/ ЛОРа? Давно не писал, но мое внимание привлекла одна проблема (присущая, вообще говоря, не только ЛОРу, но на ЛОРе проявляющаяся ярче всего). Речь пойдет о пресловутом «enterprise» (иногда в юмористическом написании «enterpriZe», «ынтырпрайз» и так далее).

В том, что «enterprise» стал на ЛОРе эдаким жупелом, смоляным чучелом — ничего странного и страшного нет. У неспециалистов это слово в первую очередь ассоциируется с корпоративным, капиталистическим, пиджачно-галстучно-кофеварочным. А отрицание корпоративного — очень в духе современной молодежи, чей природный нонконформизм требует реализации. Но это не есть предмет сегодняшней беседы; оставим юношеский нонконформизм социологам и психологам.

Проблема в том, что сам технический термин «enterprise-технологии» часто трактуется неверно. Распространено множество дилетантских интерпретаций (например, «ынтерпрайз ≡ copy-paste» и так далее). Как человеку, не один десяток лет проведшему в пресловутом «enteprise», мне хотелось бы расставить точки над «i».

Итак, ПО и технологии уровня предприятия («enterprise software») характеризуются в первую очередь повышенными нефункциональными требованиями (non-functional requirements, NFR). Что это означает? NFR относятся к работе системы, а не к её специфическому поведению (которое описывается функциональными требованиями). Рассмотрим типичные NFR:

  • производительность (performance);
  • масштабируемость (scalability);
  • доступность (availability);
  • надежность (reliability);
  • безопасность (security);
  • расширяемость (extensibility);
  • управляемость кода (maintainability);
  • управляемость системы (manageability)

и так далее. По этим признакам определенные технологии и языки программирования могут быть отнесены к «enterprise» или «non-enterprise». Например:

  • Java-технологии специально разрабатывались как enterprise и максимально удовлетворяют перечисленным NFR;
  • у языка Си отличная производительность, но отсутствует ООП, отсюда проблемы с абстракциями, управляемостью и расширяемостью. Плюс прямая работа с памятью и проблемы безопасности;
  • C++ предоставляет ООП, но не решает проблем с безопасностью;
  • Python и Ruby обладают хорошим ООП, но, не имея качественных JIT-компиляторов, сильно проигрывают по производительности. См. историю с Твиттером и Ruby vs. Scala;
  • Haskell имеет немасштабирующийся GC; функциональный подход не дает таких возможностей для decoupling'а и модуляризации, как ООП. Следствие — неуправляемый и плохо расширяемый код;
  • Лиспы имеют целый букет проблем, начиная от производительности, проходя через масштабируемость и заканчивая управляемостью.

Разумеется, такое деление «enterprise / non-enterprise» в известной степени условно. Например, можно и на Java нагородить неуправляемой, немасштабируемой и дырявой лапши. С другой стороны, наверное, можно и в рамках лиспа придерживаться строгой модуляризации, а коммерческие реализации дадут хорошую производительность и масштабируемость. Однако, такой подход не принят в лисп-среде (там приняты шестиуровневые квазицитирования), и подобный код будет считаться «non-lispy crap».

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

С пламенным приветом,
ваш Кукинштейн

★★

Более подробно эту тему я собираюсь осветить в своем блоге.

Давай сразу расценки на курсы по Java, зачем SEO-нщину разводить.

anonymous ()

Еще интересная история с PHP. Формально, в последних версиях присутствует довольно неплохое ООП. Много лет существует PDO и аналоги prepared statements из JDBC. С использованием ускорителей типа Zend или Quercus можно добиться хорошей производительности. Есть многочисленные MVC-фреймворки.

Но почему-то все равно все пишут на PHP в процедурном стиле, смешивают в одном файле PHP+HTML+JS+CSS+SQL, а сами SQL-запросы формируют конкатенацией строк :-)

Kuka ★★ ()

производительность (performance)
надежность (reliability)
безопасность (security)
Java

Толсто

функциональный подход не дает таких возможностей для decoupling'а и модуляризации, как ООП. Следствие — неуправляемый и плохо расширяемый код

Еще толще

rand ()

Кука, ты, как Java-профессионал с десятилетиями стажа, работаешь в Лондоне или Нью-Йорке?

anonymous ()

Язабан этого энтерпрайзного уберменьша. Пусть у себя в бложеке словесный понос на тему ынтерпрайзности толкает.

anonymous ()

Выявленное противоречие автора самому себе

Например, можно и на Java нагородить неуправляемой, немасштабируемой и дырявой лапши.

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

Сравнивать JVM+JRE+Java+ServletConainer+AppServer со сферическим Лиспом или Си++ом неправильно. А корректного сравнения здесь не посторишь, т.к. нет ServlerContainer+AppServer на Си++е или Лиспе (пригодных для production).

Сравнивать же целиком весь стек веб-приложения JEE/Spring (например) vs Ruby-on-Rails можно, но я сильно сомневаюсь, что здесь будет чистая победа жабатехнологий по приведенному списку параметров.

metadeu5 ()
Ответ на: комментарий от Kuka

Но почему-то все равно все пишут на PHP в процедурном стиле, смешивают в одном файле PHP+HTML+JS+CSS+SQL, а сами SQL-запросы формируют конкатенацией строк :-)

Так и на жабе пишут лапшу в JSP до сих пор и борются за превосходство JdbcTemplate над ORM'ами.

metadeu5 ()

А что уважаемый Кука думает о месте Smalltalk в enterprise?

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от anonymous

Давай сразу расценки на курсы по Java

Вообще, я не занимаюсь общим преподаванием Java, только адресными консультациями. Зачем конкурировать с замечательным Oracle University? :) Расценки на курсы посмотрите на их сайте. Если вы все-таки хотите персональный курс в моем исполнении, и у вас есть конкретное бизнес-предложение — высылайте, контакты в профиле.

зачем SEO-нщину разводить.

Если вы обратили внимание, в тексте даже не было ссылки :) да и блог я только собираюсь запускать. Это был, скорее, анонс — для всех заинтересованных в теме. Чтобы следили за событиями.

Kuka ★★ ()
Ответ на: комментарий от rand

Толсто

Что не так? По поводу производительности — сходите на Shootout и удивитесь. На тему безопасности — рекомендую почитать о Java security model вообще, о JAAS, SecurityManager'ах, role propagation в EJB и так далее (а не только новости на ЛОРе о дырках в клиентской legacу-технологии aka Java Applets). И да, какие конкретно претензии к reliability?

Еще толще

Был бы рад увидеть аргументированный ответ, желательно с примерами, в которых Haskell показывает лучшую модуляризацию, lower coupling и higher cohesion, чем Java.

Kuka ★★ ()
Ответ на: комментарий от anonymous

Кука, ты, как Java-профессионал с десятилетиями стажа, работаешь в Лондоне или Нью-Йорке?

Вообще-то, я сейчас работаю в CERN, в Швейцарии. В Лондоне и Нью-Йорке бываю пару раз в год, консультирую по JavaEE. И еще много где бываю. АПВС?

Kuka ★★ ()

tl;dr Кука учит физиков JavaEE, пишет новую книгу и покупает новое озеро? Подпишусь.

anonymous ()

Ты опять вышел на связь?

anonymous ()
Ответ на: комментарий от metadeu5

эти NFR не являются в общем смысле требованиями к языку или платформе, а требованиями к общему комплексу средств применяемых для реализации системы.

Здесь у вас логическая ошибка. NFR являются требованиями как к языку или платформе, так и к общему комплексу средств. Например, чтобы обеспечить realtime-отклик, нужна как realtime JVM (напр., JRockit), так и realtime OS (напр., RedHat Enterprise MRG). При выпадении одного из звеньев разрушится вся цепочка.

Сравнивать JVM+JRE+Java+ServletConainer+AppServer со сферическим Лиспом или Си++ом неправильно.

Полностью согласен.

А корректного сравнения здесь не посторишь, т.к. нет ServlerContainer+AppServer на Си++е или Лиспе (пригодных для production).

Не согласен. Ведь можно сравнивать язык с языком, VM с VM, компилятор с компилятором, стандартную библиотеку со стандартной библиотекой.

В таком сравнении могут, например, участвовать:

  • производительность генерируемого маш. кода;
  • производительность стандартной библиотеки (I/O, контейнеры);
  • масштабируемость мусоросборщика;
  • качество абстракций, расширяемость и управляемость кода;
  • VM manageability (возможность мониторинга и управления VM).
Kuka ★★ ()
Ответ на: комментарий от metadeu5

Так и на жабе пишут лапшу в JSP до сих пор и борются за превосходство JdbcTemplate над ORM'ами.

Везде найдутся уродцы :) Для того, в частности, и нужны архитекторы/технологи, чтобы гарантировать качественную архитектуру и соблюдение технологий. А также давать по рукам буратинам с JDBC наперевес.

Kuka ★★ ()
Ответ на: комментарий от dave

А что уважаемый Кука думает о месте Smalltalk в enterprise?

У меня не было возможности детально ознакомиться со Smalltalk'ом и сопутствующими технологиями, поэтому воздержусь от вердиктов. Полагаю, там есть некоторые интересные идеи (message-passing OOП). Если бы передо мной стояла задача выявить место Smalltalk в enterprise, я бы стал смотреть в первую очередь на следующее:

  • runtime-среды, их качество, производительность, стабильность, коммерческая поддержка;
  • подходы к обеспечению модульности и изоляции кода (decoupling);
  • масштабируемость garbage collector'а;
  • принципы работы с реляционными СУБД;
  • серверы приложений, инструменты разработки, профилировки и отладки.

А какая информация есть у вас на эту тему?

Kuka ★★ ()
Ответ на: комментарий от anonymous

Кука учит физиков JavaEE

Вообще-то, в ЦЕРНе я занимаюсь фундаментальными исследованиями, а попутно — проблемами big data.

пишет новую книгу

Что за ерунда? У меня есть публикации в журналах, я собираюсь запускать блог, но на книгу как-то не замахиваюсь. Кто вам про такое сказал?

и покупает новое озеро?

Что-то часто у вас тут это озеро стало упоминаться, это какой-то новый мем? :) Надо почаще заходить на ЛОР.

Kuka ★★ ()

общеизвестный факт что если в названии продукта есть слово enterprise, то:

- нужно 3-5 иженеров разных вендоров, чтобы заставить этот качественный продукт работать

- низкая производительность (по сравнению с web scale) наблюдается на любом железе

- система описывается десятком книг и мануалов не менее 1000 страниц каждая

- программисты вендора не понимают, то что они наворотили за 3-5 лет. Очень много красивых классов и файлов конфигурации, которые делают бесполезную работу, навроде создать новый объект путём перепаковки другого объекта.

ihanick ()
Ответ на: комментарий от Kuka

не было возможности детально ознакомиться со Smalltalk'ом

Это значит, что Кука не знаком (или знаком по наслышке, «из статей с Хабра») с рефакторингом, юнит-тестированием и ООП в целом. Расходимся, коллеги. Беспонтовый тролль, я думал лучше будет.

anonymous ()

«enterprise» стал на ЛОРе эдаким жупелом, смоляным чучелом

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

Вот и весь секрет «жупела» и «чучела». :)

PS: Я сам-то фрилансер, есличо. Но в «энтепрайзе» 2.5 года успел повариться.

DeVliegendeHollander ★★ ()
Ответ на: комментарий от Kuka

А какая информация есть у вас на эту тему?

Мне показалось интересным такое решение как GemStone/S, но я о нем мало знаю. Думал, что у вас могла быть информация.

dave ★★★★★ ()
Ответ на: комментарий от Kuka

Надо почаще заходить на ЛОР

Лучше не отвлекайся от фундаментальных исследований UML и паттернов GoF.

anonymous ()

Haskell имеет немасштабирующийся GC;

В «enterprise» исключительно машины с > 12 ядер?

функциональный подход не дает таких возможностей для decoupling'а и модуляризации, как ООП

Ну-ка изобрази что-нибудь stm-подобное (в плане composability) на жаве, и чтобы из транзакций нельзя (компилятор не разрешит) было прожать I/O?

Глупый тролль, в общем, про хаскель ты зря написал.

anonymous ()

отсутствует ООП, отсюда проблемы с абстракциями

функциональный подход не дает таких возможностей для decoupling'а и модуляризации

расскажите подробнее, желательно, с небольшими примерами, пожалуйста

RedPossum ★★★★★ ()

функциональный подход не дает таких возможностей для decoupling'а и модуляризации, как ООП.

Ну это же ложь. Все с точностью до наоборот.

anonymous ()
Ответ на: комментарий от Kuka

Вообще-то, я сейчас работаю в CERN, в Швейцарии.

То есть вы учёный? Государственный служащий с небольшой зарплатой? Поэтому вы шабашите на стороне уроками по Java?

Почему бы с вашими-то талантами по Java не переехать в Нью-Йорк, заниматься любимым делом и получать очень солидное вознаграждение за это?

anonymous ()

Однако, такой подход не принят в лисп-среде (там приняты шестиуровневые квазицитирования), и подобный код будет считаться «non-lispy crap».

А в джаве приняты абстрактные фабрики абстрактных фабрик.

anonymous ()
Ответ на: комментарий от Kuka

Был бы рад увидеть аргументированный ответ, желательно с примерами, в которых Haskell показывает лучшую модуляризацию, lower coupling и higher cohesion, чем Java.

погоди, это же ты сказал, что в ФП с этим все плохо - вот и приведи, пожалуйста, примеры того, как джава показывает лучшую модуляризацию и т.д.

anonymous ()

Кстати, а где бложик-то? Я б подписалсо.

anonymous ()

Как долго такой развёрнутый вброс готовили?

dmfd ()

Python и Ruby обладают хорошим ООП, но, не имея качественных
JIT-компиляторов, сильно проигрывают по производительности.

PyPy уже давно работает и работает хорошо.

archimag ★★★ ()
Ответ на: комментарий от archimag

PyPy уже давно работает и работает хорошо.

И как себя с ним чувствуют Twisted, numpy, Zope, Plone, Django и т.п.? Какой прок от standalone интерпретатора?

anonymous ()
Ответ на: комментарий от Kuka

Здесь у вас логическая ошибка. NFR являются требованиями как к языку или платформе, так и к общему комплексу средств. Например, чтобы обеспечить realtime-отклик, нужна как realtime JVM (напр., JRockit), так и realtime OS (напр., RedHat Enterprise MRG). При выпадении одного из звеньев разрушится вся цепочка.

Вы искажаете мой посыл, на тот, который вам проще опровергнуть. Естественно, что требования к комплексу в целом подразумевают, что все его составляющие так же находятся в этих рамках. Я же говорил о другом — при проектировании веб-сервиса, например, никакой здравый человек не будет оперировать понятием скорости ВМ или операций сложения двух float'ов, его будут интересовать параметры его системы в целом — среднее время отдачи страницы, количество одновременных соединений и т.п.

Ведь можно сравнивать язык с языком, VM с VM, компилятор с компилятором, стандартную библиотеку со стандартной библиотекой.

Можно? Вы действительно хотите сравнить между собой компилятор Форта и Хаскелля между собой или ВМ Форта и JVM? Стандартную библиотеку Ruby и Си? Вы же понимаете, что в каждом подобном отдельном сравнении вся инфраструктура Джавы и в десятку финалистов не войдет?

metadeu5 ()
Ответ на: комментарий от anonymous

Какой прок от standalone интерпретатора?

До сих пор у меня были проблемы только с PIL, но это не критично для меня. Более существенными были проблемы с cx_oracle, но в итоге оказалось, что cx_oracle_on_ctypes работает отлично.

archimag ★★★ ()

С пламенным приветом,
ваш Кукинштейн

Из психушечки пишешь?

alienclaster ★★ ()

Haskell ...; функциональный подход не дает таких возможностей для decoupling'а и модуляризации, как ООП.

Кому не дает?

Следствие — неуправляемый и плохо расширяемый код;

Брехня

yoghurt ★★★★★ ()
Ответ на: комментарий от alienclaster

Специалист с 10-летним стажем: (рассуждения о точности терминологии, с определениями, примерами и сравнениями)
Лиспер: Из психушечки пишешь?

anonymous ()

Лор торт! Кука, анонимусы, лиспосрачь. Всё как в старые добрые времена

anonymous ()

слишком много семенов в одном треде. а где же автор?

rikardoac ()
Ответ на: комментарий от rikardoac

а где же автор?

Он обычно только поверхностно вбрасывает горы некомпетентности и тонны баззвордов (одних и тех же, уверен - копипаст) в пределах первых 2-х страниц.

alienclaster ★★ ()
Ответ на: комментарий от alienclaster

ага, значит один из анонимусов - автор. чудесно, больше мне знать и не надо.

rikardoac ()

Python и Ruby обладают хорошим ООП, но, не имея качественных JIT-компиляторов, сильно проигрывают по производительности.

Основная проблема скриптовых языков в энтерпрайзе вовсе не в этом, а в динамической типизации.

ovk48 ★★★ ()

Такой тред и без биореактора?

J ★★★★ ()

Во-первых в интерпрайзе не всегда завышенные NFR. Интерпрайз-интерпрайзу рознь. Во-вторых, почему для создания хайлоада, где еще суровее NFR, интерпрайза с глуькин нос?

dizza ★★★★★ ()

функциональный подход не дает таких возможностей для decoupling'а и модуляризации, как ООП.

ФП вообще ортогонально подходу к модуляризации. А вот ООП в задачах модуляризации в голом виде потерпело фиаско. А вот SOA рулит.

dizza ★★★★★ ()
Ответ на: комментарий от Kuka

Если вы обратили внимание, в тексте даже не было ссылки :) да и блог я только собираюсь запускать. Это был, скорее, анонс — для всех заинтересованных в теме. Чтобы следили за событиями.

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

ival ★★ ()
Ответ на: комментарий от ival

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

Плюсую.

Громко в смысле формулировок. Дешево в смысле аргументов.

ak377630 ()
Ответ на: комментарий от ihanick

общеизвестный факт что если в названии продукта есть слово enterprise, то...

...а если фраза начинается со слов «общеизвестный факт», то пишущий готовится впарить читателям откровенную ересь :) И к его вбросу надо относиться соответственно.

В данном случае пишущий знаком с «энтерпрайзом» исключительно по трепу ЛОРовских троллей. Потому что первая же пара попавшихся продуктов — JBoss, GlassFish — не оставляет камня на камня от его «общеизвестных фактов».

Kuka ★★ ()
Ответ на: комментарий от dave

Мне показалось интересным такое решение как GemStone/S, но я о нем мало знаю. Думал, что у вас могла быть информация.

Нет, мне не приходилось заниматься Smalltalk и GemStone/S на моей практике. Тут вам бы обратиться к yoghurt, кажется, он у нас одепт апологет адвокат евангелист специалист по Smalltalk и GemStone.

При беглом изучении темы мне сразу же резануло глаз то, что GemStone — изначально проприетарная объектно-ориентированная БД. Я бы в первую очередь выяснил, каким образом в GemStone/S организуется (если организуется вообще) работа с современными реляционными СУБД, а также некоторыми NoSQL БД. При всем уважении к ООБД я утверждаю, что универсальная информационная система сегодня невозможна без РСУБД. РСУБД — это все: годами отточенная высокая производительность, state-of-the-art планировщики, sharding, кластеризация, аналитика, наконец. С ООБД многое из этого придется велосипедить самостоятельно, if possible at all.

Kuka ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.