Кир Шатров: Shopify начался с Rails и здесь искренне любят этот фреймворк

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

    image

    Расскажи, как ты начал карьеру?

    Как и многие, я занимался программированием еще в школе. Делал сайты на WordPress за 200$ каким-то знакомым. Узнал о Ruby on Rails и понял, что те задачи, которые на PHP занимают часы и дни, можно решать гораздо быстрее. Мне показалось, что стоит запрыгнуть на этот поезд: я купил книгу по Rails и начал изучать по шагам. Многие шаги не работали, и я забросил занятия. Вернулся через год, попробовал идти по онлайн-туториалам, и тогда все получилось. Только потом я понял, в чем была проблема: пока книгу писали, переводили, печатали и везли в магазины, прошел год, а то и полтора. Rails за это время сильно изменились. Естественно, что инструкции уже не работали. А когда я смог читать материалы онлайн и на английском, то легко вошел в Rails и сделал первые хобби-проекты.

    Потом я познакомился с Олегом Балбековым, основателем конференции RailsClub, которая теперь называется RubyRussia. Так я попал в компанию Evrone, где проработал почти четыре года и благодаря классным и умным коллегам смог хорошо вырасти. Evrone здорово помог начать: была возможность делать опенсорс, расти. Потом я работал в Evil Martians, делал проекты уже другого масштаба — EBay, Groupon, Gett. У марсиан необычная культура опенсорса и экспериментов, которая бывает далеко не во всех командах. В перерывах между проектами или прямо на проектах у людей есть возможность заниматься опенсорсом. Именно так получается развивать Autoprefixer, AnyCable и не только. Как результат — есть о чем рассказать на конференциях. Я выступал на RailsClub в России, RailsConf в Штатах и на огромном количестве других крупных и не очень мероприятий. И из-за того, что я так много выступал, меня заметили и пригласили работать в Shopify.

    Расскажи, как ты переехал в Канаду и как Shopify помогал в процессе?

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

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

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

    Чем конкретно ты сейчас занимаешься в Shopify?

    Задачи разные. Конечно, я пишу код. Но много моего времени уходит и на организацию процессов. Например, в конце ноября будет Black Friday. Для всех, кто работает в e-commerce, это самое большое событие в году. Мы начинаем готовиться еще в августе: нужно договориться с разными командами о выпуске новых фич, договориться с вендорами и провайдерами. А после того, как черная пятница пройдет, мы входим в фазу, когда начинаем делать что-то новое. Тогда мне приходится надевать шляпу архитектора.

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

    Shopify — большая платформа. Сколько у вас клиентов?

    Официальная цифра — 800 000 активных магазинов. Это не просто регистрации (их намного больше), это именно живые бизнесы.

    Что Shopify как платформа дает клиентам?

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

    Если ты живешь в стране, где у Shopify полная поддержка, значит, что тебе не нужно выбирать платежную систему, ведь есть Shopify Payments. Просто вводишь свои налоговые данные, и все будет работать. Та же ситуация с отправкой товаров: ты печатаешь стикер, клеишь его на посылку и отправляешь. Не нужно покупать марки, оплачивать доставку, Shopify автоматически интегрируется с почтами. Есть складские сервисы: ты можешь отправить свои товары на склад Shopify, а сложные алгоритмы вычисляют, на каком складе его хранить, как обеспечить доставку клиентам за один день. Это позволяет малому бизнесу конкурировать с Amazon и EBay.

    Я некоторое время работал над переносом проекта на вашу платформу. У этого магазина были свои inventory, товары, клиентская база. Все работало достаточно удобно: есть экспорт\импорт, даже сторонние платежи подключаются в два клика. У вас огромная инфраструктура. Правильно ли я понимаю, что большинство библиотек (shopify api, shopify app, shopify co), написано на Ruby и Rails?

    Да, это так.

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

    Компания началась с парня по имени Тоби, который увлекался сноубордами. Двенадцать лет назад он решил написать свой магазин для продажи этих сноубордов. Делать это на PHP, Java и XML ему было не интересно. Тогда друг Дэвид показал ему свой новый классный фреймворк, который позволял быстро создавать веб-приложения. Фреймворк назывался Ruby on Rails, и на нем Тоби построил свой магазин для сноубордов. Ему понравился язык и идеи фреймворка, Тоби стал одним из первых контрибьюторов в Rails. На тот момент у Rails еще не было даже централизованного git репозитория! Люди просто обменивались новыми версиями. Так Тобиас Лютке и Давид Хейнемейер Ханссон начали работать над Rails. И скоро Тоби понял, что гораздо круче запустить не свой магазин сноубордов, а целую платформу для других магазинов.

    Тобиас Лютке — наш фаундер, он все еще является СЕО. Его можно встретить в офисе, все эти пятнадцать лет он работает над Shopify. Компания началась с Rails, и в ней работают люди, которые искренне любят этот фреймворк. Они видят, как быстро смогли построить на Rails то, что они хотели. Видят, как быстро разработчики могут что-то делать, экспериментировать и доставлять в продакшен.

    Я не думаю, что в компании когда-то серьезно рассматривали варианты перехода на что-то другое. На мой взгляд, веб-приложения все равно будут упираться в базу. Сходить куда-то, взять что-то, переформатировать это, склеить шаблон, положить в кэш и потом отдать результат. На это уходит большая часть времени. Rails прекрасно подходит для рендеринга страниц за 100-300 миллисекунд. Конечно, если нужно рендерить за 8-10, то придется выбрать что-то более быстрое, например, Go. В компании есть отдел, который занимается инфраструктурой, масштабированием и исследованием направлений роста с нашими текущими технологиями.

    Как решаете проблемы с масштабированием и высокими нагрузками?

    У нас очень типичный стек: Rails, MySQL, Memcache, Redis. Наверняка, ты работал с таким на многих проектах. Где-то в 2014 году, когда компании было 10 лет, мы поняли, что все необходимое уже не лезет в одну базу данных. Можно покупать более мощное железо для сервера MySQL и расти вертикально, но всему есть предел.

    Тогда мы решили, что шардинг поможет расти горизонтально. Как SaaS, где данные одного магазина не пересекаются с данными другого, мы можем организовать шардинг довольно просто. Никогда не придется делать join между двумя разными магазинами. С нашей моделью шардинга, на одном шарде живут тысячи магазинов разного размера и разной нагрузки. Шард включает в себя не только сущность базы данных, а также свой Redis, свой Memcache и так далее. За счет полной изоляции между шардами мы разбиваем весь Shopify на сотни маленьких Shopify. Каждый может хостится в отдельном регионе, датацентре, провайдере, в отдельной юрисдикции. Если у тебя 100 шардов, и на одном из них что-то упало, это затронет всего 1% клиентов. Это очень немного, если сравнить с ситуацией, когда при падении одного ресурса на всех падает все.

    Это и есть горизонтальное масштабирование с помощью шардинга. И шардинга не только одного, самого главного ресурса (базы данных), а изоляции всех компонентов, которые используют магазины. Дальше появляются интересные проблемы. Например, на каком-то шарде больше магазинов, где много трафика, а на каких-то меньше. На каких-то больше нагрузки, а на каких-то меньше. Приходится решать проблемы балансировки магазинов внутри шарда.

    Вы мигрируете магазин из одного шарда в другой?

    Когда нужно решить такие проблемы — да. У нас есть тулинг, который я подробно опишу в докладе. Будет рассказ о том, как мы пришли к этой схеме, как работает шардинг, как такой подход может применяться не только к нашему бизнесу, но и к другим. Нам пришлось самим разработать тул для миграции магазинов между шардами и датацентрами. В основном, миграция нужна для ребалансировки.

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

    На конференцию приезжает Yukihiro Matsumoto. Что бы ты хотел у него спросить?

    Сначала опишу контекст, чтобы мой вопрос был более понятен. Насколько я знаю, разработка Ruby — это несколько индивидуальных личностей, меньше десяти человек, среди них не более пяти ключевых. Большинство — японцы, которые очень давно этим занимаются. Кто-то из них может в одиночку реализовать такую мажорную фичу, как, например, guild или аннотации типов. Все завязано на этих людей. И если один человек, которого спонсирует Cookpad или Heroku, реализует ключевую фичу определенным образом, то именно такой она и будет. Но есть bus factor.

    На мой взгляд, самые большие продвижения в Ruby, которые происходили за последние пару лет, были инициированы большими компаниями, так как большие проблемы невозможно решить в одиночку. Например, Stripe нанимает людей, которые занимаются разработкой типизированных языков программирования, и дает им год на исследование. Так получается Sorbet, который является не просто способом тайп-чекинга, а целой парадигмой, его можно масштабировать, его документация построена на опыте сотен человек внутри Stripe. И таких примеров масса. Oracle спонсирует Truffle, и несколько людей работают над созданием виртуальной машины следующего поколения, переиспользуя часть виртуальных машин, которые уже были разработаны на протяжение десятков лет, десятками умных людей внутри Oracle.

    Я бы спросил Маца о том, насколько он верит в реалистичность решения больших проблем Ruby силами небольшой группой индивидуальных контрибьюторов. Насколько такая модель может конкурировать с примерами, когда проблемы решались при помощи крупного спонсора.

    Обсудим на конференции!

    Напомним, что она состоится 28 сентября в Москве, все подробности и регистрация на сайте.

    Нас поддерживают:

    Организатор — Evrone
    Генеральный партнер — Toptal
    Золотой партнер — Gett
    Серебряные партнеры — Валарм, JetBrains, Bookmate и Cashwagon
    Бронзовый партнер — InSales
    RubyRussia
    0,00
    Конференция разработчиков на Ruby и RoR
    Поделиться публикацией

    Похожие публикации

    Комментарии 25

      0
      Уже не первый раз вижу, что на руби с пыхи убежало не мало людей после опыта с вордпрессами и битриксами… бичи языка
        0
        Да, прибегут обратно. На Ruby работы все меньше и меньше в РФ. Только всякие легаси проекты времен 2012 года. В США любят рельсы, а РФ и Европа — мертвое поле.
          0
          Даже удивительно как я умудряюсь находить по удаленке свежие руби проекты в рф //sarcasm

          На php писать тошно.
            0
            Да, я не говорю, что работы прямо нет. Кто-то и на Коболе в 2019 работает. Я к тому, что тенеденция такова, что Ruby не вызывает «сексуальное влечение» у новых фаундеров, и число проектов, предложений пр работе уменьшается в РФ и Европе.
              0
              Значит работать зарубеж.
                0
                но в США, в США Руби на хорошем счету
                0

                А я на PHP перешел именно с Ruby, экосистема PHP мне кажется на порядок более зрелой.

                  +1
                  А дело не в экосистеме, руби лаконичный и красивый, в нем в паре строк выразительно можно написать то что в php сделаешь за 10 (и не так читабельно). Что касается экосистемы то и там и там стабильно, если не считать что в php зоопарк технологий, а в рубях в основном только Rails.
                    0
                    я большой фанбой питона, но когда на php(symfony) предложили на 40к больше, чем на том же уровне на Питоне — мне как-то не западло написать 10 строчек, вместо 2-3 -)
                      0
                      Вам не западло — мне западло писать грязь. Да и на питоне вы могли найти бы столько же.
                        0

                        Но при этом на рельсах пишете? Он, мягко говоря, с запашком и красота самого языка это не перебивает.


                        Вы пробовали строгие фреймворки, напрмер Spring или Symfony?
                        В ruby и python нет чего-то подобного. И поэтому мой путь с них (на обоих работал) в сторону php считаю оправданным.
                        Еще мог идти в сторону java, но я выбрал php ввиду большего количества удаленной работы.

                          0
                          Вы пробовали строгие фреймворки, напрмер Spring или Symfony?


                          А причем тут фреймворки если сам язык с запашком? банальный array_map который играючи делается в рубях — в пхп километровый. И фреймворк это не перебьет.

                          Но при этом на рельсах пишете? Он, мягко говоря, с запашком и красота самого языка это не перебивает.

                          Скорее на рубях, по минимуму используя функционал Rails (иногда он здорово экономит время). Он также с запашком как и все остальные фреймворки, строго говоря.

                          В php статическая типизация есть?

                          P.S. Уж лучше на Java писать чем на php, там хоть статическая типизация из коробки, пусть он и чертовски многословный.
                            0

                            Нет технологий без запашка. Просто он разный и в разных типах проектах по разному проявляется.
                            Более того, запашок может быть даже не от языка и фреймворков, а от устоявшихся в сообществе практик.
                            Человек, оценивая субъективно, пытается выбрать технологию, где запах применительно к его задачам минимальный. К примеру, если мне надо что-то на коленке сделать, то я не побрезгую AR моделями, но в что-то покрупнее пары человекомесяцев этот паттерн точно не потащу.


                            Он также с запашком как и все остальные фреймворки, строго говоря.

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


                            В php статическая типизация есть?

                            Есть, в виде type declarations. И она реально применяется в проектах — откройте практически любую свежую популярную библиотеку.

                              0
                              Есть, в виде type declarations

                              Это не статическая типизация. Я говорю про точную проверку в условном CI что везде типы совпадают, вроде typescript. Кроме того type declarations бедны, я не могу как в том же typescript указать несколько вариантов возвращаемых типов.

                              P.S. Я прямо сейчас копаюсь в php воркере, кодить на нем неудобно, статической типизации тоже нет, код многословный, слабо читабельный (по синтаксису). Скорее всего это будет последний проект который я трогал на php.
                                0
                                Я говорю про точную проверку в условном CI что везде типы совпадают, вроде typescript.

                                Конечно в PHP это есть, и оно работает как в IDE в реальном времени, так и в CI (phpstan, например).
                                Со старым и плохим кодом работает плохо (если типы не указаны, или много смешанных типов), с актуальным кодом работает отлично.
                                И это частный случай статической типизации.


                                я не могу как в том же typescript указать несколько вариантов возвращаемых типов

                                В PHP сейчас это делают на уровне phpdoc и сейчас обсуждают это на уровне синтаксиса: https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-union-types-v2.md
                                Я категорически против такой возможности, считаю такой подход грязным.


                                кодить на нем неудобно, статической типизации тоже нет

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

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

                                  Кодить на пхп неудобно именно благодаря синтаксису.

                                  Впрочем нам наверное нет смысла спорить, это все субъективные ощущения.
                                    0
                                    Средний уровень разработчиков благодаря джумлам, битриксам и вордпрессам не изменился.

                                    А почему вы из в PHP-разработчики записываете? Они пользователи.


                                    Кодить на пхп неудобно именно благодаря синтаксису.

                                    Вы же не пробовали современный PHP, судя по вашим вопросам.


                                    Да, согласен, что спор надо завершить. Я попробовал оба мира, но не смогу объяснить проблемы чего-то человеку, который пробовал только это.

                                      0
                                      А почему вы из в PHP-разработчики записываете? Они пользователи.

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

                                      Я так то, вообще начинал с php и даже сейчас ковыряю конкретный php проект. Убежал на руби в свое время и с тех пор предпочитаю подобного рода вещи писать на нем, ибо проще и выразительнее (и легаси меньше).

                                      Расскажите как современные php разработчики делают array_map тогда уж.
                                        0
                                        Я говорю про тех кто делает правки к этим движкам, они по определению не пользователи.

                                        Приведу пример из моего детства. То, что я отредактировал lua-плагин к игре, не делает меня разработчиком этой игры. Так же это не делает меня lua-программистом.


                                        Вордпресс — это не разработка. Эпизодическое ковыряние в коде шаблонов и расширений не делает из вебмастера PHP-разработчика. Это не основная деятельность человека.


                                        и даже сейчас ковыряю конкретный php проект

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

                                          0
                                          Так же это не делает меня lua-программистом.

                                          А что делает? ))) Внезапно написание плагинов на amxmodx для cs 1.6 таки делает вас amxmodx программистом, как и здесь.
                                          Вордпресс — это не разработка

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

                                          Я бы сказал что и то и то, но дело то даже не в этом, дело в php синтаксисе.

                                          Все еще жду пример array_map.
                            0
                            Но при этом на рельсах пишете? Он, мягко говоря, с запашком и красота самого языка это не перебивает.

                            Тут хоть только фреймворк с запашком, его можно и заменить на Roda или Sinatra, да и Hanami уже более менее пригодный. А вот когда в самом языке уже запашок уже совсем не свежий, то с этим уже ничего не поделать если так и будут цепляться за обратную совместимость. Да и snake_case намного приятней, чем camelCase :)
                0
                а теперь подумайте, почему битрикс и wp еще не на руби.И в статье здесь тонны легаси выдаются за фичи и наши преимущества. При этом с моей точки хрения вся статья крутится вокруг вакансии руби разработчика с релокацией в Канаду. Вот тебе и немало ушедших на руби людей.
                  +2

                  А было что-то на PHP в 2006-2008 годах, что нельзя назвать бичами языка? Drupal, Joomla были ещё хуже, чем Wordpress. Скорее тут дело даже не в языке, а в сложившихся в те годы подходах к разработке, которые и породили всех этих монстров. Поэтому Rails тогда был глотком чистого воздуха. Сейчас уже и в самом Rails очевидны архитектурные изъяны, но это совсем другая история.

                    +1
                    Я начал программировать в начале 2017 года :) Как и пара ребят, о которых я говорил… Просто Битрикс (конкретно он стал «мотиватором» сбежать) есть и сейчас :)
                    Я этих всяких систем не касался
                      0

                      Ну, если Битрикс не переписали свой код с нуля, а оставили примерно таким же, как в 2007-м, то в 2017-м его читать уже было чревато культурным шоком :)

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

                Самое читаемое