Рубрика «монолит» - 2

Прим. перев.: системный архитектор Avery Pennarun, создавший VPN-решение Tailscale на базе WireGuard, размышляет об отличиях монолитов с модулями от микросервисов. Он рассказывает об эволюции подхода к модульности вообще и о том, почему изоляция до сих пор далека от совершенства, а также делится своим мнением о том, когда проводить границы между сервисами рационально.

В последнее время меня часто спрашивают, в каких случаях переход на микросервисы — хорошая затея. В статье «Systems design explains the worldЧитать полностью »

В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?

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

С этой темой я выступал на Читать полностью »

В общем потоке новостей остался незамеченным совместный призыв продукт-менеджера Chrome Кенджи Бахе и веб-консультанта Google Юсуке Уцуномии об использовании нового стандарта Web Bundles, разработанного Google. На chromium.googlesource появился соответствующий мануал по использованию WebBundles и, собственно, особо о нем больше не говорилось. Запись от лица Базе и Уцуномии была опубликована еще в ноябре 2019 года, но вызвала реакцию сообщества только сейчас, и то, исключительно на нескольких профильных площадках и в одном блоге, посвященном кибербезопасности.

Google продвигает новый стандарт WebBundles — потенциально опасную для веба технологию «упаковки» веб-сайтов - 1

Чем так опасна технология «упаковки» содержимого веб-страницы в один источник, что это вообще такое, и почему команда веб-разработки Google ступает на очень скользкую дорожку, давайте разбираться ниже.
Читать полностью »

Привет, меня зовут Ваня. Я решаю архитектурные задачи на фронтенде в Тинькофф Бизнесе и сейчас расскажу вам про одну из них.

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

Как мы распилили монолит. Часть 1 - 1

Синхронизация

Читать полностью »

«Все об этом говорят, некоторые понимают, (как они думают), а занимаются, по-настоящему, лишь единицы» — цитата программного директора DUMP Казань. Если вы думаете, что вы тертый калач фронтенд, и ничего нового на конференциях не услышите, то загляните на frontend-секцию 8 ноября. Мы вспотели, пока слушали мат.часть некоторых докладов и истории взлетов-падений.

Темы секции Frontend на DUMP Казань: ML для фронтенд-разработчика, пиксельная магия, SvelteJS, смех, пот и слезы - 1
Читать полностью »

На конференции RubyRussia Кир Шатров расскажет об архитектуре Shopify. Как одного из самых больших и нагруженных в мире приложений на Rails поддерживает рост бизнеса на протяжении 10 лет, не переходя на микросервисы, Elixir и другие популярные альтернативы? В традиционном интервью перед конференцией вопросы Киру задал Анатолий Зайцев, разработчик компании Evrone.

image

Расскажи, как ты начал карьеру?
Читать полностью »

image

Когда задумывается большой продукт или маленький софт начинает вырастать в левиафана, какой путь развития выбрать? Стоит ли все переписывать с нуля или продолжать «исторически сложившиеся» традиции? Да и вообще, стоит ли пересматривать саму концепцию архитектуры?

Здравствуйте! Меня зовут Константин, и я являюсь ведущим разработчиком одной довольно крупной системы, которая начиналась когда-то как эксперимент. Небольшой сайт на PHP, созданный буквально «на коленке» и, конечно же, монолитом. Шло время, сайт рос и столкнулся с рядом проблем, решение которых поставило вопрос «а дальше-то как?».
Читать полностью »

монолит от https://reneaigner.deviantart.com

Неделю назад я выступал на митапе по Node.JS, и многим обещал выложить запись выступления. Уже потом я понял, что мне не удалось вместить в регламентированные полчаса некоторые интересные факты. Да и сам я больше люблю читать, а не смотреть и слушать, поэтому решил выложить выступление в формате статьи. Впрочем, видео тоже будет в конце поста в разделе ссылок.

Рассказать я решил про набившую оскомину тему — жизнь в монолите. Об этом на хабре уже есть сотни статей, тысячи копий сломаны в комментах, истина давно погибла в спорах, но… Дело в том, что у нас в OneTwoTrip есть весьма специфический опыт, в отличие от многих людей, которые пишут про некие архитектурные паттерны в вакууме:

  • Во-первых, нашему монолиту уже 9 лет.
  • Во-вторых, всю жизнь он провёл под хайлоадом (сейчас это 23 млн запросов в час).
  • А в NaN-ых, мы пишем наш монолит на Node.JS, который за эти 9 лет изменился до неузнаваемости. Да, мы начинали писать на ноде в 2010, безумству храбрых поём мы песню!

Так что всякой специфики и реального опыта у нас довольно много. Интересно? Поехали!

Читать полностью »

Вечный вопрос технического долга - 1
Это одно из самых крутых облегчений проекта. На картинке — график суммарного времени, затрачиваемого CPU на обработку всех пользовательских запросов. В конце видно переход на PHP 7.0. с версии 5.6. Это 2016 год, переключение во второй половине дня с 24 ноября.

Туту.ру с точки зрения вычислений — это в первую очередь возможность купить билет из точки А в точку Б. Для этого мы перемалываем огромное количество расписаний, собираем в кэш ответы множества систем авиакомпаний и периодически делаем невероятно длинные join-запросы к базе данных. В целом мы написаны на PHP и до недавних пор были полностью на нём (если язык правильно готовить, то можно даже строить на нём системы реального времени). С недавнего времени критичные по производительности участки стали рефакториться на Go.

У нас постоянно возникает технический долг. Причём это происходит быстрее, чем нам бы хотелось. Хорошая новость: его не надо закрывать весь. Плохая: по мере роста поддерживаемой функциональности техдолг тоже пропорционально растёт.

Вообще технический долг — это плата за ошибку при принятии решения. Вот ты что-то предсказал не так, как архитектор, то есть совершил ошибку прогнозирования или принимал решение в условиях недостаточной информации. В какой-то момент понимаешь, что надо что-то менять в коде (часто на уровне архитектуры). Дальше можно сразу поменять, а можно подождать. Если подождал — на техдолг набежали проценты. Поэтому хорошая практика — время от времени реструктуризировать его. Ну или признавать себя банкротом и писать весь блок заново. Читать полностью »

Сравниваем особенности микросервисной и монолитной архитектуры, их преимущества и недостатки. Статья подготовлена для Хабра по материалам нашего митапа Hot Backend, который прошел в Самаре 9 февраля 2019 года. Мы рассматриваем факторы выбора архитектуры в зависимости от конкретной задачи.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js