Conduit — компания, основанная в Израиле, являющаяся ведущим мировым поставщиком платформ тулбаров для браузеров.
Система обслуживает 200 000 паблишеров и 70 000 000 пользователей в режиме 24×7. Перед такими системами остро стоит вопрос масштабируемости, надежности и эффективности.
Ранее Игорь был разработчиков в самарской компании «НПК „Генезис Знаний“». В свободное время Игорь ведет блог. Блогерский стаж — 6 лет
- Дима Фитискин, организатор конференции:
- Проблема масштабируемости и устойчивости систем при высоких нагрузках очень узка и специфична, поэтому вопросов сегодня не так много. Перейдем к ответам.
- Екатерина Лосевская:Привет, Игорь, не скучаешь по Родине? А по ГЗ?
Расскажи несколько подробнее, что именно делаешь ты, какие веб-сервисы? - Игорь Шапиро:Катя, привет! Во-первых, спасибо за вопрос, особенно за то, что он первый.
Если честно, скучать не получается. Может, на пенсии этим займусь. Зато всегда есть что вспомнить — и улыбнуться. Особенно ГЗ :) Кстати, поздравляю всех разработчиков с новоявленным профессиональным праздником!!!
Теперь о моей работе: команда, в которой я работаю разрабатывает, практически, все веб-сервисы с которыми работает тулбар, установленный у пользователя в браузере. Собственно, именно эти сервисы объясняют серой горизонтальной полоске — как стать полезным тулбаром. Также, наша комманда отвечает за внутреннюю инфраструктуру всех приложений: конфигурация, хранение данных, серверное представление тулбара.
- Екатерина Лосевская:Игорь, поскольку у тебя есть опыт работы в зарубежной компании, более того, работы именно за рубежом, скажи, пожалуйста, чем отличается процесс разработки в отечественных и зарубежных компаниях, с точки зрения организации процесса, а также, есть ли какие-то другие отличия?
- Игорь Шапиро:Если честно, процесс разработки и здесь (в Израиле) и в России — мало чем отличаются. Все как обычно — более прибыльные компании могут себе позволить нанимать профессиональных продакт-менеджеров, разделять разработку на комманды (System team, Architecture team, Design team, Web team, Infrastructure team, Web Services team, Business Intelligence и т.п.). Еще неприбыльные компании или стартапы — не могут себе позволить такое количество сотрудников — потому, часто один человек может выполнять работу от проектирования до разработки.
Основное отличие, на мой взгляд, это отношение к персоналу. Например, здесь затраты на содержание персонала составляют однозначно большую часть затрат компании: з/п, лизинговая машина+бензин, различные страховки (увольнение, потеря трудоспособности, дополнительная пенсия, другие накопительные фонды), оплата питания и, наконец, предоставление опций/акций компании. Как я уже отметил, эти затраты несоизмеримо больше расходов на аренду офиса, поливальщиков цветов в офисе, покупку серверов и все остальные оперативные расходы.
Результат предсказуем: в офисе я могу сосредоточиться на своей работе, не особо отвлекаясь на житейские проблемы. Производительность больше, результат лучше — компания может тратить больше денег на меня любимого :)
Особо стоит отметить роль акций — их роль исключительно мотивирующая :)
- Антон Косов:Привет, Игорь.
Расскажи о масштабируемости. Какими средствами решаете проблему? И как стоит себя вести разработчику, чтобы облегчить вам работу.
Спасибо. - Игорь Шапиро:Хороший вопрос! Короткий ответ будет звучать так: SOA (Service Oriented Architecture) + REST (REpresentation State Transfer).
Теперь подробнее.SOA позволяет нам грамотно разбить систему на автономные подсистемы. Автономность этих подсистем упрощает мониторинг бизнес процессов всей системы в целом, а также помогает определять узкие места и соответственно принимать решения — либо оптимизировать конкретную подсистему, либо наращивать для нее ресурсы (например, добавить сервер). Таким образом, SOA решает для нас проблему масштабируемости на уровне подсистем.
REST позволяет нам эффективно использовать кэширование, а следовательно, CDN (Content Delivery Networks). Следовательно, REST решает для нас проблему масштабируемости системы на уровне взаимодействия с внешним миром (конечными пользователями).
- Яков Акулов:Я недавно познакомился с сервис-ориентированной технологией, увлекся, но до конца еще не во всем разобрался. Но меня больше всего интересуют перспективы данной парадигмы разработки ПО, что ждет SOA в будущем по вашему мнению?
- Игорь Шапиро:Яков, спасибо за вопрос. Прежде чем ответить на него, я хотел бы подчеркнуть, что SOA не ограничивается каким-то набором технологий — скорее, она определяет рекоммендации к построению архитектуры системы.
Однозначно не следует отождествлять SOA и веб сервисы (WS-I) в их сегодняшнем виде, хотя они и являются подмножеством SOA-решений. О перспективах: я считаю, что мелкие-средние системы будут продолжать использовать WS-I веб-сервисы, в первую очередь, из-за легкости их реализации.
Что же касается Enterprise систем, а также Web 2.0 сервисов, то уже сегодня очевидно, что они движутся в направлении SOA/EDA (Event Driven Architecture). Именно событийная модель (EDA) дает наилучшие результаты в масштабируемости, мониторинге, легкости поддержки и надежности систем.
- Денис Кишкин:Привет, Игорь! Расскажи-посоветуй, какие литературные источники помогают сейчас или помогли приобрести необходимый опыт для проектирования столь масштабных приложений? Как в ИзраИле обстоят дела с фанфуриками? :)
- Игорь Шапиро:Привет, Денис!
Есть очень много хороших книг. Все названия хорошо известны. Я не буду приводить их здесь — напишу попозже в блоге. Прочитав все (или часть) эти книги, ты сможешь легко написать любой отдельный модуль системы. Но это только половина дела. Проблемы наступают на стадии интеграции этих модулей в единое целое. Я не встречал литературы, которая бы это объясняла. Но однажды, к нам в компанию пришел товарищ Уди Дахан, который прочитал лекцию именно на эту тему. Лекция называлась «Распространенные ошибки реализации SOA». Эти 2 часа запомнятся мне на всю жизнь. После этой лекции, все что я знал, вдруг приняло совершенно конкретный вид, все проблемы, которые я считал данностью программирования, вдруг исчезли. Теперь хорошие новости, этот товарищ ведет блог на http://www.udidahan.com/?blog=true . Очень рекомендую. А с фанфуриками в Израиле плохо. Заменяем их виски и вином :)
- Марат:Что вы думаете о том, чтобы переводить «Senior Developer» на русский как «Сеньор Девелопер»?
- Игорь Шапиро:Марат, добрый день!
После перевода Application как «аппликация», а Implementation — как «имплементация», «Сеньор Девелопер» звучит очень даже достойно. Если честно, то я даже не могу припомнить в русском аналога Senior Developer. Так что пусть остается транскрипция.
- Дима Фитискин:
- Спасибо Игорю за участие в конференции и всем участникам за интересные вопросы. На этом конференция подходит к концу.
