Чему я научился за 30 лет работы программистом
ฝัง
- เผยแพร่เมื่อ 29 ก.ย. 2024
- Сегодня на примере монолита и микросервисов поговорим о том, что является самым важным в программировании.
Поддержать меня: boosty.to/mflenov
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.info
Мой просто блог blo.moe
Twitter: / flenov
Инстаграм: / mflenov
Телеграм: t.me/mflenov
Выходить из vim….)))
Научился, но это не самое важное из того, что я узнал
@@programisli очень некрасиво поступаете, вас просят совета, а вы просто "забили болт", проигнорив . Надеюсь вам это все вернется и люди будут к вам также относиться
Юмор для юниоров:)
Некоторых в настоящее время при слове "монолит" просто вводит ступор и ты в их глазах становишься самым непонимающим айтишником на самом низу эволюции) Мне нередко приходилось встречать такую реакцию людей на собеседованиях и на местах работы. Более свойственно это молодым людям, которые привыкли гнаться за модой и модными течениями, пытаясь все в мире перевести на эти новые рельсы, это лишь показывает их малый опыт в мире IT. Я встречал сеньоров, которые становились сеньорами в 23, и мидлов которым было под или за 50, при этом они работали в одной конторе, и имели за плечами разницу в опыте измеряющуюся в десятках лет) Первые просто угодили своей конторе, а вторые работали в соответствии с совсем другой философией) Все относительно как говорится.
Хорошо что я посмотрел это видео, так как в нем именно это еще раз подтверждается и я теперь не буду себя чувствовать неуверенно при разговорах о монолите и его праву на существование в современном мире.
Новые рельсы это хорошо, если они производительные
А ещё git не нужен, даёшь папочки с датой)
@@НикН-о7о ага шутник, пока вы пытаетесь рефакторить, везде пихая DI, выбирая лучшую структуру проекта, постоянно переделывая ее, делаете избыточные реализации типа закладывая код под масштабируемость в будущем, которая никогда скорее всего на проекте не наступит, тратя кучу времени и делая проект дороже, мы уже давно запиливаем процесс и запускаем его в прод.
@@НикН-о7о не, ну не))
Ну фиг знает. Монолит монолиту рознь. Иногда очень классно раскидать распределение задач по разным ПК. Да и машиабируемость, да и вообще допиливать легче. Это на мой взгляд
Забавно. Задавали ли я вопрос Why? Не часто, но задавал. Обычно ответом было - потому что так. И все. Я исхожу из одной простой мысли данной мне моим первым и наверно одним из лучших в моей жизни начальником еще в советском НИИ - лучшее враг хорошего. Ничего не надо улучшать, если оно и так работает. Я нажимаю кнопки с 1986 года, хотя и не все это время подряд. В 1992-94 работал дальнобойщиком, потом настраивал пневматические системы. Веселое время было, но в 1997 все же вернулся в программизм и уже в 1999 получил работу в США. Так что что в программизме самое важное, вопрос наверно открытый. На мой взгляд после примерно того же 30 летнего опыта (хотя с алголом я познакомился еще в школе в далеком 1979 году) ответ достаточно прост, хотя и другой - чем меньше ты нажимаешь кнопок, тем лучше для тебя и твоего продукта.
Согласен с автором. Мне лично тоже запомнился случай, когда мой начальник снаряжал сервачок в какой-то технологический цех еще на 2000 винде и тамошний начальник айти завел речь, что надо бы автоматические обновления, антивирусы подрубить, на что начальник так же ответил: нафига? Сервак стоит, собирает свои данные с датчиков, в него никто не лезет, и так и будет работать годами. Поставь автообновления и начнется: то то не так, то это не так, здесь перезагрузитесь, здесь переустановите.
А потом довелось немного коснуться японского айти, там вообще могут работать на доисторическом или самопальном софте и не париться как у нас: ах ох, надо срочно обновляться!
То, с чего следует начинать всем - монолит, его хватит условным 80% по принципу Парето, а на время выхода на IPO хватит всем.
Золотая середина - это SOA, но не микросервисы.
Микросервисы - это удел единиц, но это модно, поэтому они везде.
Михаил, большое спасибо за видео и личный опыт!
Хотелось бы также услышать Ваше мнение насчет ChatGPT и страшилок, что скоро developers, technical support engineers, QA engineers могут быть заменены искусственным интеллектом. Спасибо
Думаю над этим
Очень крутое видео! Можете рассказать любопытному фронтендеру возможна ли такая нагрузка при которой понадобятся микросервисы или это нужно только для организационных вопросов в больших командах?
Нагрузка и микросервисы не связаны. Stackoverflow как раз доказательство того, что очень большую нагрузку можно обрабатывать монолитом.
А мы с коллегами второй месяц уже Apache nifi в кубер пытается запихнуть, а что поделать, а что поделать, никакого монолита))
Крутой дядька) Сам фронтом интересуюсь. Но когда смотрю про бэк ребят, то понимаю какие они лютые) И, наверное, понимаю, почему ребята из бэка не считают фронтменов за прогеров)
А я не знаю, почему фронтов не считают за программистов. React и Angular достаточно серьезные фреймворки
Пускай для начала ребята из бэка напишут правильно по архитектуре фронт, а потом раскидываются такими заявлениями
@@ShoxaKardashian 🤣🤣🤣🤣
@@programisli а extjs как? есть спрос?
Я ангулярщик. Было два проекта, в которых главным был джавист. Джавист выбрал Ануляр для фронта. Но только потому, что Ангуляр внешне похож на джаву. Он говорит, как надо делать (исходя из своих джавистых скиллов), но получается не очень. Но виноват - я. Вот так. Будьте бдительны! Фроненд - это не только div+div+div+display:flex;
А с кофе прикольно получилось то!) Буква "Р" такая картавая, акцент американский будто))
монолиты дорого масштабировать, по этому все сразу делают микросервисы
Почему монолиты дорого масштабировать?
@@programisli потому что часто нужно отскейлить отдельный кусочек, бывает даже сотнями инстансов, если делать 100 копий монолиотов то это по ресурсам серверов накладно(Дорого). Еще надо помнить что ошибка в монолите приводит к краху всего приложения, в то время как в микросервисах упадет лишь один сервис (и то его один инстанс)
@@kl45gp Почитайте на досуге как устроен веб сервер, может перестанете говорить глупости.
@@kl45gpможно отрубать все ненужные кеши и роутить на определенные машины определенные урлы. По ресурсам будет как микросервисы, а чаще даже лучше
Если вы задаете вопрос зачем это вам и честно не можете на него ответить, то это значит что вы выгорели и уже физически не тянете конкуренцию с молодыми и тупыми, которые такие вопросы не задают. Они знают ответ. Затем чтоб получить вашу зарплату вместо вас.
OOOOOooooooooooooo
двигаца вперёд быстрее
ПОчему Зачем
Ох, спасибо, Михаил. У меня опыта в программирований недавно стукнуло 3 года. И мне нравится тейк про то, что нужно осознанно подходить к задаче, и прежде чем что-то выбрать или начать производство - понять, а что это такое и нужно ли оно? Не идти просто так за всеми. Такой же подход в каком-то из подкастов говорил Соер, ну он собственно и топит за осмысленную разработку, когда ты понимаешь, что делаешь.
Самостоятельная разработка конечно круче, ты сам решаешь, что делать, но не каждый может себе позволить и умеет
Чему я научился за 25 лет программирования - красиво делай, красиво будет
Благодарю, интересно. Записывайте еще, если не трудно.
Много написал. Считайте это выплеском боли человека, который работает на ужасном монолите и уже не в состоянии это терпеть =) С технической точки зрения и в идеальном мире не могу поспорить. Но в реальности мне кажется есть больше аспектов, чем только то, что монолит может выдерживать те же нагрузки. Я встречал однажды такой монолит, который сам с собой общался через внешнюю очередь и просто разные модули этого одного монолита подхватывали нагрузку, когда могли. Код - по сути монолит, но можно скейлить количеством задеплоенных инстансов почти, как в микросервисах, имея при этом более простую инфраструктуру. Главная проблема вылезает, когда растет команда. В такой команде получается, что каждый может вроде отвечать за какую то свою зону, но доступ имеет ко все кодовой базе. Даже если представить, что в изначальной версии мы имели идеальную архитектуру, что вряд ли, со временем начинается каша. На каждого девелопера сверху давят менеджеры по срокам и начинается срезание углов - где-то надо было использовать готовый код, но что-то не срослось и сделал запрос в общую базу в своем модуле, где-то не понял замысел архитектора и добавил свой код в не совсем верный модуль, следующий разработчик посмотрел на это и решил, что так и надо и пошло поехало. Через N лет получаем что-то невероятное мягко говоря =) Кроме того, чаще всего монолит - это одна общая база и все это ползет в нее тоже. У меня опыт, конечно, не гигантский, но я работал и на нескольких монолитах и на микросервисных проектах. Все монолиты, что я видел, были просто ужасающими. Сейчас уже пол года работаю над довольно крупным монолитом, команда опытная, сеньоры и архитекторы сохранились на проекте еще почти со времен его зарождения, код стандарты, код ревью довольно жесткие и аппрувить могут только несколько избранных. Но это не помогает. Во певых, даже эти избранные вообще ничего не помнят про большую часть проекта. Что в целом не удивительно, когда отвечаешь за все сразу. Проект превратился в полное месиво, где нет никаких разделений ответственности, все что угодно может происходить где угодно. Я так за эти пол года и не понял изначальной идеи архитектора, за слоями костылей этого уже не разглядеть. База данных - вообще кошмар. Под сотню схем, сколько таблиц вообще один господь бог знает. Есть много таблиц дубликатов или чего-то в стиле payments, payments1, payments_depricated и тд. В таблицах сотни полей, большая часть из которых пустые и никто не знает, зачем они нужны и нужны ли вообще. Делать релейшены между таблицами никто и не помышляет уже давно. Данные, которые вроде должны бы храниться где-то рядом, могут быть разбросаны по разным схемам в рандомном порядке. Микросервисная архитектура, что я видел тоже была не идеальной. Но она хотя бы устанавливает более четкие границы между зонами ответственности, которые нарушить очень сложно. Над разными зонами могут работать разные команды, что снижает объем того, что необходимо знать разработчику на своих участках. Сервисы сильно проще для понимания. По мне, если не иметь какую-то идеальную команду, где все дисциплинированы, одинаково хорошо разбираются в технологии и при этом еще и не меняются, то монолит будет эффективнее в разработке. У тебя все под рукой, ни с кем договариваться не надо. Берешь и делаешь. Но все упирается в команду, как по мне. Люди не идеальные, они меняются, знания теряются, а область ответственности растет. И вместе с этим растет сложность добавления новых фич. Микросервисы в начале сложнее. Дополнительные сложности с инфраструктурой, общением между командами и.т.д. Но эта сложность со временем растет предсказуемо и не так сильно. В то время, как сложность работы с монолитом в начале меньше, но со временем ускоряется все больше, пока компания не помрет в один момент. Мне кажется идеальный вариант начинать с монолита, который изначально планируется, под разбиение на сервисы в момент, когда сложности этих двух подходов пересекутся. И последний аспект, уже более относящийся к самому девелоперу. Возьмем девелопера, который проработал на монолите в котором из стека всего и есть, что C# и SqlServer. Кому он будет нужен на рынке, если его вдруг уволят или компания умрет? Это же просто конец карьеры, если только не найти точно такую же компанию.
хорошо написал, видел подобное...
В своей практике поступаем так, MVP-версию (прототип) делаем как монолит, чтобы примерно сделать демо основных замыслов. Если поддерживается дальнейшая разработка, тогда проектируется более детальная архитектура с разбивкой на сервисы и выбором стэка.
Чтобы избавиться от старого кода, ненужных таблиц обычно делается новая ветка проекта, в которую переходят только актуальные модули и таблицы данных.
Послать все наХ в таком случае 😂 И переформулироваться в другую специальность 😂
Надоели микросервисы. Из-за этого хайпа столько ресурсов уходит.
ещё один хороший навык: умение спрашивать: а почему нет? особенно когда в команду приходит новенький и модный мальчик и спрашивает:
а почему вы это делаете на монолите, а не на микросервисах?
или а почему вы используете TFS, а не модный сейчас git. В ответ спросить его: а объясни почему по-твоему мы должны переходить на эту технологию? Пусть объяснит. А самому внимательно послушать.
Кстати, вопросы почему? и зачем?: они принципиально отличаются друг от друга. И в английском тоже их часто путают:
Why - meaning: what caused this?
And:
what for - meaning: what will be the outcome or the result if you do this?
Спасибо, личный опыт это драгоценно. Спасибо и Божьих благословений Вам и Вашим близким.
Аминь
Профи фигни не посоветует: думай что и зачем делаешь и не забывай про бабки))
Спасибо за свои программысли, очень помогают увидеть вещи под другим углом)
Очень неудобно поправлять, но не flash mode, а flash mob (толпа).
Без проблем, я нормально отношусь к таким вещам. Во время записи просто забыл вообще как называются такие. Даже флеш мобом это не назовешь, кажется есть другой термин
У монолитной и майкросёрвис архитектуры есть у обоих свои преимущества и недостатки, как вы и сказали. Майкросёрвисы можно можно более точечно скэйлить. Монолит же можно скэйлить только полностью. Всё решает use case а не хайп
Нет. Монолит это больше маркетинговое название, придуманное для того, чтобы продать тебе микросервисы в облаке. А правильно говорить N-tier архитектура. В ней могут быть и сервера баз данных, и сервера для бизнес логики, и сервера для веба. Можно выделять отдельные небольшие приложения для специфических задач на отдельные сервера, и, в общем делать все что угодно, и все это прекрасно скейлить. До того, как облачные провайдеры начали впаривать микросервисы, проблем с масштабированием по частям никогда и не было. Например, у Microsoft в Azure до сих пор доступна инфраструктура Azure Cloud Services из домикросервисной эры, в которой сервера объединяются в так называемые роли и эти роли могут автоматически скейлиться. Там ты просто настраивал выкладку билда на стейдж и все, не нужно было никаких девопсов, YAML, ничего - ты просто писал код и не парился о том, сколько серверов нужно для какой части проекта. Поэтому не сказал бы, что в классической архитектуре прям уж нельзя масштабировать отдельные части, там для этого очень много возможностей, которые зачастую были даже удобнее докера и микросервисов. Другое дело, что чем меньше у тебя частей, тем меньше накладных расходов на их взаимодействие, поэтому в простых проектах для лучшей производительности обычно все кроме базы данных держали в одном приложении и скейлили все разом по серверам, а не по уровням.
Сделайте, пожалуйста, выпуск "Куда уходят умирать программисты за 50". Есть куча роликов, как стать джуниор программистом, а вот ничего про то, как/куда продолжить быть программистом.
Опыт в программировании 20+, бэк на java, застоявшийся мидл, никак не сдвинуться дальше. На своём месте работаю качественно. Работал в монолитах, умею в микросервисы. Освоить новое - не проблема. Но, наверное, гореть только работой уже не готов, когда днем и ночью только код, курсы, постоянные флешмобы "лучшей версии себя". Всё-таки семья, хобби, ложиться костьми не хочется. Возраст - сорокет с хвостом. Оглядываюсь по сторонам - практически не вижу своих ровесников рядом. Куда они уходят умирать, с какой скалы сбрасываются? Знаю, некоторые перешли в аналитиков. Кто-то - в админов/девопсов. Кто-то в бухгалтерию(раньше был тренд). Кто-то в архитекторов или в административную работу, управление. В чём причина этого, боятся, что год-3-5 и мозг сдаст, не смогут конкурировать с молодняком на равных? Как вы видите возможный путь? Есть ли вариант переквалифицироваться в датасайнс или еще во что-то смежное интересное перспективное(понятно, что это нифига не просто, тут скорее речь о возможном рывке в 2-3 года).
Понятно, что в Канаде/США и России этот путь - он разный, но всё же. Спасибо.
Если нравится дата сайнс, то можно переквалифицироваться. В Канаде много программистов в возрасте, которые продолжают писать код. Я сам не знаю, куда деваться после 50
@@programisli, а никуда и не надо !
Надо быть профессионалом в своем деле . Глупо расти 30 лет и потом куда то уходить. Вы же профи ! А профи всегда нужны везде .
Главное физ.форму держать .
А зачем 30 лет работать программистом?
Мне нравится код писать. Я сейчас менеджер, но продолжаю для себя писать что-то
Как я понял. Надо делать удобно и в зависимости от требования:)
Я в шоке что вы уже 30 лет работаете) Вы выглядите на 35, надеюсь не с 5 лет работаете))
Мне 47
Много новых терминов узнал, спасибо за рассказ)
Почему я не увидел это видео два года назад когда начал изучать бэк)
Относительно cloud vs 'on premises'. Есть такой зверь: Azure on premises
Он спасет мир :-)
Михаил, спасибо что делитесь опытом. Очень интересно и затягивает в тему айтишечки)
ссылку на интервью так и не разместили)
Мне 18 и я хочу стать программистом. Люблю посмотреть такие видео , очень мотивируют к продвижению в этой сфере 😁
У автора видео много хороших книг по C# у самого есть почти все книги Миши 😊
Удивительный канал, программист с опытом вместо того чтоб работать собирает донаты со зрителей. Успешный успех?
Докер это отстой, они используют виртуал бокс а в них имиджи из говна и палок слеплены. Лучше Фотон ОС и ВМваре.
У меня есть работа. Это же донаты, не хочешь, не участвую, всё добровольно
я заметил про монолит и микросервисы рассуждают только менеджеры ) ... программисты работают с тем что есть ) ... решит архитектор делать микросервисы, хорошо, нет, то-же неплохо )
Я среди программистов много слышу про микросервисы, мол перейдем на них и будет счастье.
@@programisli это как в том анекдоте - "ну и вы то-же говорите" ) ... я на прошлой работе видел такой монолитище, что я даже не представляю как микросервисы ему помогут ) ... хотя менеджеры только об этом и говорили, но ни один не взял на себя ответственность начать его "резать"
И правильно делали. Микросервисы - инструмент для решения проблемы организации работы программистов. Это зона ответственности менеджмента
Вообще так как ты авторитетный дядька, можно было записать небольшой ролик про нейросети, я понимаю не твоя стезя в целом, мнения на этот счёт, может личный опыт использования в жизни и в разработке, насколько это перехайп, ибо в целом есть две волны мнений : "Нейросети отберут хлеб у всего живого или Нейросети фуфло и до настоящего профи им далеко", ибо художников они уже неплохо так уделали, хочется посмотреть на вопрос со всех сторон
Целое видео пока не готов записать, я еще думаю над этим. Если коротко, то пока не заменят.
@@programisli в целом согласен и ответ знаю, но просто жду ваш ролик маэстро, как будет время и желание естественно
да уделали но вопрос кому это нужно и ответ авторитарной системе которая стремится подчинить себе все и вся но это объять не объятное парадокс? да! но на этом и стоит движение вперед
Привет. Посмотрел произношение build на американском англ. и на британском - оно одинаковое. Я думаю, что это дикция конкретного человека была - 'булд'
Это как русский - как произносят слова в городах и деревнях, это разные вещи. Так что здесь британец был явно со специфичным акцентом
Красиво!
За 30 лет работы программистом научился быть ДевОпсом)
И им тоже, говорил про это здесь DevOps глазами программиста - как я познакомился с DevOps
th-cam.com/video/_N1jNu7dDrM/w-d-xo.html
@@programisli да я к тому, что зашёл про опыт программиста посмотреть) но.. не дождался) А девеопс для бекендера понятное дело уже мастхев выходит..
Как хорошо, что попал на Ваш канал. Спасибо большое за творчество! Засмотрелся, подписался! Интересные мылси, хорошо поставленная речь! Очень интересно послушать матерого кодера)))
Спасибо
@@programisli я только начинаю изучать язык программирования, и решил я изучать питон, не знаю на сколько правильный выбор, но полагаю, что для новичка именно этот язык программирования отличный порог вхождения в тему. Так вот вопрос! Что именно необходимо минимально знать и Как правильно реализовать полученные знания для того что бы устроиться в компанию?
Прямо задел за живое. Мы распиливаем свою срм на отдельные части и связываем микросервисами. Наняли кучу девелоперов, тестировщиков, аналитиков, ушли в клауд. Но блин новые девелоперы ничего не знают про нашу систему. Куча созвонов, митингов. Обычная ситуация когда у девелопера в день 2 часа митингов. В таком режиме полтора года. В результате юзеры по-прежнему используют старую репортинговую систему вместо новой потому что с новой куча проблем. А у нашей старой дев команды кроме обычного добавления фич в систему прибавилось куча дополнительной работы с интеграцией.
До слез знакомая история
У меня пермоментое состояние того, что ты только подумал что, чему то научился. А потом понимаешь что ничего не знаешь
Бывает такое.
Отличный выпуск, спасибо! =)
попробуйте открыть для себя "serverless" патерн, вместо монолитов и микросервисов.
Это не универсальная таблетка
@@programisli SOA architectures преполагает "стабильную топалогию", т.е. лукавицу по любому нужно делать.
ну что-бы два раза не вставать, зачем париться только с "фанкшен (или домэйн) лайером", если можно и "процесс лайер" переложить на функции?
Миша, детей твоих давно не видно... Покажи хоть как-нибудь!
На неИТшном канале они появляются часто m.th-cam.com/channels/3VuryIjs0xXFu2vlbdbP0Q.html
Интересная история ❤
Начала изучать программирование с месяц назад, 90% терминов в видео не поняла от слова совсем, но уловила ваш посыл, спасибо)
Сельское хозяйство гораздо перспективнее. Потому что продукт получается напрямую без посредников.
Стоит ли 45 летним программистам переезжать в Канаду?
Я думаю, что будет сложно, но можно.
Это оно? th-cam.com/video/nZX13dVxnJw/w-d-xo.html
С этой же девушкой но другое. Там формат интервью был и похоже его не сохранили.
@@programisli просто картинки из видео, там тоже были)
Картинки взял уже из этого видео, потому что не нашел то, которое смотрел в декабре
Жизненно, особенно когда твой сервис и так является Микросервисом в большой системе, а вас заставляют распиливать ещё на 100 разных сервисов его) это не всегда нужно
Это как с базами, иногда нужна и денормализация
Когда интересно нужна денормализация?)
Не часто на старых технологиях проекты хороши и востребованы, если хочется расти по карьере, то только актуальный стек, в целом можно и не бежать за стеком, но тогда надо быть уверенным, что не останешься без работы завтра (в РФ на легаси можно не найти то что хочешь)
Актуальный стек конечно важно. И обновлять стек с целью быть на коне - это хорошая причина "почему" это стоит сделать
Привет. Услышал много раз слово монолит. Это о чём?
Ты не знаешь, что такое монолит?
@@programisli ааа, все про это знают, а я нет, как же так! Погуглил специально, чтобы понять терминологию. На самом деле именно монолиты я и собираю на Delphi. Как пример, использую встроенное средство для работы с базами. И 100% кода собирается при компиляции. На данном этапе я собираю порой в рамках 1 приложения сразу несколько EXE-шников, для чего написал отдельное приложение-инструментарий, ибо батники и скрипты на msbuild оказались костылями, управлять которыми неудобно
Добавлю, навык формулировать и задавать правильные вопросы полезен не только в dev
Я просто не понял твоего изначального коммента, что ты именно ввиду. Если ты делаешь десктопные приложения в Delphi то это не монолит и не микросервисы, это просто десктопные. Ты можешь вызывать различные сервисы как WebAPI.
@@programisli Речь идёт о терминологии. Чтобы к ней выработать отношение, хорошо бы всем прояснить, о чём речь. Я сталкиваюсь иногда с тем, что термины, применяемые блогерами, с ходу не были известны, а по мере вникания оказывается, что таким ты уже лет 100 как пользуешься и есть свой опыт, которым можно делиться. Чтобы использовать микросервисы в чистом виде, это должна быть обособленная задача, к использованию которой могут быть причасны несколько разных или несколько экземпляров приложений. Другая сторона медали. Как только решаемая задача усложняется, скорее всего выделение её в отдельный микросервис также усложняется. Поэтому и заинтересовал эфир, ведь чужой опыт он иногда дополняет собственный. И так как я с микросервисами знаком минимально, но выделяются среди множества задач экосистемы те, что по логике могут быть обособлены в отдельное решение, мне тема интересна. Я подошёл к решению, когда часть функционала приложения я выделяю в отдельное небольшое приложение, и оно разбирает команды, полученные по TCP/IP и в командной строке. Я называю такие микро-приложения ассистентами. Причина их появления в том, что когда требуется выполнить несколько действий, связанных с основной темой приложения, нет необходимости запускать его полностью, с интерфейсом, достаточно запустить в режиме - инициализируй состояние готовности, предварительная подготовка данных, подключения разные, отработай несколько команд и закрыв всё, прописав в логи, заверши работу. И на время выполнения этого движения некий набор межпрограммных взаимодействий будет недоступен, своего рода "критическая сессия". Но это, как я понимаю не совсем микросервисы. Вопрос в буквальном определении терминов. Скорее всего, дальше я буду двигаться в сторону, процесс приложения висит, всё инициализировано и готово, получил-отработал команды, и дальше себе "вишу" ) Если это называть микро-сервисом, то да, использование таких решений у меня назрело, так как подготовка к выполнению порой сравнима по времени с выполнением, и когда через батник или послав пакет команд я запускаю кучу раз на выполнение это микро-приложение, происходит многократная инициализация и это бессмысленно и по факту просто как потеря времени. Но я вышел из этого, было несколько случаев, когда я передавал именно большой пакет команд, то есть не несколько вызовов а сценарий, 5 команд, если условие, то следующие, иначе другой набор, и сценарии решают задачу того, чтобы 100 раз не проделывать инициализацию. Если сценарии возможны, сейчас я использую сценарии. Но в чистом виде, как микросервис, я планирую таковой, ибо есть задача, растянутая во времени в том смысле, что некоторые действия над информационным объектом нельзя спланировать как сценарий, это как хаотически возникшие потребности. Я о задаче техподдержки, когда доступ к состоянию некоторой задачи требуется по принципу - ну как я проверю, как там сейчас дела, а есть ли ошибки, а как проц и память нагружены, а если в задаче давно открытые базы и сложные индексы не используются, что если я позакрываю. И хорошо бы тиражирование и перенос на новый клон работающего приложения проделывать автоматом. Думаю над этим, и послушал лекцию про докер, как бы, двигаюсь в ту сторону. Вот такой мой опыт. Послушать опыт человека, книгу которого я читал, для меня честь. Если надумаешь делать видео про практику использования докера, без воды, а конкретно, задача, вот сценарий, вот так это получается, то прими мой голос в поддержку. Спасибо за интересные видео
Здраствуете Михаил можно вопрос стоит ли изучат Xamarin для мобильной разработка
Можно, но он не сильно популярен. Я бы лучше Flutter изучал
@@programisli, а почему не Kotlin?!
И могли бы вообще видео снять про ваше мнение про Kotlin?! Спасибо
Помогите пожалуйста мужу устроиться на работу, он программист C#, проработал 15 лет в компании, уволили, ищет работу, но пока отказы, у нас ребёнок инвалид, работать я не могу, муж один кормилец в семье, а у нас ещё кредиты, помогите пожалуйста, может быть кто нибудь сможет помочь, ему удаленка нужна 🙏
Второй после если вести счёт
20 мин про то, что научился задавать вопрос why.
Ну я в начале предупреждал, что будет долго, с историями, почему я люблю спрашивать почему
Спасибо за интересную информацию. Но насчет микросервисов: оптимизация работы конечного продукта может быть не всегда является окончательной целью. Если проект ОЧЕНЬ динамично развивается и на нем сидит с пол тысячи сотрудников, то прогонять, к примеру, через CI\CD работу каждого сотрудника может значительно замедлить общий процесс, тк dev окружение не всегда такое "щедрое", как prod)) А замедление процесса на таких объемах может конвертироваться в солидные финансовые потери. Возможно для Netflix с их штатом в 15000 этот переход решил какие-то проблемы в бизнес процессах. У стека, я смотрю, около 200 сотрудников. Что скажете если посмотреть на эти програмысли с такой точки зрения?)
200 сотрудников не значит, что 200 программистов. Там много тостеров, админов, инженеров, программисты могут работать над разными вещами. Поэтому монолит для них работает. Я не знаю, сколько из сотрудников Netflix программисты. Но если даже 1000, то тут ясно, почему они выбрали микросервисы. Да и проект у них шире, так что я уверен, что у них микросервисы оправданы
@@programisli цифры по сотрудникам приведены только для объемного сравнения. Понятно, что доля программистов будет совершенно другая, но в процентном соотношении этих двух компаний все равно можно увидеть разницу в штате. Но основная мысль моего комментария "тире" вопроса именно в том, что не всегда решающим аргументом может быть 100% техническая составляющая. Иногда это может быть завязано на оптимизации внутренних бизнес процессов, которые напрямую влияют на финансы бизнеса. Так ли это?
Что такое трафик?
Смотря в каком контексте, в отношении машин на дороге - пробка. Я не помню в каком контексте в использовал в видео
Первый!!!
Как понять, что ты стал програмистом?
А оно нужно заморачиваться такими вопросами? Научился писать какой-то код уже программист, дальше уже вопрос уровня
@@programisli спасибо
Учу с#, и докер кажется пока сложно. Но все таки придётся учить его
Скорей всего, он полезен и с монолитами и микросервисами
@@programisli это как с гитхабом, вначале думал все сложно да и зачем он мне сейчас 😁
Докер мега простой.
Записать пару комманд, понять как работают слои и осознать что внутри просто линукс в котором можно выполнять все те-же команды как и в обычном линуксе.
Спасибо за видео! Интересно, у монолитного Stackoverflow компиляция тоже занимает весь день?🤔
Не думаю. У меня Sony электронный магазин на горячую занимал не более минуты. Даже полная компиляция с нуля не более 5
Программировать? Лол
Привет, что думаешь о гос службе в IT? Я имею в виду фсб или кгб какое-нибудь. Как считаешь стоит ли начитать свою карьеру там? Будет ли это хорошим опытом? Да и вообще общее мнение интересно насчет этого.
Я там не работал. В ФСБ наверно не стал бы, думаю там есть потом ограничения на выезд из страны, а я люблю путешествовать. Если ограничений нет, то ... сложно сказать, не задумывался об этом
Добрый день! А где можно посмотреть что за сайт на бусти?
всё нашла)
Я бы сказал, что мейнстрим и хайлоад вообще плохо совместимы, мейнстрим ориентируется на скорость разработки и на то, что удобно массам, а под высокие нагрузки обычно наоборот приходится отказываться от удобного в пользу более простого и предсказуемого (и быстрого).
Микросервисы решают проблему менеджмента. Поэтому толковые книжки об этом сразу начинаются с Conway’s law.
Если монолит не соответствует орг-структуре, то начинаются проблемы с временем доставки фичей до пользователя.
Да, есть технические преимущества, но они менее значительны. При желании можно хорошую архитектуру сделать с монолитом и десятком сервисов вокруг. Но если у вас 40 команд работают изолированно с разной скоростью, вас это не спасёт.
А вот если 20 программистов в пяти командах, то нафиг это не надо. У них просто на тулинг времени не будет и они вечно будут заняты проблемами интеграции своих сервисов.
Послушал 9 минут. Ничего не понял.
Жаль
@@programisli но я разберусь. Видимо время займёт. Я только начал учиться на разработчика.
А почему Миша записывает это видео?
Чтобы вы задавали самый важный вопрос - почему! :)
Казалось бы название "Чему я научился за 30 лет работы программистом" а по итогу пересказ истории , а чему научился - нет ...
Есть