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