Comments 104
Касательно микросервисов небезызвестный Martin Fowler в статье MonolithFirst выразился так:
Т.е. если начинаешь проект сразу с микросервисов — получаешь проблемы.
Один из вариантов разработки — начать с малого количества «макросервисов», а затем их дробить по мере необходимости.
Правда, это было довольно давно (лето 2015 года).
Ну и у Райффайзенбанк есть статья здесь: Микросервисы делают мир проще (а вот и нет)
— Almost all the successful microservice stories have started with a monolith that got too big and was broken up
— Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious troubl.
Т.е. если начинаешь проект сразу с микросервисов — получаешь проблемы.
Один из вариантов разработки — начать с малого количества «макросервисов», а затем их дробить по мере необходимости.
Another route I've run into is to start with just a couple of coarse-grained services, larger than those you expect to end up with. Use these coarse-grained services to get used to working with multiple services, while enjoying the fact that such coarse granularity reduces the amount of inter-service refactoring you have to do. Then as boundaries stabilize, break down into finer-grained services.
Правда, это было довольно давно (лето 2015 года).
Ну и у Райффайзенбанк есть статья здесь: Микросервисы делают мир проще (а вот и нет)
Спасибо за ссылки, я тоже придерживаюсь принципе «сначала монолит» прежде всего потому, что угадать как именно надо будет разбивать с начала сложно и не нужно. А вот разбитое не в том месте потом сращивать может быть дорого.
Кроме того — вот мы мигрируем сейчас в облака систему, у которой в Back Office 300 (триста) таблиц, «сущностей» над этими таблицами под сотню, неужто мы должны сотню микросервисов сделать? «Монолит», очевидно, напрашивается.
Конечно, нужно сразу избавляться от взаимных зависимостей в коде, чтобы облегчить отстрел микросервисов по мере необходимости («But if you start with a monolith, the parts will become extremely tightly coupled to each other», ссылка). Согласен, OSGi — отличный способ для этого, по сути, «микросервисы».
Конечно, нужно сразу избавляться от взаимных зависимостей в коде, чтобы облегчить отстрел микросервисов по мере необходимости («But if you start with a monolith, the parts will become extremely tightly coupled to each other», ссылка). Согласен, OSGi — отличный способ для этого, по сути, «микросервисы».
Обычно всё же среди сотен сущностей относительно легко выделяются кластеры сильно связанных сущностей, при этом сами кластеры слабо связаны друг с другом.
Конкретный пример. Client не связан с Article, в рамках Back Office, все вместе это требуется при заказах и оплатах.
Делать четыре микросервиса:
— Client
— Article
— Order
— Payment
и еще к ним непонятное количество микросервисов, которые делают отчеты?
Мне пока видится, что нужны три монолита: BO (редактирование справочников), Sales (заказы, оплаты и проч.) и Reports.
Делать четыре микросервиса:
— Client
— Article
— Order
— Payment
и еще к ним непонятное количество микросервисов, которые делают отчеты?
Мне пока видится, что нужны три монолита: BO (редактирование справочников), Sales (заказы, оплаты и проч.) и Reports.
Микросервис per entity — как и практически любое архитектурное разделение per entity — плохая идея за редкими исключениями. Делите по бизнесу, по его процессам.
Часто встречаю такую тему, кстати, "у нас Х таблиц в базе, куда нам столько микросервисов", есть ощущение что это каргокульт: если у меня есть микросервис, скажем, форумного движка, то в нем очевидно окажется сущность Forum и называться он скорее всего будет ForumService. Но при этом в нем будут содержаться и темы, и модераторы, и комментарии, и спасибы, и прочие. Но со стороны все равно появится ощущение, что это сервис только форумов.
Вот ещё в копилочку — доклад по теме: «Микросервисы: размер имеет значение, даже если у вас Kubernetes», в нём как раз есть отсылки к Martin Fowler.
И если при проектировании системы в обозримой перспективе эти задачи перед вами не стоят, скорее всего, эта технология вам здесь и сейчас не нужна, какой бы прекрасной она при этом ни была.Полностью согласен и сам не раз сталкивался с такой проблемой. Люди пытаются вкрячить в свои процессы какую-то технологию, просто потому, что она на слуху и «все так пишут». Частный случай карго-культа.
Но вот что обязательно стоит учитывать при планировании своей системы, это возможность расширения или замены какой-то ее части в принципе. Иначе можно столкнуться с ситуацией, когда технология на старте отмечена как «когда-нибудь совсем нескоро», сегодня это «нескоро» наступило, но перейти на нее мы не можем, просто потому, что для этого придется переделывать проект с нуля.
UFO just landed and posted this here
Потому что гренка не может стоить 8 долларов, а croûton — может (с)
Ну, микросервисы обеспечивают бОльшую изоляцию контекстов друг от друга.
Вопрос в том, как степень изоляции действительно требуется и делать изоляцию больше чем требуется — это жечь деньги без пользы.
UFO just landed and posted this here
Как минимум, будут исключены возможности доступа к «чужим» данным не через публичный интерфейс.
*улыбающийся-терминатор-2.jpeg*
нет ничего невозможного для пыткого велосипедостроителя!
нет ничего невозможного для пыткого велосипедостроителя!
Ой ли? Там уже будет зависеть от ситуации.
У нас, к примеру, все микросервисы крутятся в openshift и настройку осуществляем тоже мы, через чарты.
Таким образом, при особом желании, можно скрестить несколько микросервисов и напрямую заставить их смотреть в одну базу, к примеру. Или смотреть в базы своих соседей. Особых трудностей сделать это нет.
Разумеется, так никто не делает, но сама возможность никуда не делась.
А про доступ через публичный интерфейс — ничего не мешает написать защищённый системный метод, который будет принимать в себя произвольный запрос и отдавать данные по этому запросу. Это будет лютая дырка в безопасности, но кто же помешает людям сделать именно так?
У нас, к примеру, все микросервисы крутятся в openshift и настройку осуществляем тоже мы, через чарты.
Таким образом, при особом желании, можно скрестить несколько микросервисов и напрямую заставить их смотреть в одну базу, к примеру. Или смотреть в базы своих соседей. Особых трудностей сделать это нет.
Разумеется, так никто не делает, но сама возможность никуда не делась.
А про доступ через публичный интерфейс — ничего не мешает написать защищённый системный метод, который будет принимать в себя произвольный запрос и отдавать данные по этому запросу. Это будет лютая дырка в безопасности, но кто же помешает людям сделать именно так?
Хнык хнык в этом месте. Мне как разработчику не микросервисов, но 1С очень очень не хватает промежуточной «package» видимости.
И вот уже появляется толпа методов в публичном интерфейсе нужных только для того, чтобы форма объекта могла со своим объектом пообщаться. Естественно вся эта толпа публичных, но по факту служебных процедур и функций никем не тестируется на некорректные входные параметры и тд. Так как разработчик знает, что вызывать этот публичный метод будет только он из одного единственного места.
(а когда при доработке другой программист попробует воспользоваться этим публичным методом, то огребет по полной — от неожиданных и плохо описанных структур в параметрах, до сайд эффектов, которые ему не нужны, но про которые он не знает)
И вот уже появляется толпа методов в публичном интерфейсе нужных только для того, чтобы форма объекта могла со своим объектом пообщаться. Естественно вся эта толпа публичных, но по факту служебных процедур и функций никем не тестируется на некорректные входные параметры и тд. Так как разработчик знает, что вызывать этот публичный метод будет только он из одного единственного места.
(а когда при доработке другой программист попробует воспользоваться этим публичным методом, то огребет по полной — от неожиданных и плохо описанных структур в параметрах, до сайд эффектов, которые ему не нужны, но про которые он не знает)
Как такой же фрагмент кода будет работать в реактивном стиле? Нить исполняет вычисления, посылает HTTP-запрос и вместо того чтобы заблокироваться и при получении результата синхронно обработать его, описывает код (оставляет callback) который должен быть исполнен в качестве реакции (отсюда слово реактивный) на результат. После этого нить продолжает работу, делая какие-то другие вычисления (может быть, как раз обрабатывая результаты других HTTP-запросов) без переключения контекста.
Это не реактивное, а асинхронное программирование на коллбеках. Хотя реактивные фреймворки зачастую имеют асинхронный реактор, но одной из фич реактивного программирования является как раз избегание коллбэков. Реактивное программирование — это прежде всего про потоки данных внутри системы и распространение изменений. Никаких отложенных вызовов не предполагается. За манифест спасибо, посмотрю.
«Хотя реактивные фреймворки зачастую имеют асинхронный реактор, но одной из фич реактивного программирования является как раз избегание коллбэков»
Откуда такое заключение? Если заглянем в wikipedia.org/Reactive_programming, то там написано: Update process: callbacks versus dataflow versus actors, то есть, никакой дискриминации колбэков. А если учесть, что callbacks, dataflow и actors — разновидности асинхронного вызова процедуры, то выбор конкретной разновидности определяется только удобством.
Откуда такое заключение? Если заглянем в wikipedia.org/Reactive_programming, то там написано: Update process: callbacks versus dataflow versus actors, то есть, никакой дискриминации колбэков. А если учесть, что callbacks, dataflow и actors — разновидности асинхронного вызова процедуры, то выбор конкретной разновидности определяется только удобством.
Вроде бы и да, но в этой статье я вижу другой смысл. В RP коллбеки очень тонкие и не порождают новые коллбеки (они могут, но это не идиоматично). Их задача — получить сообщение и послать его в граф. В статье описывается функция которая занимается вычислениями, выводом и вводом, хотя в RP все три части разделены.
Автор хотел на примере блокировки потоков показать крутость реактивного программирования, но показал крутость асинхронного (non-blocking) подхода.
Реактивное программирование по определению использует асинхронный подход, но нужно понимать что это абстракция более высокого порядка.
В том же .net есть старая парадигма APM когда вместо блокирующих методов создаются пары BeginXXX / EndXXX (в BeginXXX передается колбек, в котором нужно вызвать EndXXX который вернет результат или ошибку).
А реактивный это уже IObservable, и LINQ-подобные операции (Select/Where/Join/Aggregate) над источником событий. За счет того что это модель push (в нашу цепочку операторов событие пропихивается источником), а не pull (когда мы делаем условный вызов и ждем результат), модель неизбежно асинхронная.
Но опять же, важно доказывая вред блокирующего подхода противопоставлять ему не реактивный, а асинхронный
Реактивное программирование по определению использует асинхронный подход, но нужно понимать что это абстракция более высокого порядка.
В том же .net есть старая парадигма APM когда вместо блокирующих методов создаются пары BeginXXX / EndXXX (в BeginXXX передается колбек, в котором нужно вызвать EndXXX который вернет результат или ошибку).
А реактивный это уже IObservable, и LINQ-подобные операции (Select/Where/Join/Aggregate) над источником событий. За счет того что это модель push (в нашу цепочку операторов событие пропихивается источником), а не pull (когда мы делаем условный вызов и ждем результат), модель неизбежно асинхронная.
Но опять же, важно доказывая вред блокирующего подхода противопоставлять ему не реактивный, а асинхронный
Я взял цифры из исследования компании IBM, если не ошибаюсь, двухлетней давности. Кратко, если мы говорим о дисковых операциях, использовании процессора или доступе памяти, Docker почти не добавляет оверхеда (буквально доли процента), но если речь идет о network latency, задержки вполне ощутимы. Они не гигантские, но в зависимости от того, какое у вас приложение, могут вас неприятно удивить.
Есть один грязный лайфхак, который безумно очевиден и многие его практикуют. Просто не используйте докер сети, можно все в хостовой сети запустить. Они скорее всего вам не нужны, а оверхед от них приличный.
Спасибо за отличную статью!
UFO just landed and posted this here
идентичность среды для продакшна
Не является проблемой в java-разработке.
Удивительно, но еще как является
Я думаю сильно зависит от предметной области и того как написано приложение. При правильном подходе скорее не является, чем является, но предметная область, понятно может вносить коррективы.
Не является проблемой в java-разработке.
Разница даже в минорных версиях JRE уже может приводить к тому, что проблема в продакшене не будет воспроизводиться на дев.стенде.
Практически дюбой микросервис требует открытых портов (для Rest, http, socket), которые могут на проде быть заняты другими сервисами.
Редкое Java приложение вообще не использует внешних баз данных или систем кэширования, которые тоже нужно устанавливать и их версии и конфигурации могут отличаться.
Поэтому «идентичность среды для продакшна» хоть для Java, хоть для любого другого языка важна. Особенно понимаешь важность, когда на продакшен у разработчиков нет иного доступа кроме получения логов, а на тестовом сервере проблема вообще не воспроизводится.
Поднять аналог среды исполнения с помощью docker-compose, например, может сэкономить невероятное количество времени, особенно когда вводишь нового человека в проект.
Докер это не всегда iptables — ЕМНИП при каких-то конфигурациях сети данные качаются через container-shim и это довольно неэффективно — особенно на устройствах класса Raspberry Pi.
UFO just landed and posted this here
Данные с нескольких тасков можно собрать через CompletableFuture.allOf, Promise.all, Task.WhenAll и аналогичные API.
Нет это все одна статья, написана по мотивам разбора проблем. Одна из существенных проблем вызвана использованием реактивного программирования и главной из причин почему был использован реактивный фреймворк — было «мы хотим реактивную систему».
Статья строго по реалиям жизни.
Статья строго по реалиям жизни.
UFO just landed and posted this here
Нижняя строчка плохая не потому что красная, а потому что не работает как задумывалось. Обновить точечно ничего не получится по той же причине: пока есть блокирующие звенья, всё будет висеть на них и прироста не будет.
^ this!
UFO just landed and posted this here
UFO just landed and posted this here
Блокируются не таски, а потоки. До тех пор пока таск существует лишь в виде объекта и не занимает ни одного потока — никого не интересует чего он там ждет.
Я прощу прощения, если я отвечу немного в сторону. В статье я не рекомендую конкретный способ решения проблем, собственно про это можно было бы написать, но это тема для отдельной статьи.
Мое мнение, что играть в эти игры с перекидыванием задач между не блокирующимися потоками — довольно опасное занятие. Очень легко получить сложный, непредсказуемо работающий код.
Я бы решал задачу примерно так
1. обычные требования среднего веб приложения — вообще не использовать реактивный фреймворк, никакой пользы он не принесет. Те 5-10% процентов экономии которые он дает все равно «растворятся» в общих накладных расходах. Длинные, хорошо написанные, последовательные, блокирующиеся, императивные методы — что может быть лучше и понятнее?
2. Есть длинные задачи — использовать пул тредов и асинхронный запуск задач через org.springframework.scheduling.annotation.Async например. Тут все понятно и все это обычно умеют
3. если есть какие-то супер плотные, обоснованные бизнесом требования по использованию процессора — использовать например WebFlux — и изолировать его использование в отдельный, как можно более компактный сервис. Никаких жонглированием задачами между пулами внутри не делать — такой код относительно легко написать, но очень тяжело поддерживать.
Мое мнение, что играть в эти игры с перекидыванием задач между не блокирующимися потоками — довольно опасное занятие. Очень легко получить сложный, непредсказуемо работающий код.
Я бы решал задачу примерно так
1. обычные требования среднего веб приложения — вообще не использовать реактивный фреймворк, никакой пользы он не принесет. Те 5-10% процентов экономии которые он дает все равно «растворятся» в общих накладных расходах. Длинные, хорошо написанные, последовательные, блокирующиеся, императивные методы — что может быть лучше и понятнее?
2. Есть длинные задачи — использовать пул тредов и асинхронный запуск задач через org.springframework.scheduling.annotation.Async например. Тут все понятно и все это обычно умеют
3. если есть какие-то супер плотные, обоснованные бизнесом требования по использованию процессора — использовать например WebFlux — и изолировать его использование в отдельный, как можно более компактный сервис. Никаких жонглированием задачами между пулами внутри не делать — такой код относительно легко написать, но очень тяжело поддерживать.
UFO just landed and posted this here
Ну тут сложно сказать точную цифру, думаю сильно зависит от системы, процессора, версии Явы и т.п. я сделал примерную модельку — у меня получается, что для того, чтобы разница между реактивным и блокирующим подходом была заметна если принять, что переключение нитей 20мкс, надо чтобы весь цикл обработки запроса (от начала его чтения сервером) в среднем был не более 500 мкс.
Вторая часть, как по мне, водянистое «семь раз отмерь, один раз отрежь прежде чем гнаться за модой на „реактивное“ программирование». Которое к тому же не реактивное (= сверхбыстрое) а, скорее, реакционное.
«реактивный самолёт» — это не «сверхбыстрый самолёт», а самолёт на реактивной тяге
Хотел было возразить, что у нас не о самолётах речь, а разговорное речи «реактивный» используется как синоним «очень подвижный, энергичный, быстрый», но разговорный вариант во всех словарях, кроме арго, идёт в самом конце, а основные толкования близки по смыслу к использованию в программировании.
Был неправ.
Был неправ.
Если посмотреть на комментарии, то часть читателей ругается за пропаганду реактивного подхода, а часть за критику и не понимание.
При этом сам статья, про то, что можно и так и этак, главное осознавать к чему это ведет и какие плюсы и минусы.
При этом сам статья, про то, что можно и так и этак, главное осознавать к чему это ведет и какие плюсы и минусы.
UFO just landed and posted this here
К сожалению на работает так как вы хотите. Нельзя рецепт счастья написать для таких случаев. Слишком много разных критериев надо учитывать, от технических до совершенно субъективных. Мне казалось я написал в виде достаточном для того, чтобы дать дальнейший толчок мысли читателя. Но вот давать рецепт для общего случая — я считаю это не профессиональным.
Тем более что все быстро меняется и «твердые» рецепты быстро устаревают.
Тем более что все быстро меняется и «твердые» рецепты быстро устаревают.
В общем случае любое приложение, чувствительное к задержкам в сети в пределах до 250–500 мс, лучше не докеризировать.
Автор точно имеет в виду мс, а не мкс? +250 мс — это грандиозные задержки, особенно для микросервисных архитектур, где обычно реквест проходит несколько слоев обработки.
Да и на диаграмме над цитатой видно, что Docker добавляет средний оверхед при обработке сетевого пакета порядка 30 мкс, а не мс.
нахожу нечто мне интересное. а оно… докером. а я нехочу докером. у меня уже есть система, это моми проблемы, что я ее порушу. но я хочу на живое поставить, а не в докер. спрашиваешь — а как не в докере? ответ — да хз, ставь в докере. уроды, чесна.
Вот уроды, написали нечто интересное и не дают порушить систему!
знаете, я не из тех, которые делают по мануалу без думно. если я чтото делаю — я понимаю что я делаю. да и почему комуто должно быть какоето дело что я порушу СВОЮ систему.
знаете, я не из тех, которые делают по мануалу без думно. если я чтото делаю — я понимаю что я делаю. да и почему комуто должно быть какоето дело что я порушу СВОЮ систему
Потому что вы(не конкретно вы, а общно — пользователи) потом придёте к создателю этой приблуды и начнёте вопить, «а чего это вы мне всё сломали?!», «не работает ваша херня, а я так много сил потратил, скачивая её! Почините!».
Поэтому, чтобы большинство жило счастливо приходится ограничивать их, тем самым ограничивая и тех, кто способен сам разобраться и починить.
Откройте докерфайл и, грубо говоря, выполните в консоли все команды из него.
спрашиваешь — а как не в докере? ответ — да хз
А зачем разработчику париться и пооддерживать весь зоопарк операционок, их мажорных версий и программ, которые просто рядом стоят, но не дают поставить очередную зависимость, т.к. конфликтуют?
Зачем threads переводить как нити?
Сам удивляюсь, почему так переводят. Вообще стандарты перевода отдельная тема, больше всего меня удивляет Исаак Азимов ставшей Айзеком и spice melange ставшее спайсом.
После перевода не отдают на вычитку человеку в теме. Ну не знает переводчик про потоки и Азимова не читал. Досадные мелочи.
Сам спросил, сам ответил, сам молодец :)
Сам спросил, сам ответил, сам молодец :)
человек в теме это я, threads переводится как нити примерно с прошлого века.
Серьезно? А hyperthreading тогда как?
threads переводится как нити в контексте нить комментариев (в адаптации на русский «ветка»). Тред в каментах, нить разговора. Когда про программирование — thread это поток. Причем не тот который stream. А Айзек это все таки имя Исаак. Но раз уж сложилось исторически что стали произносить Айзек и в русском языке, отступать уже некуда. Хотя непонятно как Ньютон Исааком остался.
Как такой же фрагмент кода будет работать в реактивном стиле? Нить исполняет вычисления, посылает HTTP-запрос и вместо того чтобы заблокироваться и при получении результата синхронно обработать его, описывает код (оставляет callback) который должен быть исполнен в качестве реакции (отсюда слово реактивный) на результат. После этого нить продолжает работу, делая какие-то другие вычисления (может быть, как раз обрабатывая результаты других HTTP-запросов) без переключения контекста.
Основное преимущество здесь — отсутствие переключения контекста
Это фантастика какая-то. Какой-то поток все равно должен заблокироваться во время IO и ждать результат. Если это не тот же самый поток, произойдет точно такое же переключение контекста. Чтобы переключения не было, блокироваться и выполнять callback должен тот же поток, а в этом смысла нет в данном случае.
Просто таски в Rx* выполняются на планировщиках, но переключение контекста с ними такое же реальное, как и при любом другом подходе.
Посмотрите на пакет docs.oracle.com/javase/8/docs/api/java/nio/package-summary.html и саб пакеты он как раз про неблокирующее чтение
Тут имелось в виду, что если есть две задачи, выполняющиеся параллельно — то один поток может начать выполнять первую, отправить http-запрос, а потом без переключения контекста начать выполнять вторую и отправить второй http-запрос.
А потом поток заблокируется и будет ждать прихода http-ответов. И обработает их точно так же подряд, и всё это без переключений контекста, если всё это каким-то чудом в квант времени уложится.
А потом поток заблокируется и будет ждать прихода http-ответов. И обработает их точно так же подряд, и всё это без переключений контекста, если всё это каким-то чудом в квант времени уложится.
Ок, понятно что имелось в виду, согласен.
Но опять же, реактивное программирование здесь не при чем.
Такое поведение достигается за счет планировщика с 2+ тредами, но не за счет «реактивности». Можно сделать то же самое, используя, например, обычный ExecutorService в Java.
Поэтому «отсутствие переключения контекста» — никак не основное преимущество RP.
Но опять же, реактивное программирование здесь не при чем.
Такое поведение достигается за счет планировщика с 2+ тредами, но не за счет «реактивности». Можно сделать то же самое, используя, например, обычный ExecutorService в Java.
Поэтому «отсутствие переключения контекста» — никак не основное преимущество RP.
А второй-то тред зачем тут нужен?
Чтобы на одном из них был блокирующий IO, а на другом гонялись в это время любые другие таски
Блокирующего IO вообще не должно быть.
:)
Мы обсуждаем пример из статьи, а не спорим как должно быть
Мы обсуждаем пример из статьи, а не спорим как должно быть
Ну так читайте статью дальше примера-то!
Далеко не все операции ввода-вывода поддерживают неблокирующие вызовы. Например, JDBC на текущий момент не поддерживает (в этом направлении идут работы см. ADA, R2DBC, но пока все это не вышло на уровень релиза). Поскольку сейчас 90 % всех приложений ходят к базам данных, использование реактивного фреймворка автоматически из достоинства превращается в недостаток. Для такой ситуации есть решение — обрабатывать HTTP-вызовы в одном пуле потоков, а обращения к базе данных в другом пуле потоков. Но при этом процесс значительно усложняется, и без острой необходимости я бы так делать не стал.
А если транзакции нужны, в микросервисах, что делать будешь? Лепить распределенные транзакции?
Hypervisor->guest->docker->jvm->app, и вся идея выбросить докер и потерять в удобстве деплоя. А почему не выбросить JVM? Нельзя, мы на ней пишем. А гипервизор? Тоже нельзя, нам так удобнее в амазоне покупать инстансы. А докер — это проблема админов, его выкинем.
Сеть докера работает на linux bridge, это вносит задержку, но она незначительна и измеряется микросекундами. Если задержка критически важна, что 30-50мкс (тут выше путались, так что поясню — это микросекунды, это в тысячу раз меньше миллисекунд) это значительно — выкинуть нужно сначала JVM.
Сеть докера работает на linux bridge, это вносит задержку, но она незначительна и измеряется микросекундами. Если задержка критически важна, что 30-50мкс (тут выше путались, так что поясню — это микросекунды, это в тысячу раз меньше миллисекунд) это значительно — выкинуть нужно сначала JVM.
Выкинуть JVM идея хорошая, но без нее к сожалению программа не работает. Вообще. Никак. Так что выкручиваемся как можем.
Ну а без докера не работают контейнеры, но его почему-то предлагают выкинуть. Я к тому, что оптимизировать нужно самую тяжелую часть, а она в такой ситуации как правило — JVM. Выкидывание контейнера добавит проблем к масштабируемости, стоимости администрирования и позволит увеличить хорошо если на 1% отзывчивость. Вот на графике, который привел автор видно, что докер добавляет 0.030мс к времени обработки, а автор рассуждает о приложениях, для которых критично время 250 и больше мс.
Я отказываюсь понимать пользу оптимизации в 0.012% за счет отказа простоты деплоя.
Я отказываюсь понимать пользу оптимизации в 0.012% за счет отказа простоты деплоя.
Я вас собственно не заставляю — если вам так удобнее для вас все работает — нет вопросов. Судя по комментариями — для кого-то это имеет смысл, пусть они мучаются без докера, а вы будете им наслаждаться.
Я всегда за оптимизацию (если она не преждевременна, конечно).
Но выкидывать докер из JVM приложения — это как лечить перелом позвоночника прикладыванием подорожника. Мне по долгу службы приходится порой считать и байты, и такты, поэтому тешу себя мыслью, что немного понимаю в оптимизацию. Так, вот по моему опыту (который предельно согласуется с вашим графиком от IBM, кстати сказать) — главное, что можно выкинуть из JVM приложения — это JVM.
Не подумайте, я не противник java, но если вы доходите в оптимизации до того, что вам мешает докер, а главная ваша претензия к скорости работы linux bridge — явой тут должно не то что не пахнуть — у разработчиков даже мылей таких в голове быть не должно. Это совершенно разные порядки времени обработки данных.
А если рассматривать проблему не как «Давайте выкинем докер?», а как «А нам точно нужно вводить этот модный докер в стек? Зачем?»?
И насчёт админов: в своё время инициировал введение докера в стек как раз чтобы не выяснять лишний раз где проблема админов, а где разработчиков. С докером очень удачно рутинные обязанности по эксплуатации разделились: админы отвечают за работоспособность кластеров, за мониторинг и т. п., а разработчики обеспечивают работоспособные контейнеры и «скелет» конфигурации оркестратора. При возникновении проблем очень быстро либо выясняется кто и где накосячил, либо приходит понимание, что тут нужно вместе садиться и вырабатывать общее решение. «отфутболивание» практически прекратилось. Причём админы сначала возражали против докера, а потом им схема работы (именно организационная) понравилась.
И насчёт админов: в своё время инициировал введение докера в стек как раз чтобы не выяснять лишний раз где проблема админов, а где разработчиков. С докером очень удачно рутинные обязанности по эксплуатации разделились: админы отвечают за работоспособность кластеров, за мониторинг и т. п., а разработчики обеспечивают работоспособные контейнеры и «скелет» конфигурации оркестратора. При возникновении проблем очень быстро либо выясняется кто и где накосячил, либо приходит понимание, что тут нужно вместе садиться и вырабатывать общее решение. «отфутболивание» практически прекратилось. Причём админы сначала возражали против докера, а потом им схема работы (именно организационная) понравилась.
Впервые за несколько лет увидел адекватную оценку этих техник. Сам понимал всегда что в большинстве проектов они не нужны, и вот в этой статье нашёл подтверждение своему мнению, разложенное по полочкам. Искренне сочувствую тем, кто внедрил в своих проектах не решение конкретных проблем, а модную штуку, которая сделала проект хуже, зато добавила крутую строчку в резюме программиста.
Не хочу сказать, что эти техники плохи, просто не надо возить уголь автобусами — они хоть и вместительные и грузоподъемные, но всё же неудобно как-то…
У меня мнение скорее такое: во многих проектах новые техники добавят плюсов, но принесут и минусы, а итоговый баланс плюсов и минусов сильно зависит от проекта, от команд над ним работающих, от сроков и бюджетов проекта. Даже идеальное техническое решение может оказаться экономически невыгодным в случае если команды в первый раз о нём слышат, их надо обучать, их надо мотивировать быстро обучаться, а проект короткий с весьма ограниченным бюджетом.
То есть, всякие консультанты, чтобы напаривать свои никому не нужные услуги, решили вместо слова "асинхронный" написать слово "реактивной"?
Вот что за бред?
реактивный у меня ассоциируется с реактом на который у меня аллергия :D, а вот асинхронная архитектура у меня активно используется с rabbitmq кроме асинхронности это всё ещё позволяет не терять сообщения если чтото пошло не так, одно не удобно что система становиться не очень прозрачной, а для некоторых такой подход вообще не приемлем, коллеги из соседней страны сказали что им нужно всё синхронно, так как это понятно О.о
На счёт зависимостей и ящика пива звучит странно. Библиотека добавляет немного времени запуску приложения, но в большинстве случаев это не очень критично. Если изобретать свои велосипеды, то их необходимо поддерживать команде, а в случае библиотеки ее поддерживает сторонний разработчик.
Поддержка сторонним разработчиком это не всегда плюс увы. Но основная проблема с библиотеками они очень редко делают _ровно_ то что вам надо и _ровно_ так как вам надо. И вы вынужденны втаскивать в абстракцию своей системы абстракцию библиотеки. Если вы из нее используете один статичный метод UtilClass.doSomething() — это не проблема, но так бывает редко.
По поводу времени запуска — смешно совпало — буквально сегодня у меня был достаточно жаркий спор как раз про время запуска. Коллега жаловался на слишком долгий старт.
По поводу времени запуска — смешно совпало — буквально сегодня у меня был достаточно жаркий спор как раз про время запуска. Коллега жаловался на слишком долгий старт.
Как раз любуюсь муками горе-разработчиков, наплодивших инфраструктурных сущностей и вместе с этим лишних забот и ограничений в проект. Нужен тренд антихайпа в индустрии!
Sign up to leave a comment.
Всегда ли нужны Docker, микросервисы и реактивное программирование?