Size: a a a

Software Design/Architecture/Zen

2021 May 21

SP

Sergey Protko in Software Design/Architecture/Zen
ждем и надеемся что распадется это все на сервисы да на липовый мед
источник

k

knopkod4v in Software Design/Architecture/Zen
а липовый мёд коричневый?
источник

K

Konstantin in Software Design/Architecture/Zen
А какая разница, если сладенько? Вон ириски тоже цвета непонятного, но зубы выдирают на ура
источник

k

knopkod4v in Software Design/Architecture/Zen
главное шоб не показалось)
источник

K

Konstantin in Software Design/Architecture/Zen
Тут уже вопрос перспективы, если как говорится, тебе так кажется, то вполне возможно что это субъективно, если двоим так кажется, вполне возможно объективно, если 3м то уж точно так и есть
источник

k

knopkod4v in Software Design/Architecture/Zen
вообще я пока не убеждён в верности этой логики
ну то есть можно ли этого достичь без микросервисов?
Это же вообще не совсем технические моменты, а не знаю - дисциплина в разработке?
источник

k

knopkod4v in Software Design/Architecture/Zen
за теми же контрактами всё равно следить надо, шо так шо этак.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
представь ситуацию что у тебя за каждый "модуль" отвечает отдельная команда. И допустим вы добились того что у вас нарушать границы никак нельзя, на CI как-то отловте. И тестами все покрыто и каждый коммит в мастере можно в любой момент выкатить в прод. Легко такое сделать? И да, есть продукты где именно так так что все возможно
источник

k

knopkod4v in Software Design/Architecture/Zen
думаю нелегко.
Тогда вопрос в том - легче ли это сделать с микросервисами? Не меняешь ли ты тут одни проблемы на другие?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
а если "не каждый коммит" то уже начинаются нюансы, координация деплоев, сложный CAB процесс (change advisory board), оверхэды на комуникации и люди думают "ой блин короч проще будет подождать неделю и со всеми выкатиться".
источник

SP

Sergey Protko in Software Design/Architecture/Zen
а там где "через неделю выкатить" там и "выкатиться больше и больше вероятность что что-то пойдет не так и хуй пойми что пойдет не так" - не завидую онкол инженерам
источник

K

Konstantin in Software Design/Architecture/Zen
👆🏻👆🏻👆🏻 фантомные боли, я же теперь спать не буду. Не сыпь мне соль на ранууууу (с)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
меняешь конечно, вопрос какие боли тебе дешевле
источник

SP

Sergey Protko in Software Design/Architecture/Zen
держать команду опсов которая тебе инфраструктуру для всего этого цирка супортит может быть сиииильно дешевле чем вся эта бюрократия и пиздец для команд.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну то есть микросервисы это долго дорого и больно
источник

SP

Sergey Protko in Software Design/Architecture/Zen
потому рассматривать это стоит как решение когда у тебя уже долго дорого и больно. Что бы новые боли были другими и их было меньше
источник

k

knopkod4v in Software Design/Architecture/Zen
у нас 1 парт-тайм чувак есть... Но это неточно, я его никогда не видел :D
источник

SP

Sergey Protko in Software Design/Architecture/Zen
в целом как говорил Ньюман - микросервисы отличное решение но стоит к нему прибегать когда вы уже другие рассмотрели
источник

SP

Sergey Protko in Software Design/Architecture/Zen
скажем если у вас пиздец с комуникациями между командами или продукты хуйню творят - то микросервисы сделают все только хуже)
источник

k

knopkod4v in Software Design/Architecture/Zen
"Honestly, microservices seem
like a terrible idea, except for all the good stuff."
источник