Микросервисы - это не только про порядок в архитектуре (хотя и про это тоже), но и про надежность, гибкость и масштабируемость проекта.
Вот некоторые кейсы пользы микросервисов, выходящие за пределы просто архитектуры:
1) Допустим, мне нужно реализовать надежный, отказоустойчивый функционал для обработки данных, поступающих от партнеров. Я могу сделать отдельный сервис "приемник" который будет максимально легковесным и надежным, он будет ТОЛЬКО принимать данные и складывать их в очередь, благодаря чему партнеры смогут максимально быстро передавать нам данные почти мгновенно получая 200е коды и при этом у нас будут минимальные риски что в этом микросервисе что-то пойдет не так. А все риски и основную нагрузку будет брать на себя другой сервис, который будет эти данные обрабатывать в фоне. При этом, эта обработка никак не будет тормозить первый сервис, которым пользуются партнеры.
2) Допустим, среди доступного функционала у нас есть один наиболее ресурсозатратный флоу, дающий большую нагрузку на железо.
- В монолите, этот флоу всегда будет тормозить весь сервер, включая сервисы взаимодействующие с пользовательскими запросами. Даже если увеличить количество ресурсов, нагрузка от этого флоу всегда будет влиять на общее быстродействие системы.
- В микросервисной архитектуре, этот тяжелый флоу можно не только запускать на отдельных мощностях, но и масштабировать точечно только его. Просто статические буфера и прочий кэш заменяешь на межсервисную память типа redis и плодишь хоть 20 инстансов этого сервиса на отдельно выделенных ресурсах. При этом, сервисы для пользовательских запросов будут продолжать работать на отдельных мощностях и сайты/приложения для юзеров вообще никак не тормозятся в таком случае.
И это не какие то теоретические фантазии из области высоких материй, а реальные кейсы из личной практики, которые решают реальные проблемы на реальных проектах. При чем, это только первое что в голову пришло, продолжать можно долго при желании.
Статью можно брать в рамку и приводить как аргумент в пользу того, что питухон вызывает рак мозга, когда кто-то в интернете пытается защищать этот недоязык.
Фашизм - это деструктивный культ, основанный на диктатуре и тоталитаризме.
Смысл в том, что все это DEI движение тоже является деструктивным культом с делением людей на своих/несвоих, преследованием "неверных", культивацией ненависти к инакомыслию и прочими "прелестями" подобных сект. Хотя DEI по факту и не является буквально фашизмом, сравнение с фашизмом или религиозным фанатизмом тут вполне уместно.
Только смысл от нее есть только в очень редких специфических случаях, потому что повсеместное использование динамической типизации - прямой путь к бардаку и говнокоду.
Обучать сотрудников без опыта - это хорошее дело. Но если сотрудник не знает элементарных вещей и не умеет самостоятельно добывать информацию, то долгосрочные перспективы такого сотрудника вызывают некоторый скепсис.
А за вопросы, которые легко гуглятся вообще прописывать с ноги нужно (не в прямом смысле конечно, но все же).
Я лично всегда посылаю куда подальше с такими вопросами. Вопросы должны быть только касательно внутренней бизнес логики и архитектуры, то есть то, что в интернете просто так не гуглится.
Это вообще довольно распространенная проблема во многих it компаниях, когда во главе стоят НЕпрограммисты, особенно если они себя еще и умнее программистов считают. Суровая правда такова, что каждый конкретный разработчик индивидуален и оценить реальные способности конкретного программиста может ТОЛЬКО другой программист и только спустя 1-2 месяца совместной работы. Конечно, это никак не вяжется с мировоззрением "эффективных менеджеров" и "во всем правых начальников", которым удобнее оперировать какими-то метриками, фильтрами и ярлыками.
Полагаться при найме на наличие ВО - все равно что полагаться на карты таро. Не дает это 100% гарантии компетентности нанимаемого сотрудника. Как бы вам этого не хотелось.
Если программист на каждый свой пук в области оптимизации будет бежать на прод и мерить линейкой сколько процентов там чего увеличилось, то на эти замеры будет уходить больше времени чем на саму работу.
Так что пусть бестолковые HR засунут свои туториалы по написанию "правильных" резюме себе в стол.
Как уже написали выше, подобные инфоцыганские премчики могут быть плюсом в резюме менеджера по продажам, но не в резюме программиста.
Микросервисы - это не только про порядок в архитектуре (хотя и про это тоже), но и про надежность, гибкость и масштабируемость проекта.
Вот некоторые кейсы пользы микросервисов, выходящие за пределы просто архитектуры:
1) Допустим, мне нужно реализовать надежный, отказоустойчивый функционал для обработки данных, поступающих от партнеров. Я могу сделать отдельный сервис "приемник" который будет максимально легковесным и надежным, он будет ТОЛЬКО принимать данные и складывать их в очередь, благодаря чему партнеры смогут максимально быстро передавать нам данные почти мгновенно получая 200е коды и при этом у нас будут минимальные риски что в этом микросервисе что-то пойдет не так. А все риски и основную нагрузку будет брать на себя другой сервис, который будет эти данные обрабатывать в фоне. При этом, эта обработка никак не будет тормозить первый сервис, которым пользуются партнеры.
2) Допустим, среди доступного функционала у нас есть один наиболее ресурсозатратный флоу, дающий большую нагрузку на железо.
- В монолите, этот флоу всегда будет тормозить весь сервер, включая сервисы взаимодействующие с пользовательскими запросами. Даже если увеличить количество ресурсов, нагрузка от этого флоу всегда будет влиять на общее быстродействие системы.
- В микросервисной архитектуре, этот тяжелый флоу можно не только запускать на отдельных мощностях, но и масштабировать точечно только его. Просто статические буфера и прочий кэш заменяешь на межсервисную память типа redis и плодишь хоть 20 инстансов этого сервиса на отдельно выделенных ресурсах. При этом, сервисы для пользовательских запросов будут продолжать работать на отдельных мощностях и сайты/приложения для юзеров вообще никак не тормозятся в таком случае.
И это не какие то теоретические фантазии из области высоких материй, а реальные кейсы из личной практики, которые решают реальные проблемы на реальных проектах.
При чем, это только первое что в голову пришло, продолжать можно долго при желании.
Шедевр!
Статью можно брать в рамку и приводить как аргумент в пользу того, что питухон вызывает рак мозга, когда кто-то в интернете пытается защищать этот недоязык.
Спасибо, очень полезно(нет). Теперь ждём урок как включить комп для начинающих с домашним заданием.
Главное ссылку на телеграм оставить не забудьте.
Не вопрос, ждите ai резюме)
Миф 6 - «Архитектор должен писать код»Все что нужно знать о статье.
С таким же успехом, можно сказать что композитор не должен играть на инструменте, фитнес-тренер не должен иметь хорошую форму и т.д.
А что тогда архитектор должен? Широкими мазками обозначить: "эта штука делает то-то, а эта то-то и между ними ходят такие-то данные" ?
Это работа бизнес-аналитика, а не архитектора ПО.
Коротко о том, почему реально топовые программисты крайне редко меняют работу и никогда не контактируют с hr/рекрутерами
Фашизм - это деструктивный культ, основанный на диктатуре и тоталитаризме.
Смысл в том, что все это DEI движение тоже является деструктивным культом с делением людей на своих/несвоих, преследованием "неверных", культивацией ненависти к инакомыслию и прочими "прелестями" подобных сект. Хотя DEI по факту и не является буквально фашизмом, сравнение с фашизмом или религиозным фанатизмом тут вполне уместно.
Сегодня ведь сентябрь, а не 1 апреля?
Вы ведь не хотите сказать что это все серьезно?
Глупость. Игры, которые действительно пробивают потолок, можно пересчитать по пальцам.
В c# тоже есть динамическая типизация.
Только смысл от нее есть только в очень редких специфических случаях, потому что повсеместное использование динамической типизации - прямой путь к бардаку и говнокоду.
Ждём вопросы на stackoverflow:
"Посоветуйте расклад для оценки покрытия автотестов?"
"Что означает 9 кубков и Горящая башня в контексте проверки контракта API на возможность расширения в будущем?"
"Что можно оставить бесам в откуп на перекрестке, чтобы успешно закрывать задачи без дедлайнов?"
Спорное решение на мой взгляд.
Обучать сотрудников без опыта - это хорошее дело. Но если сотрудник не знает элементарных вещей и не умеет самостоятельно добывать информацию, то долгосрочные перспективы такого сотрудника вызывают некоторый скепсис.
А за вопросы, которые легко гуглятся вообще прописывать с ноги нужно (не в прямом смысле конечно, но все же).
Я лично всегда посылаю куда подальше с такими вопросами. Вопросы должны быть только касательно внутренней бизнес логики и архитектуры, то есть то, что в интернете просто так не гуглится.
Если новичок не может понять чем финтех отличается от геймдева и не знает аббревиатур БД, ПО, то тут вопрос к ответственным за найм.
КОГО вы вообще на работу взяли?
Чего молчим и минусуем?
Видимо, попадание было в самую точку)))
Это вообще довольно распространенная проблема во многих it компаниях, когда во главе стоят НЕпрограммисты, особенно если они себя еще и умнее программистов считают. Суровая правда такова, что каждый конкретный разработчик индивидуален и оценить реальные способности конкретного программиста может ТОЛЬКО другой программист и только спустя 1-2 месяца совместной работы. Конечно, это никак не вяжется с мировоззрением "эффективных менеджеров" и "во всем правых начальников", которым удобнее оперировать какими-то метриками, фильтрами и ярлыками.
Полагаться при найме на наличие ВО - все равно что полагаться на карты таро. Не дает это 100% гарантии компетентности нанимаемого сотрудника. Как бы вам этого не хотелось.
От куда такие выводы что именно некие "специалисты без ВО" виноваты в каких-то проблемах крупных компаний?
От куда такое предвзятое отношение?
Позвольте угадаю: вам за 40 и вы непрограммист.
Если программист на каждый свой пук в области оптимизации будет бежать на прод и мерить линейкой сколько процентов там чего увеличилось, то на эти замеры будет уходить больше времени чем на саму работу.
Так что пусть бестолковые HR засунут свои туториалы по написанию "правильных" резюме себе в стол.
Как уже написали выше, подобные инфоцыганские премчики могут быть плюсом в резюме менеджера по продажам, но не в резюме программиста.
Если инфоцыгане начинают агрессивно рекламировать продукт X, значит скорее всего с продуктом X что-то не так...
Автору советую идти делать уроки и не заниматься ерундой)
Если ваши тестовые задания может решить нейронка - значит у вас плохие тестовые задания.
В моем тестовом задании для трудоустройства нужно было написать asp net core mvc приложения с доской объявлений и системой авторизации.
Причем, объявления были с картинками, а система авторизации с ролями (админ и юзер).
Слабо сделать такое в chatgpt?)
Основной минус — слабая регуляция со стороны государства, что сказывается на качестве образовательных программ.Видать, опечатка закралась.
Вероятно, вы хотели написать "основной плюс". Хотя, даже независимость от государства не всегда является признаком качества.