Представляем пятый выпуск подкаста о технологиях, процессах, инфраструктуре и людях в IT-компаниях. Сегодня в гостях у “CTOcast” — Джин Бармаш (технический директор компании Merchantry, сооснователь митапа CTO School) и Евгений Бабкин (руководитель группы разработки в Merchantry).
О наших собеседниках:
Джин Бармаш учился в колледже Cooper Union (1995--1999), Нью-Йорк. В период с 1999 по 2009 годы работал в компаниях Trilogy Software, Symantec, Infusion Development и Alfresco, пройдя путь от software-инженера до технического директора. В 2009 году основал компанию EnergyScoreCards (сервис для сравнения энергетической эффективности зданий). На сегодняшний день является техническим директором в компании Merchantry (SaaS-платформа для электронной коммерции).
С 2006 активно участвует в менторских программах и акселераторах для технологических стартапов. Является сооснователем и организатором митапа CTO School (Нью-Йорк), который представляет собой сообщество технических лидеров, насчитывающее более 1600 членов.
Евгений Бабкин окончил Новосибирский государственный университет (2004), где с 2000 года работал в качестве инженера по инфраструктуре. С 2005 года — в компании Икстенс. На сегодняшний день является руководителем группы разработки, которая работает над SaaS-платформой электронной коммерции для Merchantry.
Текстовая версия подкаста
Александр Астапенко: Джин, расскажи, пожалуйста, немного о себе и своей карьере.
Джин Бармаш: Начинал свою карьеру я в компании Trilogy в Остине (Техас). Тогда был самый разгар стартапов первой волны, 1999-й год, и мы все в этом соусе варились. Потом несколько лет я занимался консалтингом, тренингами, делал всякие интересные и не очень интересные вещи.
В какой-то момент решил, что все я про эти стартапы думаю и мечтаю, поэтому пора бы что-то конкретное делать. Alfresco—open-source приложение для менеджмента контента—был моим первым полноправным стартапом. Я там был где-то 70-м человеком. После этого—EnergyScoreCards, где я стал уже основателем, а мой приятель был экспертом по энергетическому использованию жилых зданий.
Последние полтора года руковожу технологиями в Merchantry. Поскольку, кроме главы нашего продукта, я единственный технический человек в команде в Нью-Йорке, то моя роль заключается в том, чтобы понять, что бизнес от нас хочет и преподнести это нашим техническим командам как можно эффективнее, иногда выстроить какую-то техническую стратегию. И, с другой стороны, понять, что нужно технической команде. Вторая часть моей работы—это наш data-центр и все, что там происходит.
Александр Астапенко: Женя, а как ты попал в Merchantry? Чем занимался до этого?
Евгений Бабкин: Я начинал работать и учиться в самом начале 2000-х годов. Если кто-то помнит, в это время был кризис и все было достаточно сложно. Точнее, в 1998-м году я начинал. Работал админом и на мне была какая-то часть инфраструктуры университета, а также было несколько мелких компаний, где я делал все, что нужно.
Время шло, и в какой-то момент я устроился Java-разработчиком в компанию Икстенс, где мы делали большие электронные магазины. Тогда была очень популярна enterprise-платформа Intershop. И вот на этой платформе для клиентов из США и Европы мы делали, как это тогда называлось, интернет-порталы, где осуществлялась e-сommerce того времени.
Потом наши клиенты захотели интеграции с Amazon, чтобы продавать, в том числе, и там. С этого момента изменилась и компания, и продукт. Мы стали делать интеграцию с Amazon, затем с eBay. У нас появилась собственная платформа, которая занималась этими интеграциями для клиентов самого разного размера. События начали развиваться еще более интересно: мы стали консультировать тех, кто хотел себе сделать свой собственный небольшой Amazon, свой marketplace. В какой-то момент мы начали делать свой продукт, платформу, которая позволяла любому более-менее крупному ритейлеру сделать себе Amazon. Сейчас мы идем немного дальше и хотим занять другую нишу на рынке, поэтому продукт под это дело тоже меняется.
Я начинал как разработчик, потом был аналитиком. А сейчас мы в паре с Джином работаем над текущей версией платформы. Один и тот же продукт писался много лет, и когда при этом меняется сегмент рынка, меняется бизнес, то получаются достаточно причудливые наслоения, с которыми потом очень интересно иметь дело.
О компании Merchantry
Александр Астапенко: Чем занимается компания Merchantry? Хочется понять в чем заключается бизнес прежде чем мы будем говорить о технической части. Кто клиенты? Когда компания появилась?
Джин Бармаш: Компания была основана примерно десять лет назад. Первые шесть-семь лет мы в основном занимались консалтингом. Работали на больших клиентов и делали им клиентские приложения. Примерно три-четыре года назад мы взяли деньги у инвесторов и сказали, что будем строить платформу.
Первоначально мы строили платформу для marketplaces, чтобы делать онлайн рынки. Что для этого нужно? Во-первых, иметь возможность взять продукты у поставщиков и интегрировать их через, например, API. Это дает возможность импортировать продукты в нашу платформу и потом экспортировать их на клиентов, которые имеют marketplace. Покупатели идут на marketplace и видят продукты от разных поставщиков. Когда они покупают эти продукты, через какое-то время к ним приходит посылка, которая может состоять, скажем, из 5 разных вещей от 5 разных поставщиков. В первой части мы должны моделировать, синхронизировать и описывать продукты. Или, более конкретно, давать нашим поставщикам инструменты, чтобы это делать. Затем синхронизировать это на marketplace, и когда приходят заказы, правильно доставлять эти заказы электронным способом поставщикам. Это marketplaces.
То, что мы делаем сейчас называется product information management. Это выглядит, честно говоря, очень-очень похоже. У нас есть платформа, где поставщики могут добавить свои продукты, и мы эти продукты позволяем экспортировать в их магазин. Когда приходят заказы, то мы эти заказы даем поставщикам, синхронизируем информацию (какой пакет и когда выслан, какой номер у этого пакета) и позволяем отменить заказ.
Павел Павлов: Какими силами удалось построить такой продукт? Как структурирована команда? Где находится?
Евгений Бабкин: Сейчас над основной платформой работают 13 человек. Фактически, они представляют собой одну команду. Нельзя сказать, что это команда переросток, но что-то такое похожее. В разное время численность разработчиков, тестировщиков и всех, кто работал над платформой и ее интеграцией, достигала, наверное, 100 человек. Сейчас то, что мы делаем, и то, как мы работаем, немножко похоже на scrum. Чистый scrum у нас мало возможен, потому что владелец продукта находится достаточно далеко от нас и говорит на английском языке, а команда разработки на английском языке не очень хорошо говорит. У нас есть спринты, также, благодаря Джину, достаточно хорошо развился continuous integration.
Павел Павлов: Можешь рассказать сколько человек в команде разработчиков? Техническая поддержка?
Джин Бармаш: В Новосибирске работают примерно 30 человек. Как сказал Женя, 13—на главной разработке. Также 5--6 человек работают на professional services, консультанты, которые поддерживают свой продукт для интеграции. Поддержка у нас состоит из 6--7 человек. Они говорят с клиентами, смотрят на системы и так далее. И 3--4 человека занимаются DevOps: следят за нашим data-центром, делают трансформации и миграции.
О технологиях
Павел Павлов: Раз уж зацепили эту тему, можете рассказать о вашем data-центре? Где вообще находится и разворачивается платформа?
Джин Бармаш: Сейчас у нас два главных data-центра. Есть такая компания Connectria в Сент-Луисе (Миссури) с хорошим уровнем сервиса—там находится наш главный продакшн. У нас также есть второстепенный data-центр в OVH, в Монреале, Канада. Мы используем его в основном для внутренних систем. Плюс там же находятся несколько продакшн-систем. И еще у нас есть географический failover в Amazon Web Services (AWS) на случай если метеорит упадет в Миссури.
Павел Павлов: А почему не используете Amazon в качестве основной платформы?
Джин Бармаш: Несколько причин. Частично, потому что так сложилось. У нас довольно большая нагрузка идет, и мы считаем, что более экономично использовать свое железо. Каждый раз, когда мы смотрели на цены Amazon, они были существенно выше, особенно на то железо, которое нам требуется. В принципе, мы могли бы перейти на Amazon, но потребовалась бы довольно большая трансформация, потому что у нас уже все сделано, у нас железо. С другой стороны, это бы и стоило существенно дороже, чем мы платим сейчас, а мы уже платим не мало.
Александр Астапенко: Джин, ты общаешься с довольно большим количеством технических лидеров в рамках CTO School. Если говорить о подходах к инфраструктуре, является ли сейчас общей тенденцией для сервисов с большими нагрузками использование data-центров, несвязанных с известными cloud-провайдерами типа AWS? Или все же люди склоняются к cloud-сервисам?
Джин Бармаш: В основном склоняются к cloud-сервисам. Еще я хочу заметить, что у нас нагрузка довольно стабильная. Она может быть большая, но нет такого, что в следующем месяце нагрузка будет в 5 раз больше и нужно в 5 раз больше серверов. Так что мы можем делать очень конкретное планирование мощностей и облако нам не дает тех преимуществ как, например, другим компаниям. Начинающие стартапы, конечно, делают на облаке. Используют Amazon или что-то вроде Heroku, которым я тоже пользовался почти год. Он жутко удобный, особенно если делаешь такие вещи как Ruby on Rails. Тебе не надо думать про deployment вообще.
У нас довольно сложная инфраструктура: есть свой FTP, email-сервер, LDAP для пользователей и так далее. Поэтому иметь все клиентское для нас работает неплохо. Да и изначально полный контроль над железом был очень удобен.
Евгений Бабкин: Мы подходим к инфраструктуре примерно так же, как это принято делать в облаках. Когда мы что-то разворачиваем, то все это автоматизировано. Наши тестовые среды и наши продакшн-среды в настоящее время уже достаточно похожи. То есть с этой точки зрения неважно облако или не облако, свой собственный . Везде надо смотреть нагрузку, надо смотреть на SLA.
Джин Бармаш: Да, Женя полностью прав, у нас много автоматизации. Сontinuous integration дает автоматизацию, Puppet, который позволяет разворачивать кластеры, у нас Docker, который может поднимать сервисы очень быстро. Сейчас мы заканчиваем миграцию на Docker и тогда вообще все станет унифицировано. Разработчики смогут разворачивать полноценные мастера, которые на 100% такие же, как и в продакшене.
Павел Павлов: Вопрос о переходе на сontinuous integration и внедрении Docker. Как внедряли? Каким образом это помогло решить проблемы?
Джин Бармаш: Мы к Docker подошли со стороны сontinuous deployment сначала. Что такое сontinuous deployment? Это когда каждый коммит диплоится на продакшн. Нам не нужен каждый коммит, поэтому мы делаем один раз в день.
Процесс миграции на сontinuous deployment он с Docker контачит, потому что Docker помог изолировать наше окружение в тестовой среде и обеспечить 100%-изоляцию между разными тестами. Это значит, что мы можем разные ветки полностью отдельно друг от друга тестировать. Каждый разработчик сидит на своей ветке и полноценно прокручивает все тесты.
Павел Павлов: А с чем был связан ваш переход на Docker?
Джин Бармаш: Честно говоря, у нас не было огромной проблемы, которую мы решали в момент перехода на Docker. Посмотрели, что есть новая технология и вроде бы она нам подходит. Что такое Docker? Это Linux в контейнере, который дает легковесную изоляцию между разными серверами. То, что дает VMware, но с меньшими издержками.
Когда мы достаточно неплохо познакомились с технологией, то стали думать, а как нам перейти на continuous deployment. И Docker стал одним из инструментов, которые мы использовали, чтобы это реализовать.
Павел Павлов: Такой переход нужно было согласовывать с бизнесом? Или люди, которые инвестируют в проект, на подобные вещи и не смотрят?
Джин Бармаш: Деньги на Docker просить не надо было, поскольку это open-source проект. Технология работает и делает наш DevOps эффективным. Почему бы ее и не применить?
Когда мы переходили на continuous deployment, вот тогда уже нужно было объяснять бизнесу, потому как все менялось. На это надо было отвлечь главную команду разработчиков и очень много вложить в тесты. У нас и так были неплохие тесты, но мы подключили разработчиков к написанию функциональных тестов. И надо было сказать бизнесу, что следующие две недели команда будет делать что-то другое. И, соответственно, когда ты им эти вещи говоришь, они спрашивают: «А что они будут делать?» И ты объясняешь, что процесс меняется, что цель это улучшить качество, делать релиз быстрее. Женя, расскажи, как это выглядело. Ты был намного ближе.
Евгений Бабкин: Да. Я хотел бы эту тему с другой стороны раскрыть. Писали мы эту платформу достаточно долго. Нам приходилось иметь дело с enterprise-клиентами, у которых особые какие-то требования к качеству, и поэтому нам хотелось достичь стабильности платформы. Мы знали, что для этого нужно делать, и когда мы осуществили очередную смену, то стали писать автоматические тесты. То есть у нас все тестирование дублировалось автоматизацией. Понятно, что все автоматизировать невозможно, но автоматизировалось многое.
По-большому счету, сейчас у нас есть два уровня тестов. Это классические GUnit-тесты и интеграционные тесты Selenium, которые тоже запускаются через GUnit и работают через внешние интерфейсы-приложения, через симуляцию браузера и так далее.
Мы написали массивный набор тестов. Естественно, были проблемы с тем как долго они выполняются. А выполнялись они долго. С этим приходилось как-то жить. У нас был TeamCity как интеграционный сервер, несколько машин, которые были серверами и на которых мы все это дело разворачивали. Беда была в том, что мастер постоянно был разобран. Переход на Docker позволил решить эту проблему, потому что сейчас мы очень быстро и легко разворачиваем приложение с нуля для любого бранча, наполняя его данными и прогоняя тесты. Парадигма работы изменилась полностью. Теперь у нас действительно всегда стабильный мастер. То есть докеры кардинально изменили тот уровень качества, который мы имеем. Теперь не нужно идти на всякие компромиссы, когда релиз нужен послезавтра и когда не очень страшные баги не являются багами вообще, потому что деться-то некуда. Это все уже в прошлом.
Александр Астапенко: Джин, правильно ли я понимаю, что мануального тестирования у вас нет вообще? То есть все тесты—функциональное тестирование?
Джин Бармаш: Нет, это неправильно. У нас есть три тестера: один полноценно работает на автоматизации и два комбинированно тестируют вручную и помогают с автоматизацией.
До перехода на continuous delivery наши тестеры делали тесты только вручную, но был один человек, который гнался за командой и пытался делать автоматизацию тестов. Он всегда отставал, так как было 9 разработчиков, а он один. Получалось, что много фич не имели автоматизации. Из-за того, что он всегда отставал у нас регресс появлялся только через несколько недель после первоначального релиза. Это было неприятно. Поэтому мы подключили разработчиков к написанию тестов.
Александр Астапенко: Ясно. Женя, что-нибудь еще добавишь?
Евгений Бабкин: У нас нет ручного регресса. Вот так правильно говорить. У нас есть мануальное тестирование, потому что все автоматизировать очень дорого. Как, собственно, автоматизировать, так и потом прогонять эти тесты каждый раз. Но регресс полностью проходит автоматически. Каждая новая фича тестируется вручную.
Так сложилось, что набор Selenium-тестов начинали писать тестировщики и писали они их как умели. Поэтому в какой-то момент мы стали подключать к написанию тестов разработчиков, что сделать непросто. Потому что разработчики не очень хотят, им тяжело работать с тем кодом, который предыдущие два года писали тестировщики. Они хотят переписать практически весь код, а никто им не дает. Если бы я это делал второй раз, наверное, сделал бы так, чтобы разработчики с самого начала писали тесты по кейсам, которые дают тестировщики. Тогда было бы дешевле и чуть быстрее.
О CTO School
Александр Астапенко: Я уже кратко упоминал в начале нашего подкаста CTO School Meetup. Слышал от нескольких людей об этом митапе, но до сих пор мало о нем знаю. Что такое CTO School Meetup?
Джин Бармаш: Это простой митап в Нью-Йорке. Хотя есть один сейчас и в Австралии, Мельбурне. Мы просто собираемся один раз в месяц, иногда два раза в месяц, и пытаемся говорить на разные темы, о том, как стать лучшим техническим лидером.
С моей точки зрения, для этого нужна компетенция в трех сферах: технологии, нужно понимать различные процессы разработки, чтобы люди друг с другом работали эффективно, а также нужно быть лидером, чтобы мотивировать людей, проводить интервью и так далее. Когда мы собираемся, я пытаюсь балансировать разные темы по всем этим направлениям.
Надеюсь, что когда люди приходят к нам, то они чему-то учатся. У нас есть большое собрание, обычно один раз в месяц, когда кто-то готовит выступление на определенную тему: как нанимать людей, как оптимизировать процесс. Примерно 100--150 человек приходит. Есть еще и второй тип собраний. Это примерно 20 человек. Мы сидим вокруг стола и делимся опытом в более интимной обстановке. Еще у нас есть лист, где люди задают вопросы, а другие на них отвечают.
Я занимаюсь митапом 4 года и мне это очень интересно, помогает набраться опыта от других людей. И думаю, что людям тоже интересно узнать какие проблемы у других.
Александр Астапенко: Джин, на самом деле гениальная идея. Если бы у меня была возможность привлекать лучшие технические умы Нью-Йорка для решения своих проблем, это было бы круто. А о чем сейчас говорят технические лидеры на Ист Косте? Я так понимаю, что помимо тематических выступлений идут же какие-то разговоры в кулуарах. Какие темы сейчас горячие?
Джин Бармаш: Что такое горячее трудно сказать, потому что у каждой компании свои проблемы. Темы, которые за последние год-полтора развиваются, это DevOps, инженерная культура и философия инженерных команд. Вот я недавно интервьюировал CTO Etsy (marketplace для ручных изделий). Эту компанию очень уважают в Нью-Йорке. У них оборот, наверное, уже пару миллиардов на текущий момент. В компании работают около 215 инженеров. И у них такая философия: мы пишем PHP и такие очень скучные технологии, с одной стороны, a с другой—нам не надо сидеть и думать какие новые технологии применять. Новые технологии тяжело поддерживать, потому что они новые и они меняются. Кстати, основатель PHP у них работает, что тоже помогает.
А с другой стороны есть Gill, которые делают микросервисы. Микросервисы, Docker и event-driven архитектура становятся очень популярными. По технологии можно сказать, что Node.js поднялся на ноги сейчас в Нью-Йорке и еще Go начинает быть популярным.
Александр Астапенко: Пару слов в завершение нашего подкаста?
Джин Бармаш: Во-первых, большое спасибо, что нас пригласили. По своему опыту организации митапов я бы сказал, что если есть тема, которая действительно интересна людям, то в любом месте можно ее развернуть. Я знаю, что у Жени есть группа технических лидеров в Новосибирске, в которой он участвует. Тот факт, что в Нью-Йорке много людей, он конечно помогает. Но если есть интерес, это можно поднять везде. Для хорошей дискуссии тебе не нужна 1 000 человек. Тебе нужны 10, которые умные и которые разбираются в том же, что и ты. Даже меньше 10—тоже нормально.
Евгений Бабкин: На самом деле мне очень приятно, что появляются такие русскоязычные встречи как CTOcast. Очень часто можно услышать, что русские разработчики одни из самых лучших разработчиков в мире. Понятно, что мы все прекрасно понимаем английский и можем делать на английском выступления, но слушать их на русском все равно очень приятно.
Автор: ViktoryiaFedzkovich
