дело в том, что это у тебя и получится микросервис. по работе с валютами.

не микросервис, просто сервис.

а то обмажутся экторами, а потом валюту во float хранят

ну да. я там поправился

по условию задачи у тебя ж источника данных два

источники - вопрос третий) у меня некоторые курсы по imap'у аще забирались)

ага, вон ещё 1 причастный пишет)

У меня это просто очередная классическая бессмысленная задача в универе - спарсить с центробанка курсы, оформить их в excel\csv, отдать клиенту файлик, примерно так (+ клиент еще может что-то класть сам). Хотелось попробовать сделать микросервисами, т.к. как еще учить себя чему-то новому, но раз бессмысленно - ок, благодарю за мнения.

Говнокод, в формачках Visual C++ наше все

Запятая лишняя, и восклицательный знак забыл

Говнокод, в формачках Visual C++ наше все

У нас тут это предполагается делать на C#, хотя там даже код почти писать не надо, все поднимается через всякие WCF и гуй

Ну и я про тоже, зачем вам микросервисы? Задача ж для универа

Хотя последнее тоже лишнее

микросервисы - это просто стильно, модно и молодёжно)

микросервисы - это просто стильно, модно и молодёжно)

микросервисы это просто распределенное приложение

микросервисы это просто распределенное приложение

в идеальном мире)

а тут распределять нечего

У нас тут это предполагается делать на C#, хотя там даже код почти писать не надо, все поднимается через всякие WCF и гуй

тебе следует забыть о микросервисах на ближайшие 5 лет

ну только если вдруг тебя занесет на проект в 50+ разработчиков которые уже это делают

лучше сосредоточиться и думать о великом (том что лежит в основе всего этого) - каплинги, кохижены, проектирование и тесты

тебе следует забыть о микросервисах на ближайшие 5 лет

Т.е. вы даже свои пет проекты или проекты средней сложности пилите в привычном монолите?

Т.е. вы даже свои пет проекты или проекты средней сложности пилите в привычном монолите?

ну слово "привычный" тут не к месту...

в копролите

я бы сказал.... "нормальный"

монолитный говнокод = копролит

ну то есть.... нормально спроектированный монолит в условиях проекта среднего и ниже не требует "распределенности"

микросервисы - не золотая пуля. а вопрос прозвучал как-то странно. Те, кто микросервисами не обмазывается - идиоты что ли?)

а если вдруг потребует - если все нормально спроектировано тебе не сильно сложно будет куски "скейлить" отдельно

чтобы юзать микросервисы - необходимо четко понимать зачем тебе именно микросервисная архитектура. Что даст. Микросервис ради микросервиса - это хрень

у нас crm на микросервисной архитектуре сделать решили

теперь мы постоянно испытываем много боли

главный вопрос - как ты готовишь монолит. Ибо если ты не умеешь их готовить - то с микросервисами ты заруинишь все еще быстрее

теперь мы постоянно испытываем много боли

потому что монолиты не умеете готовить?)

а если вдруг потребует - если все нормально спроектировано тебе не сильно сложно будет куски "скейлить" отдельно

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

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

ну таки да, первое правило распределенных приложений - не делать распределенных приложений пока можешь

потому что монолиты не умеете готовить?)

при чем тут монолит? у нас crm на микросервисах, не монолит

монолит до этого делали - и все замечательно работает

при чем тут монолит? у нас crm на микросервисах, не монолит

а в чем проблема? каплинг?

ну то есть, вот показательный пример разобрать можно)

главный вопрос - как ты готовишь монолит. Ибо если ты не умеешь их готовить - то с микросервисами ты заруинишь все еще быстрее

Я понял мысль, спасибо.

потому что монолиты не умеете готовить?)

По-моему микросервис это просто маленький монолит

По-моему микросервис это просто маленький монолит

поправка - много маленьких монолитов)

но вообще нет

это "монолит" компоненты которых можно независимо подменять

но вообще нет

Ну технически по-моему да

Ок, я если у меня часть приложения на одном языке написана, часть на другом (или переписана), это все еще считается монолит? С какого момента грань начинается?

это "монолит" компоненты которых можно независимо подменять

Дык и в обычном монолите можно. Просто интерфейсы, классы, DI = изи подмена

Ок, я если у меня часть приложения на одном языке написана, часть на другом (или переписана), это все еще считается монолит? С какого момента грань начинается?

С отдельного процесса

Можно ли использовать "микросервисы" для внедрения искуственных физических границ, чтобы снизить шанс случайного каплинга?

Ну технически по-моему да

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

Можно ли использовать "микросервисы" для внедрения искуственных физических границ, чтобы снизить шанс случайного каплинга?

Это как доставлять пиццу боингом по-моему

а вот писать монолит на разных языках - оно от этого микросервисами не станет

Дык и в обычном монолите можно. Просто интерфейсы, классы, DI = изи подмена

замени мне компонент системы на спринге в рантайме

Ну, большая команда, за всеми не уследишь, принудительно вводим boundaries. Не?

Можно ли использовать "микросервисы" для внедрения искуственных физических границ, чтобы снизить шанс случайного каплинга?

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

замени мне компонент системы на спринге в рантайме

Ггг)) там по-моему в NetflixOSS было что то про перезагрузку приложения без перезапуска jvm, но я бы не рискнул таким пользоваться)

Ну, большая команда, за всеми не уследишь, принудительно вводим boundaries. Не?

если ты не можешь за ними уследить - у тебя с микросервисами будет больше проблем ибо каплинг ты никуда не дел

Ггг)) там по-моему в NetflixOSS было что то про перезагрузку приложения без перезапуска jvm, но я бы не рискнул таким пользоваться)

ну я могу так на эрланге сделать)

а на джаве не могу

ну я могу так на эрланге сделать)

На эрланге все могут

Кто может в эрланг)

Т.е. вы даже свои пет проекты или проекты средней сложности пилите в привычном монолите?

https://i.pinimg.com/originals/60/6f/5f/606f5fdedb26758bb16877f2283f91b2.jpg Микросервисы по сути всем плохи - их сложно проектировать, сложно реализовывать, сложно деплоить, сложно поддерживать. Единственная причина, почему это вдруг стало мейнстримом - они решают одну-единственную проблему "масштабируемость". Пока нет проблемы с масштабируемостью - нет и смысла в микросервисах.

https://i.pinimg.com/originals/60/6f/5f/606f5fdedb26758bb16877f2283f91b2.jpg Микросервисы по сути всем плохи - их сложно проектировать, сложно реализовывать, сложно деплоить, сложно поддерживать. Единственная причина, почему это вдруг стало мейнстримом - они решают одну-единственную проблему "масштабируемость". Пока нет проблемы с масштабируемостью - нет и смысла в микросервисах.

Тру стори

Ок, я если у меня часть приложения на одном языке написана, часть на другом (или переписана), это все еще считается монолит? С какого момента грань начинается?

да, монолит или микросервисы определяются тем, что эти сервисы делают. Например если у тебя есть сервис "приложение" и сервисы "pdf-генератор", "socket-io сервер" и т.д. - то сам понимаешь что тут вопрос чисто реюза инфраструктуры

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

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

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

прояви фантазию) статический анализ)

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

Ну либо «как это заюзать, сукаблядь»)

что бы каплинга между подсистемами либо небыло либо через четко определенные интерфейсы все

прояви фантазию) статический анализ)

мы опять упираемся в "мы же взрослые люди" )

мы опять упираемся в "мы же взрослые люди" )

нет, мы упираемся в возможность проверки

ERROR: S client not available

именно этот аспект ты можешь проверить

нет, мы упираемся в возможность проверки

именно. поэтому первый послулат у меня был "за всеми не уследишь"

https://i.pinimg.com/originals/60/6f/5f/606f5fdedb26758bb16877f2283f91b2.jpg Микросервисы по сути всем плохи - их сложно проектировать, сложно реализовывать, сложно деплоить, сложно поддерживать. Единственная причина, почему это вдруг стало мейнстримом - они решают одну-единственную проблему "масштабируемость". Пока нет проблемы с масштабируемостью - нет и смысла в микросервисах.

если у кого-то возникают проблемы с МС. могу подарить книгу: https://leanpub.com/microservices-for-everyone Она отлично подходит для стартовой точки в начале пути по МС архитектуре.

именно. поэтому первый послулат у меня был "за всеми не уследишь"

как ты относишься к идее монорепозиториев?

именно. поэтому первый послулат у меня был "за всеми не уследишь"

Не тебе надо следить, а тулзе

если у кого-то возникают проблемы с МС. могу подарить книгу: https://leanpub.com/microservices-for-everyone Она отлично подходит для стартовой точки в начале пути по МС архитектуре.

там на первой странице "не надо!"?

С микросервисами тебе просто будет больнее... ииии всё

если у кого-то возникают проблемы с МС. могу подарить книгу: https://leanpub.com/microservices-for-everyone Она отлично подходит для стартовой точки в начале пути по МС архитектуре.

у тебя ж вроде как нет опыта в МС

или уже есть?

нету. но для начала пути

нету я про серьезный опыт

ну а не серьезный и не считается)

у тебя ж вроде как нет опыта в МС

Так там же все с просто, сам сказал, с первой страницы: не надо! Шикарный опыт!

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

блин я не помню кто такой Матиас

verraes.net?

вроде смотрел/читал чето от него но в упор не помню свое отношение к нему

блин я не помню кто такой Матиас

Год с симфони

не

верраса я уважаю

Matthias Noback

Год с симфони

а... пф... значит бесполезная книжка

Но у него блог неплохой имхо

А этот... ну он много контрибьютит в опенсоср PHP проекты :) все что знаю

зря я вбросил

через N лет дам фидбек. если доведётся поработать с МС архитектурой

Помню у него была либа для утиной типизации в пыхе) но не взлетела

как быстро темы меняются...

если у кого-то возникают проблемы с МС. могу подарить книгу: https://leanpub.com/microservices-for-everyone Она отлично подходит для стартовой точки в начале пути по МС архитектуре.

Ты файлик то скинь в лс?

Наброшу еще: если тебе нужна книжка про микросервисы значит тебе не нужны микросервисы. А когда будут действительно нужны, ты уже будешь понимать как их готовить.

Наброшу еще: если тебе нужна книжка про микросервисы значит тебе не нужны микросервисы. А когда будут действительно нужны, ты уже будешь понимать как их готовить.

...но уже будет пора умирать

...но уже будет пора умирать

PHP создан умирать...