У меня, наоборот, был отрицательный опыт пару лет назад.
Казалось бы, есть простая задача: hello world на Spring+CXF с конфигурацией в коде.
Открываем мануал: http://cxf.apache.org/docs/writing-a-service-with-spring.html
Читаем, понимаем, что там конфиг в xml.
Внизу приписка: For more information on using Spring… первая ссылка — полотно XML, вторая ссылка вообще битая.
Мучаем поисковик. Нам говорят, что нужен spring boot.
Я понимаю, что у меня будет не типовой конфиг и spring boot мне не нужен.
Да и вообще, отдельная библиотека просто для того, чтобы запустить hello world?
Я так и не нашел способа сделать это.
Возможно сейчас все поменялось и мне, наконец, покажут пример, который бы поместился в небольшой комментарий.
та же задача, но с использованием .net core для сравнения:
public class Startup {
public void Configure(IApplicationBuilder app) =>
app.Run(context => context.Response.WriteAsync("Hello world");
}
Вообще, если подумать, c# как раз таки больше подходит для систем обработки данных из-за более тонкого управления памятью (value type, указатели, ref return)
Был аналог — DryadLINQ.
Его уже не поддерживают, т.к. Hadoop начал поддерживать взаимодействия с другими языками и смысл пилить Dryad пропал, ибо малая популярность.
Так что проблемы сделать аналог нет.
Да и вообще, что именно в .net не позволяет завязываться на кластер?
Не знаком с SSIS, да и с Camel тоже. Насколько я понимаю это ETL инструменты. Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF, поэтому и нет проблемы.
Насчет "OSGI — это и есть микросервисы", тогда и WCF — это тоже микросервисы. Значит опять нет проблемы.
П.С.
maven все же не совсем аналог msbuild. скорее аналог Ant.
Или же maven аналог msbuild+nuget.
А знакомство с системами сборки вообще частенько выводит из себя :)
В maven'е куча плагинов, надо с каждым разбираться (прямо как webpack).
В .net core конфиги msbuild похудели, так что все не так уж и плохо.
Все дело в том, что значит "нормальная".
Когда я делал корпоративное ПО на java, я тоже так считал, но потом у меня появилась возможность сравнить.
В java нет такого понятия как сборка (Assembly — the smallest unit of versioning, security, deployment and reusability of code in .Net.)
Из этого маленького нюанса растут все различия в корпоративных фреймворках для .net и jvm.
Например, в .net не аналога Camel, не потому что он "не энтерпрайзный", а потому что нет самой проблемы которую он призван решить. Поэтому же нет прямого аналога OSGI. WCF+IOC+MQ-брокер + AppDomains, как изолированная среда, это примерный аналог.
Я не вижу такой технической проблемы в корпоративном ПО, которую невозможно/сложнее решать на .net, чем на java. Просто используется другой набор фреймворков, немного другие подходы.
Думаю посыл статьи в том, что с приходом .NETStandard 2 все это добро будет доступно на unix-системах, вот и получается прямая конкуренция.
А вот тут я с вами соглашусь.
Тем не менее, вы сами даете решения для монолита: stateless, липкие сессии, отдельный инстанс для задач по расписанию, распределенный кэш.
Хотя в этом случае задачи по расписанию можно выделить в отдельный микросервис, ибо ферма монолитов, будучи неправильно настроена, может конфликтовать пытаясь конкурентно выполнять эти задачи.
Получается, что микросервисы, в некоторых случаях, все же лучше чем монолит с состоянием.
Не если сравнивать с монолитом без состояния, увы, опять не вижу преимуществ.
А что именно в простаивающем приложении может потреблять ресурсы?
Мне приходит на ум только "лишние" модули/библиотеки загруженные в память. Но это ничтожно мало.
Вы утверждаете, что он, при низкой нагрузке, будет жрать больше ресурсов, чем система микросервисов.
"Размазывая" работу монолита по микросервисам вы не уменьшаете общую нагрузку.
Монолит не будет есть больше ресурсов только потому что он монолит.
Монолит потребляет столько же ресурсов, как и микросервисы при одинаковой нагрузке. Просто некоторые части из которых он сложен буду простаивать.
Так что никакого оверхеда нет.
Т.е. содержание облака с двумя микросервисами, которые получают 1000000 и 1000 запросов за день будет дешевле содержания облака с двумя монолитами, которые получают 500000 и 500 запросов за день?
Теперь понятно.
Однако хочу заметить что это не повышение производительности (скорее наоборот из за накладных расходов на сетевое взаимодействие), а снижение потребления памяти.
Я знаю, просто, когда вы начали говорить об органичности у меня немного "подгорело".
Страшно даже подумать, во что надо вляпаться, что сделать Spring'овский hello world асинхронным...
У меня, наоборот, был отрицательный опыт пару лет назад.
Казалось бы, есть простая задача: hello world на Spring+CXF с конфигурацией в коде.
Открываем мануал: http://cxf.apache.org/docs/writing-a-service-with-spring.html
Читаем, понимаем, что там конфиг в xml.
Внизу приписка: For more information on using Spring… первая ссылка — полотно XML, вторая ссылка вообще битая.
Мучаем поисковик. Нам говорят, что нужен spring boot.
Я понимаю, что у меня будет не типовой конфиг и spring boot мне не нужен.
Да и вообще, отдельная библиотека просто для того, чтобы запустить hello world?
Я так и не нашел способа сделать это.
Возможно сейчас все поменялось и мне, наконец, покажут пример, который бы поместился в небольшой комментарий.
та же задача, но с использованием .net core для сравнения:
Думаю речь одет о компиляторе в байт-код
Вообще, если подумать, c# как раз таки больше подходит для систем обработки данных из-за более тонкого управления памятью (value type, указатели, ref return)
Был аналог — DryadLINQ.
Его уже не поддерживают, т.к. Hadoop начал поддерживать взаимодействия с другими языками и смысл пилить Dryad пропал, ибо малая популярность.
Так что проблемы сделать аналог нет.
Да и вообще, что именно в .net не позволяет завязываться на кластер?
П.С. промахнулся с веткой
Не знаком с SSIS, да и с Camel тоже. Насколько я понимаю это ETL инструменты. Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF, поэтому и нет проблемы.
Насчет "OSGI — это и есть микросервисы", тогда и WCF — это тоже микросервисы. Значит опять нет проблемы.
П.С.
maven все же не совсем аналог msbuild. скорее аналог Ant.
Или же maven аналог msbuild+nuget.
А знакомство с системами сборки вообще частенько выводит из себя :)
В maven'е куча плагинов, надо с каждым разбираться (прямо как webpack).
В .net core конфиги msbuild похудели, так что все не так уж и плохо.
Все дело в том, что значит "нормальная".
Когда я делал корпоративное ПО на java, я тоже так считал, но потом у меня появилась возможность сравнить.
В java нет такого понятия как сборка (Assembly — the smallest unit of versioning, security, deployment and reusability of code in .Net.)
Из этого маленького нюанса растут все различия в корпоративных фреймворках для .net и jvm.
Например, в .net не аналога Camel, не потому что он "не энтерпрайзный", а потому что нет самой проблемы которую он призван решить. Поэтому же нет прямого аналога OSGI. WCF+IOC+MQ-брокер + AppDomains, как изолированная среда, это примерный аналог.
Я не вижу такой технической проблемы в корпоративном ПО, которую невозможно/сложнее решать на .net, чем на java. Просто используется другой набор фреймворков, немного другие подходы.
Думаю посыл статьи в том, что с приходом .NETStandard 2 все это добро будет доступно на unix-системах, вот и получается прямая конкуренция.
OSGI -> AppDomains
ESB -> WCF
Конечно они не идентичны, но решают похожие задачи
… которые тоже упали
А вот тут я с вами соглашусь.
Тем не менее, вы сами даете решения для монолита: stateless, липкие сессии, отдельный инстанс для задач по расписанию, распределенный кэш.
Хотя в этом случае задачи по расписанию можно выделить в отдельный микросервис, ибо ферма монолитов, будучи неправильно настроена, может конфликтовать пытаясь конкурентно выполнять эти задачи.
Получается, что микросервисы, в некоторых случаях, все же лучше чем монолит с состоянием.
Не если сравнивать с монолитом без состояния, увы, опять не вижу преимуществ.
В случае, если облачный провайдер взимает плату за трафик внутри кластера микросервисов, получается наоборот: монолит жрет меньше
А что именно в простаивающем приложении может потреблять ресурсы?
Мне приходит на ум только "лишние" модули/библиотеки загруженные в память. Но это ничтожно мало.
Вы утверждаете, что он, при низкой нагрузке, будет жрать больше ресурсов, чем система микросервисов.
"Размазывая" работу монолита по микросервисам вы не уменьшаете общую нагрузку.
Монолит не будет есть больше ресурсов только потому что он монолит.
Монолит потребляет столько же ресурсов, как и микросервисы при одинаковой нагрузке. Просто некоторые части из которых он сложен буду простаивать.
Так что никакого оверхеда нет.
Вместо консольного приложения под windows надо было сделать кроссплатформенный демон. Посмотрите в сторону Topshelf: Ссылка
Это довольно общие понятия. Можете пояснить конкретнее?
Т.е. содержание облака с двумя микросервисами, которые получают 1000000 и 1000 запросов за день будет дешевле содержания облака с двумя монолитами, которые получают 500000 и 500 запросов за день?
Дополню ваш комментарий Ссылка статьей
с разоблачением мифов относительно микросервисов.Вот именно.
Отсюда возникает логичный вопрос: откуда такая шумиха?
Теперь понятно.
Однако хочу заметить что это не повышение производительности (скорее наоборот из за накладных расходов на сетевое взаимодействие), а снижение потребления памяти.