Я бы даже сказал: «Независимая масштабируемость отдельных частей проекта». Пример. У нас магазин. Нагрузка неоднородная. В течении дня есть пики когда люди просто тыкают по страницам, если время когда много заказов, есть когда сильно используется поиск по каталогам, опять же маркетинговые фичи. Сервисы/Микросервисы позволяют масштабировать каждую фичу в отдельности. Нагружают пользователи запросами модуль оплаты, добавим ему ресурсов (оно само добавит). Ищут что-то, раскидываем поиск на дополнительные ноды. Когда всё было в монолите, так просто не смогли реализовать. Хотя старый код всё еще работает, решили его не растаскивать. Работает ведь.
Вроде и правильно пишете, но всё-таки не соглашусь. Во первых выбор архитектуры это не разраба задача. Потом, в этом как раз и есть положительные стороны сервисной архитектуры, ему не надо писать проект на 50krps, оно в теории скалируется системными средствами.
Нельзя говорить "в большинстве случаев". Выбор архитектуры (или тех. стэка) должен всегда исходить из поставленной задачи, а не из статистических данных.
Как-то всё притянуто в статье. Автор прям в каждом предложении старается отбить название. Как всегда, одни на "хайпе," другие на "хэйте", но в жизни оно всё-таки где-то посередине. Когда уже будет статья: "как я сочетаю разные архитектуры для разных задач", я бы такую почитал...
Выходцы из восточной европы. Они ведь едут работать не куда, а откуда. Поэтому и плохие отзывы им по барабану. Лишь бы работа была. Вот этим и пользуются. При чём есть знакомые и из BMW и из Гугла, где профсоюзы довольно сильные, но везде одна и та же история. Это всё-таки не от географического положения зависит, а от человеческой натуры.
Да всё тоже самое. Особенно с "восточниками". Если местные более матёрые в плане трудового кодекса, то на приезжих ездят все, кому не лень. И текучка поэтому в многонациональном коллективе выше.
Далее нагретая вода выливается обратно в море или океан
Всё-таки есть сомнения по поводу непостардания локальной экосистемы. Особенно когда таких ДЦ будет побольше. У нас ТЭС воду с охлаждения турбин выливает обратно в реку. Так экосистемы «до» и «после» прям сильно разные.
Надеюсь, что нет. Просто их в своё время тоже называли убийцами хтмл. Говорили, что хтмл не тянет растущих потребностей пользователей, ну и всё такое прочее.
Автору спасибо! Подсказка про версию 1.0 очень помогла. Тоже получил от китайцев чип на 64к и долго пытался активировать второй блок. Правда вместо второго STM использую Pi, там же стразу и gnuk компилировал.
Это не вопрос, что вы. Удивило, что вы не упомянув железа стали накатывать на него настройки. Так же и с jumbo. Их ведь должны поддерживать не только конечные девайсы, но и все L3 на маршруте. Получается начитаются юниоры таких статей, начнут применять у себя и порушат всё окончательно. Ну нельзя давать простыни конфигов без объяснений. Мне кажется.
Я бы даже сказал: «Независимая масштабируемость отдельных частей проекта». Пример. У нас магазин. Нагрузка неоднородная. В течении дня есть пики когда люди просто тыкают по страницам, если время когда много заказов, есть когда сильно используется поиск по каталогам, опять же маркетинговые фичи. Сервисы/Микросервисы позволяют масштабировать каждую фичу в отдельности. Нагружают пользователи запросами модуль оплаты, добавим ему ресурсов (оно само добавит). Ищут что-то, раскидываем поиск на дополнительные ноды. Когда всё было в монолите, так просто не смогли реализовать. Хотя старый код всё еще работает, решили его не растаскивать. Работает ведь.
Что-то тимлиды не своим делом у вас занимаются.
Нельзя говорить "в большинстве случаев". Выбор архитектуры (или тех. стэка) должен всегда исходить из поставленной задачи, а не из статистических данных.
Как-то всё притянуто в статье. Автор прям в каждом предложении старается отбить название. Как всегда, одни на "хайпе," другие на "хэйте", но в жизни оно всё-таки где-то посередине. Когда уже будет статья: "как я сочетаю разные архитектуры для разных задач", я бы такую почитал...
Как вариант, это еще возможность довольно просто привлекать аутсорс. Или распределять работу между разработчиками разного уровня.
Да всё тоже самое. Особенно с "восточниками". Если местные более матёрые в плане трудового кодекса, то на приезжих ездят все, кому не лень. И текучка поэтому в многонациональном коллективе выше.
Всё-таки есть сомнения по поводу непостардания локальной экосистемы. Особенно когда таких ДЦ будет побольше. У нас ТЭС воду с охлаждения турбин выливает обратно в реку. Так экосистемы «до» и «после» прям сильно разные.
Она же сказала про ячейку, снимет деньги в атм, положит в ячейку, они подъедут — заберут.
Забавно, что Вы стали крутить настройки даже не посмотрев, что у вас за карты.