Про микросервисы за 8 минут

Рет қаралды 103,491

2 ай бұрын

Стань DevOps инженером за 4 месяца обучения! 🙌
wiki.merionet.ru/merion-acade...
Наверняка ты постоянно слышишь про микросервисы (microservices). Микросервисы то, микросервисы сё, переписали все на микросервисы, развернули микросервисы в контейнерах. А че это вообще такое? Сейчас все объясним.
Merion Academy - платформа доступного IT образования ❤️
wiki.merionet.ru/merion-academy
Наш Telegram канал:
t.me/it_knowledge_base
#микросервисы #microservices

Пікірлер: 151

@merionacademy 2 ай бұрын

Стань DevOps инженером за 4 месяца обучения! 🙌 wiki.merionet.ru/merion-academy/courses/devops-inzhener-s-nulya/?YT&

@52RK Ай бұрын

You are breathtaking! Я на канале минут 20, и каждое видео максимально понятное. Спасибо за ваш труд!

@_SSG_70_ Ай бұрын

Не надо обманывать народ. Вы зазываете их всех и потом народ в обломе больше никогда не берётся за сферу IT. Нереально НОРМАЛЬНЫМ DevOps стать не то что за 4 месяца, там вообще во всех этих направлениях учиться всю жизнь. За 4 месяца более менее человека можно научить работать с командной строкой, разделение дистрибутивов, работа с установщиками ПО в каждом поотдельности, настройка сети и вообще основы блин TCP/IP, далее можно какой-то разобрать даже файер вроде ufw , но ни о каком iptables и всех на его базе речи не будет. И ты смотри мы ещё не дошли соответственно до разбора API и даже разбор протокола HTTP. Мы даже ещё не затронули что-то вроде сертификатов SSL. Ой, а ещё море баз данных вроде Mysql. Там как бы тоже различий много и если придётся работать с MS SQL или PostgreSQL, то мне жалко того девопса, который только Mysql или MariaDB изучал. В общем если было не 4 месяца, а год записано, то и в этом случае очень сложно. Да чего далеко ходить, какой-нибудь арч линукс с нуля без мануала кто-то установит? Вот ни разу не заглянув в мануалы установите? :) Это я сейчас не закидываю какашками, а просто пытаюсь объяснить, что все уже который год рекламируют сферу IT, но мало кто понимает сколько лет труда, бессонных ночей, нервов это будет стоить.

@kae6108 23 күн бұрын

@@_SSG_70_Год-два это ни о чем время. В жизни 60-100 лет. Потратить пару лет и дальше всю жизнь развиваться в выбранной сфере, при этом не выискивая акции в пятерочке очень выгодно с точки зрения планирования жизни. Понятно, что не всем такой путь по душе. Ну а рекламой они занимаются ради собственной выгоды. Это их хлеб.

@escanor8297 2 ай бұрын

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

@shurik4493 2 ай бұрын

поправка: на каждый сервис не нужна отдельная нода

@validationerror3830 2 ай бұрын

@@shurik4493бывает, что нужна

@roninsh4341 2 ай бұрын

факты, которые не имеют отношения к современной кодовой разработке

@MrPushcart 2 ай бұрын

Классный формат. Для начинающих так вообще идеально, все сжато и весело подается. Очень удобно повторять перед собеседованиями

@_vpru 2 ай бұрын

Формат - понос Тинькоффский. Нельзя по-человечески что ли объяснять? Обязательно петросянить?

@equim7363 Ай бұрын

Если хочешь сурьёзный нудный формат - иди на просторы интернета, там полно материала про микросервисы.

@9968322594393 Ай бұрын

Это же обзор, что из этого можно использовать на собеседовании? 😮

@nechai 2 ай бұрын

Не забываем положить все микросервисы в монорепо 😍😍😍

@realfootball338 2 ай бұрын

А какая разница ? Если другие команды не лезут в другие сервисы то все ок. У каждой команды свои бранчи и все в монорепе это удобно. Скачал репу на мастере и поднял всю инфраструктуру локально через docker compose. Нужны другие сервисы подтянул к себе в бранчу бранчи других сервисов - это даже удобнее чем в отдельных репах

@hackyou497 Ай бұрын

и использовать под каждый микрофронтент ФСД архитектуру

@FooFie2131 Ай бұрын

@@hackyou497 фсд это просто структура папок. и все

@ikatu8605 2 ай бұрын

Я думаю, надо же, еще не видела это видео, а оно только вышло) Люблю вас за то что даже я понимаю)

@Ermak130990 Ай бұрын

В монолите если что-то лежит, лежит все приложение. Но и наоборот в микросервисах никогда полностью не работает приложение - обязательно что-то лежит :D

@teberano8268 2 ай бұрын

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

@drane4563 2 ай бұрын

Лайк если у тебя микросервисов больше чем пользователей

@bpospanov Ай бұрын

😂😂😂

@RgavayaGalaktika Ай бұрын

😂

@buga8855 2 ай бұрын

Спасибо за вашу работу! Очень хотелось бы увидеть ролик про брокеры сообщений)

@FF-gq3hm 2 ай бұрын

Контент очень крутой, и полезный, как раз сейчас на работе занимаюсь тем что разбираю монолит, и переношу его на мса)

@Porsche_C 2 ай бұрын

Большое спасибо за видео!

@normalnoenazvaniedlyaslaba4566 21 күн бұрын

все объяснено простыми словами в доступной форме, огромное спасибо!

@tak_sebe_bloger 24 күн бұрын

Вы как всегда лучшие, обожаю смотреть ваши видео😂, так держать👍🏻🤝

@redneck_prm5429 2 ай бұрын

Микросервисы - это только одна из нескольких распределенных архитектур. Есть SOA, в свое время словившая хайп не меньше, чем недавно микросервисы. Вдобавок еще есть service based и event driven архитектуры.

@olegt9865 2 ай бұрын

Как всегда очень полезно, чётко и по делу. Красавцы чё! 😊

@athreefu9151 2 ай бұрын

Классное видео, хотел бы увидеть от вас видео про SSR/CSR

@q100kmq 2 ай бұрын

Спасибо за старания и контент. Грузим лукас.

@thomaswilson8264 2 ай бұрын

Спасибо!😅

@borismoiseev8456 2 ай бұрын

Монолиты удобно использовать в маленьких проектах с использованием clean архитектурой p.s. Хочется видос по DDD

@isagidaiki 2 ай бұрын

спасибо за видео

@artemrokhmakov6373 Ай бұрын

Монолит использоваться можно смело в случае маленьких проектов, например с фреймворком Django, можно создавать другие приложения в других каталогах, и при этом делать это зависимо и не зависимо, выходит можно разграничивать логику и при этом использовать одну кодовую базу. А в случае с большими проектами исключительно микро сервисы.

@binrootav 2 ай бұрын

Еще есть протокол LDAP, что,для чего и где, было бы не плохо с такой подачей :)

@Oooohhh_maaaan 2 ай бұрын

Как всегда годната

@ruria_coda 2 ай бұрын

Ура, новое видео!

@Redmitryify 2 ай бұрын

Монолиты можно использовать при реализации mvp продукта, тк это сильно дешевле, чем микросервисы пилить:) Если гипотеза взлетает, то можно уже делать полноценный продукт на микросервисной архитектуре. Хотя…нет ничего более постоянного, чем временные решения😢

@rexdraconis1703 2 ай бұрын

Все, уверовал... Теперь учу микросервисную архитектуру...

@Aleksandr37rus 2 ай бұрын

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

@rexdraconis1703 2 ай бұрын

По факту, каждый гос сайт узкого направление это и есть микросервис.

@Maikuf 2 ай бұрын

Хороший ролик, для понимания топ

@vladimir.kravets Ай бұрын

Жаль, что вводит в заблуждение, выдает желаемое за действительное. Low coupling прекрасно возможен в монолите и нарушить его запросто можно и в микросервисах. Микросервисы это в первую очередь история о том, что команда разработки начинает сильно превышать оптимум из 7-12 человек, по этому одна команда разбивается на несколько отдельных команд, которым надо независимо друг от друга уметь релизиться и вот тут микросервисы будут уже ой как кстати.

@user-ir1fj5jl4x Ай бұрын

Можно узнать название саундтрека к вашим роликам? Контент очень краткий и интересный!

@Aleksandr37rus 2 ай бұрын

Сделай gRPC vs REST vs http vs http2

@merionacademy 2 ай бұрын

Вы прям в самую точку, следующий видос - про это! Уже даже озвучен. Подписывайтесь, чтоб не пропустить)

@yourownazog8069 2 ай бұрын

@@merionacademy круто!

@hpsfresh 2 ай бұрын

О, открыли для себя flaticon :)

@koussy.3572 2 ай бұрын

хорошее видео

@user-ny9ux9ss8n Ай бұрын

А где у Вас в курсе SQL , AWS или GCP ,Kafka? Prometheus???

@wildcat4435 2 ай бұрын

Микросервисы нужны только для разделения труда в больших проектах. Они не добавляют скорости приложению (наоборот) и стабильности. Если в "монолите" будет ошибка в api для авторизации, остальные эндоинты продолжат нормально работать точно также. Если внесены изменения только в модуль авторизации, его тоже можно загрузить отдельно точно также, а не весь проект. Зачем сбивать людей с толку такими видео.

@tomasddf 2 ай бұрын

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

@wildcat4435 2 ай бұрын

@@tomasddf синтаксическая ошибка в общем микросервисе для извлечения данных из бд вызовет тоже самое. Правда он не скомпилируется скорее всего, но точно также, как и typescript код. И не будет меняться долгое время, но опять точно также, как и обычные базовые модули. Во вторых, с чего бы таким общим классам, от которых все зависят, вообще быть, меня никто не заставляет их делать, если я хочу более модульную архитектуру. Микромодули они и так есть в любой нормальной архитектуре приложения. Весь стек технологий для именно микросервисов нужно тянуть только в том случае, если это реально упростит жизнь команде и она точно знает зачем ей это. Если команда будет их делать потому что "так в фейсбуке и так сказал чел с ютуба" жизнь усложнится очень быстро, а с возросшим бюджетом на разработку заказчик может послать куда подальше.

@tomasddf 2 ай бұрын

@@wildcat4435 "синтаксическая ошибка в общем микросервисе для извлечения данных из бд". А это как? Каждый микросервис самостоятельно ходит в свою БД. Причем у каждого микросервиса эти БД могут быть разного типа, в зависимости от потребности

@BOPHAKOHE Ай бұрын

Чем подкреплено тво мнение ?

@wildcat4435 Ай бұрын

@@BOPHAKOHE мО мнение подкреплено тем, что это исторический факт и его никто не отрицает. Иди лучше внедряй микросервисную архитектуру в лендинг пейдж своей мамы, а не пиши глупые комментарии

@user-vt2mc9oq8y Ай бұрын

За монолит!

@yejik5816 2 ай бұрын

Я правильно понимаючто микросервисы возможны только со стороны сервера и только если программа сетевая. То есть программа которая устанавливается на телефон или компьютер пользователя она всегда монолитная и если ее надо обновить то надо пересобирать и перезаписывать всю программу и обновить чать программы на устройстве конечного пользователя не возможно?

@dmitryandreew8582 2 ай бұрын

совсем не обязательно что микросервсное приложение - сетевое. Например возьмем Evernote. Представим, что у него нет сетевых функций, но оффлайн функционал остался. Таким образом, наше приложение (Evernote) может быть поделено на сервисы (Заметки, Календарь, фотографии, тудушка и пр..)

@xtech3408 2 ай бұрын

@@dmitryandreew8582 тогда это многомодульный монолит. Про это в видосе не сказали, но можно запилить монолит из нескольких модулей, где у одного модуля может быть даже несколько инстансов, если это понадобится. Разработка модулей ведется сравнительно раздельно, так при деплое можно пересобирать только изменившиеся модули, и можно спокойно разделить команды, чисто технически можно использовать разные языки с учетом того, что четко прописан будет не только API, но и ABI(конвенция вызовов), естсно это работает только для языков с одной платформы, например jvm, .net, llvm или просто компилируемые в машинно-зависимые бинарники

@dmitryandreew8582 2 ай бұрын

@@xtech3408 Спасибо за пояснения. С монолитами приходилось работать только на стадии раннего мвп и тестирования бизнес идей, посему никогда не копал так глубоко как вы.

@andynaz7044 2 ай бұрын

@@dmitryandreew8582 И что тут глубокого продемонстрировано?

@user-pg8ry1tm3t 2 ай бұрын

По вопросу где лучше имхо для начала стоит рассмотреть структуру подразделений разрабов, вероятно, делить на отдельные репы стоит учитывая этот фактор, если у вас небольшая группа, фиг ли там городить микро?.. если у вас много больших команд, наверное стоит задуматься о гибридных вариантах… имхо. Буду рад, если кто поправит и выскажет свои мысли

@tomasddf 2 ай бұрын

Я думаю что архитектура вторична. Попытки все описывать микросервисами - это в некотором роде преждевременная оптимизация. Софт живёт и развивается, и на каждом этапе к нему разные требования. В начале важнее стоимость запуска и сроки, чуть позже становится важнее уже стоимость поддержки и изменчивость, способность противостоять неконтролируемому росту сложности, сохранение низкого порога входа и возможность с лёгкостью находить людей для поддержки. Так что нет ничего плохого в том, что на разных этапах жизненного цикла у софта разная архитектура. Софт меняется исходя из изменения требований к нему: на каком-то этапе отдельные модули монолита так или иначе придется выделять в отдельные сервисы, частично или полностью независимые от монолита. Например на ранних этапах этого процесса к монолиту прикручивают внешние сервисы, такие как например эластик, и формируют вокруг них слой поддержки, а позже все это отпочковывается в отдельный проект, чтобы быть проще, надёжнее, и хорошо выполнять какую одну конкретную функцию

@user-id6mt9lb1k Ай бұрын

пушка

@rayman4x4 2 ай бұрын

Когда вместо "функционал" начнете использовать "функциональность", будет совсем хорошо )

@gvladimir5664 2 ай бұрын

За МОНОЛИТ!

@aizenzared6668 2 ай бұрын

Для меня самый неожиданный момент , что в таких случиях можно писать на разных языках .

@rbars96 2 ай бұрын

Как вывести текущую сессию авторизации например в пользовательскм интерфейсе? Когда они в разных микросервисах. При каждой загрузке сайта дергать другой сервис?

@rexdraconis1703 2 ай бұрын

Так фронт разве тоже микросервисно делиться? Если использовать около микросервисную архитектуру (например NX monorepo), то там проблем особо вообще не будет с этим. Или я не правильно понял вопрос?

@tomasddf 2 ай бұрын

Это задача апи гейта - это отдельный микросервис, который снаружи виден как монолит с публичным апи, а внутри по факту является диспетчером для всех остальных микросервисов и общается с ними через их отдельные апи или очереди. Так что с этой стороны все ок, фронт получит сессию авторизации точно также, как получил бы ее в монолите. Ну а под капотом апи гейт собирает ответ для фронта из данных от множества других сервисов. Но он их не дёргает каждый запрос, т.к. в таких системах обязательно применяется многоуровневое кеширование: он эту сессию каждый запрос будет доставать из какого-нибудь быстрого кеша, так что по затратам это будет сравнимо с отдачей статики. Сервис авторизации в свою очередь будет контролировать этот кеш: воссоздавать его при авторизации и инвалидировать при деавторизации или истечении срока жизни сессии.

@user-jo3tt6ug5t 2 ай бұрын

Мне как hr было полезно и понятно) спасиб)

@user-ee6gj1ld5p Ай бұрын

Мне понадобилось 48 часов...

@alexandrugrubneac4199 Ай бұрын

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

@KyrylWins Ай бұрын

как вам идея создать видео, в котором расскажите, в каком порядке нужно учить тему сеть (networking)?

@djmhk9060 Ай бұрын

не нужно дублировать текст мемом , как по мне. Можно просто заменить мемом слово и станет только лучше. Хотя бы протестировать. Извиняюсь, если сильно раскритиковал

@merionacademy Ай бұрын

Спасибо, учтём)

@dmitryandreew8582 2 ай бұрын

Монолиты хороши когда надо сделать что-то быстро и, скажем, протестировать какую-то бизнес-идею. Собрал мвп, выплюнул в фокус группу / реальных пользователей и смотри как оно работает. Работает - можем пилить на мс. Не работает - штош, не велика беда

@andynaz7044 2 ай бұрын

болтуна видно сразу

@dmitryandreew8582 2 ай бұрын

@@andynaz7044 поделитесь своим мнением

@adastraperaspera7116 2 ай бұрын

Вообще, лучше монолит. Микросервисы - если у вас нормальный архитектор, который понимает: вот тут по другому ну ВАЩЕ никак. У нас на работе микросервисное и оно мальца без доков кумарит

@tomasddf 2 ай бұрын

А у нас монолит, и оно без доков тот еще ад. Лучше бы распилили на сервисы, чтобы уменьшить связность, и разграничить зоны ответственности между командами. А также в этом случае можно было бы получить преимущества благодаря независимости : у каждого сервиса свои задачи, которые эффективнее решать какими-то своими инструментами, в монолите же все вынуждены страдать, оставаясь в рамках одного общего языка и архитектуры, изобретая велосипеды, вместо того чтобы просто воспользоваться более подходящими инструментами. Отдельная боль - тестирование монолита. Степень связности там настолько высокая, что ни о каком автоматическом тестировании и речи быть не может, только ручное тестирование, только хардкор и боль. И нет никаких надёжных способов как-то ограничить рост сложности монолита: несколько команд, текучка, хаос, каждый лепит как умеет, количество костылей год от года растет, и разгрести все это ресурсов просто нет. Вместе со сложностью растет и количество ошибок и стоимость поддержки/разработки, контроля становится все меньше, и увеличивается текучка: копаться в этой куче навоза желающих нет, слишком высокий порог входа, слишком больно, и как вишенка нет документации, точнее она моментально устаревает, все держится только на экспертизе старожил, которых с каждым годом становится все меньше и меньше. Люди уходят, я тоже уже подумываю уходить, нервов уже на все это не хватает. Так что лучше уж пачка небольших микросервисов, рост сложности которых ограничен, в которых низкий порог входа и есть возможность всегда найти людей для поддержки, и самое главное, в которых четко ограничена сфера ответственности, на уровне архитектуры, и при всем желании повысить связность и сложность ни у какого отдельного разработчика просто нет возможности. Самая большая беда, когда какой-нибудь не особо умный разработчик пытается срезать углы, прокладывая новые связи там, где их быть не должно - это наиболее сильно влияет на степень сложности и количество ошибок, и это возможно только в монолитной архитектуре, где разработчик ничем не ограничен и может творить грязь.

@vladimir_-_ 2 ай бұрын

5039 нах ) ps спасибо ребят за вашу работу очень познавательно

@BumChigaBum 2 ай бұрын

а где исходник примера.

@user-vt2mc9oq8y 2 ай бұрын

А можно пожалуйста еще гачистов в мемы, плз?

@astasjr8969 Ай бұрын

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

@fallenull Ай бұрын

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

@Chel1k7 2 ай бұрын

Монолиты это жесть, особенно если они были написаны 10+ лет назад и их не хотят обновлять

@Aleksandr37rus 2 ай бұрын

Еще и на скриптах 😅 кайф легаси, смерть развитию

@rayman4x4 2 ай бұрын

Лол. Это как ругать родителей, что ты есть.

@user-yu5yz7pf4u 2 ай бұрын

Монолит намного проще ,ACID из коробки и нет гемора с сетью между сервисами)

@EarthCitizen124 2 ай бұрын

@@user-yu5yz7pf4u А еще транзакционность поддерживать между запросами... А еще всякие BFF для каждого микросервиса А про общий shared код - вообще молчу) его педалят все... и ломается оно сразу у всех 😂

@Chel1k7 2 ай бұрын

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

@gordonfreeman9813 2 ай бұрын

А у меня микрозарплата

@marte8612 Ай бұрын

Ну девопсы не то чтобы прям легко с этим справляются 😂

@kostyan1983 8 күн бұрын

А куда делось видео про кубер?

@merionacademy 8 күн бұрын

Оно там же, где и прежде 🙂

@helpatch 2 ай бұрын

Я сейчас только монолит и пишу. Допустим боты на Python

@bauyrzhanakhmetov Ай бұрын

Нюхали как то “монолит”

@Time2paw 2 ай бұрын

Видео о том, какой важный и нужный канал. Себя не похвалишь, никто не похвалит

@--fly Ай бұрын

8 дней = 8 минут

@itaccount1993 2 ай бұрын

02:28; 02:57

@SingleFeniks Ай бұрын

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

@nealjosha 2 ай бұрын

Специально кладу сайт, чтобы получить по жопе.

@anatolzva6763 Ай бұрын

Теперь хрен сделаешь магазин, стольким сервисам плотить, разве что наркоту продавать и то не везде, цены упали а сервисы умножились..

@TaggartMk2 2 ай бұрын

микросервисы - микрослоники, напевал я , перенося полтерабайтные контейнеры со старого сервера на новый.

@heheheyhey5234 Ай бұрын

Веб разработчики такие Клоуны. Если у вас не гугл, Яндекс, сбер или что то похожее по размерам. Дрочь с Микро сервисами не нужна. Медленная, дорогая разработка, маленькая производительность, относительно монолитов. Увеличенное кол во программистов

@pingwin840 2 ай бұрын

Я 10

@user-ql4xu5qu2u 2 ай бұрын

Рассказали бы лучше про курс подробнее, а то ссылкой тычите уже год

@merionacademy 2 ай бұрын

Вы можете узнать детали пройдя по ссылке, или пройти вводный урок! 🙂

@user-ql4xu5qu2u 2 ай бұрын

@@merionacademy там стандартный лендинг, ничего интересного

@merionacademy 2 ай бұрын

пройдите вводный урок, там будет интереснее! 🙂

@user-pg8ry1tm3t 2 ай бұрын

Несколько не согласен, что в монолите все перекомпилировать и пересобирать. Даже элементарные более оптимальные построения классов позволяют компилить только то, что создано вновь либо модифицировано. Потом, почему речь идёт только о монолите и микро?.. а где гибриды, скажем проекты, взаимодействующие длл или иными способами? Сборка одного длл конечно подразумевает общую сборку проекта в деплой, но речь не идёт о компиле или сборки с нуля всей кодовой базы

@vladg6251 9 күн бұрын

А есть смешанный формат? Типа и то и другое, плюсы одного и другого

@ivann129 2 ай бұрын

микрочл

@surecom11 Ай бұрын

Спешу всех расстроить , на курсах devoos вы не научитесь🎉

@merionacademy Ай бұрын

А что за курсы по devoos?

@user-hc1bj4ih9u 2 ай бұрын

Я первый

@user-zy7ug4sl6z 2 ай бұрын

⁶⁷⁹

@alexgorq_gfa12_cifn Ай бұрын

типо это разные html файлы, которые обращаются друг к другу на разных лвлах? не совсем понял суть микросервисов. Ну, да, удобнее работать над проджектом, но как их воссоединить?

@_SSG_70_ Ай бұрын

Чувак, который создавал ролик видно какой-то программер? Скажи мне мил человек где ты последний раз видел программера, который бы САМ что-то любил оптимизировать? Может лет 20-25-30 назад были такие, которые были ограничены аппаратными ресурсами. Я вот например писал всякие системные штуки. Создатели игр тоже вынуждены были оптимизировать, потому чтобы в массы что-то пошло приходилось всё же двиги вылизывать. Но опять тут тоже ключевые слова ВЫНУЖДЕНЫ и ПРИХОДИЛОСЬ. Так за последующие 25 лет я ни разу не встретил разраба, который бы по своей воле что-то начинал оптимизировать. Конечно если писали какую-то уж очень дичь и какой-то запрос на кассе занимал по полминуты, то конечно некоторым ума хватало оптимизировать. Сегодня таких нет. Но зачем всем этим вообще заниматься? А давайте поделим всю эту хрень на кирпичи и всучим им совершенно другим кадрам. Пусть они мучаются. Как результат получили кучу новых технологий. Штук 12 точно, которые почему-то всем и сразу бывают нужны. Взаимозаменяемость? Не, не слышали. Написать в одном проекте? Не, тоже не слышали. И получается интересная вещь, что по сути все эти проблемы нагрузили на админов. Да да, тех самых самых обычных админов, которыем надо было с системой возиться, либо с сетью. Ну а кто бы ещё кроме них весь этот винигрет потянул? Проблема заключается ещё в том, что и классическое понимание каких-то инженеров, сисадминов, сетевиков изживает себя. Смотришь вакансию и не понимаешь, написано скажем хотят просто айти администратора, а вот функционал там как у начальника отдела поддержки по запуску ракет в космос. Или скажем позиция сисадмина, но функционал хотят тот же - работа с облаками, куча всяких кафок, докеров, шмокеров, кубернетисов. Так и хочется всех этих хитрозадых спросить - вам что в лом было написать что вы хотите вообще ДевОпса? Ну вы же Девелопера уже девелопером называете и от девелопера даже администрирования баз данных не требуете? В общем зажирается начальство в айти секторах. Если кто не понял поясню. Разница в зарплатах и нагрузке в разы. Потому никто даже правильно не пишет чего им надо на самом деле, но юзать тебя будут как девопса. Но есть ещё один нюанс. Даже если вы проработаете условно сисадмином на позиции для девопса, то вы даже в резюме своём это не сможете легально записать. В общем надеюсь понятно объяснил.

@merionacademy Ай бұрын

Добрый день! Отвечая на ваш вопрос касаемо разраба, которого мы видели и он любит что то оптимизировать - видели его в пятницу (2 дня назад) крайний раз!

@_SSG_70_ Ай бұрын

@@merionacademyИ чего и зачем он пооптимизировал? Ну без подробностей конечно. Сегодня нет каких-то фанатиков или энтузиастов, которые будут пилить код до идеала. В основном все пашут чтобы просто работало. Конечно есть вспомогательные средства проверки кода, даже софт проверки на уязвимости, но по сути это так. Даже компании гиганты вроде Майкрософт, РедХат и т.д. этим не занимаются. А это как бы написание осей.

@merionacademy Ай бұрын

Добрый вечер! Отвечая на ваш вопрос: оптимизировал процесс планирования смен операторов!

@_SSG_70_ Ай бұрын

@@merionacademy Да ладно. Мне то какое дело человеку с 27 годиками опыта и 10 годиками образования. Я просто высказал своё мнение. И в подтверждение моих слов можно послушать что тот же Гейтс когда-то говорил сколько памяти кому хватит, потом посмотреть на современные сначала десктоп системы с потреблением памяти, потом на всякий случай глянуть потребление последними версиями андроида и в конец посмотреть уже тех характеристики роутеров и их осей. Ни в одной области оптимизацией написанного кода и не пахнет. Ни один фактически компилятор не выдаёт оптимальный код (мингва более менее ещё). Да вообще как махина типа ВС размерами в 50 и более гигов инсталяшки может оптимально что-то собрать? Её саму надо оптимизировать и оптимизировать. А новое никто ничего не создаёт, нормальное, компактное, безопасное и быстрое. Потому код уже по определению не может быть нормальным.