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

«Все об этом говорят, некоторые понимают, (как они думают), а занимаются, по-настоящему, лишь единицы» — цитата программного директора 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 года. Мы рассматриваем факторы выбора архитектуры в зависимости от конкретной задачи.Читать полностью »

image

Как изменить архитектуру монолитного продукта, чтобы ускорить его развитие, и как поделить одну команду на несколько, сохранив согласованность работы? Для нас ответом на эти вопросы стало создание нового API. Под катом вас ждёт обстоятельная история о пути к такому решению и обзор выбранных технологий, но для начала — небольшое лирическое отступление.

Несколько лет назад я прочёл в научной статье, что для полноценного обучения нужно всё больше и больше времени, а в недалёком будущем на получение знаний будет уходить восемьдесят лет жизни. Видимо, в IT это будущее уже наступило.

Мне посчастливилось начать программировать в те годы, когда не было разделения на бэкенд и фронтенд-программистов, когда не звучали слова «прототип», «продуктолог», «UX» и «QA». Мир был проще, деревья выше и зеленее, воздух чище и во дворах играли дети, а не парковались автомобили. Как бы мне ни хотелось вернуться в то время, нужно признать, что всё это не замысел суперзлодея, а эволюционное развитие общества. Да, общество могло развиваться иначе, но, как известно, история не терпит сослагательного наклонения.

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

Кажется, пик хайпа по микросервисам остался позади. Мы уже не читаем по нескольку раз в неделю посты «Как я перенес свой монолит на 150 сервисов». Теперь я чаще слышу разумные мысли: «Я не ненавижу монолит, я просто забочусь об эффективности». Мы даже наблюдали несколько миграций от микросервисов обратно к монолиту. При переходе от одного большого приложения к нескольким службам меньшего размера вам придётся решать несколько новых проблем. Перечислим их максимально кратко.
Читать полностью »

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

Основной посыл всех этих докладов — микросервисы помогают уйти от излишней сложности и запутанности проекта. Но, как по мне, от сложности не избавится совсем, нельзя переделать проект, чтобы сразу всё стало просто. Сложность из одной области перейдет в другую.
Читать полностью »

До микросервисов нужно дорасти, а не начинать с них - 1

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

У нас, разработчиков программного обеспечения, довольно интересная профессия. Мы можем спокойно кодировать целыми днями, а затем прочитать статью о чём-то — и она подвергает сомнению всю нашу работу, потому что какой-нибудь Netflix сказал XYZ.

Просто так, из-за мнения одного человека или компании вы начинаете сомневаться во всём, что делали в течение многих лет, даже если всё работало отлично.
Читать полностью »


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