Insight IT

Архитектура Pinterest

Иван Блинков — Wed, 15 Aug 2012 22:26:00 +0400

Pinterest - по непонятным для меня причинам популярная в определенных кругах социальная сеть, построенная вокруг произвольных картинок чаще всего не собственного производства. Как и Instagram проект довольно молодой, с очень похожей историей и стеком технологий. Тем не менее, Pinterest определенно заслуживает внимания как один из самых быстрорастущих по посещаемости вебсайтов за всю историю.

Платформа

Amazon AWS - хостинг и вспомогательные сервисы
nginx - вторичная балансировка нагрузки, отдача статики
Python - язык программирования
Django - фреймворк
MySQL - основная СУБД
memcached - кэширование объектов
Redis - кэширование коллекций объектов
Solr - поиск
Hadoop - анализ данных

Статистика

3 миллиона уникальных посетителей в день
18 миллионов уникальных посетителей в месяц
4-я по популярности социальная сеть в США после Facebook, Twitter и LinkedIn
Порядка 500 виртуальных машин в EC2
80 миллионов объектов в S3
410Тб пользовательских данных

Развитие

Март 2010

1 маленький виртуальный веб-сервер
1 маленький виртуальный сервер MySQL
Все это в Rackspace, 1 разработчик

Январь 2011

1 сервер nginx для балансировки нагрузки, 4 веб-сервера
2 сервера MySQL с master/slave репликацией
3 сервера для отложенного выполнения задач
1 сервер MongoDB
Переехали на Amazon EC2 + S3 + CloudFront

Осень 2011

2 сервера nginx, 16 веб-серверов, 2 сервера для API
5 функционально разделенных серверов MySQL с 9 read slave
Кластер из 4 узлов Cassandra
15 серверов Membase в 3 отдельных кластерах
8 серверов memcached
10 серверов Redis
7 серверов для отложенной обработки задач
4 сервера Elastic Search
3 кластера MongoDB
3 разработчика
Если кто-то может объяснить зачем им сдался такой зоопарк, кроме как потестировать разные варианты, можете взять с полки пирожок.

Зима 2011-2012

Заменили CloudFront на Akamai - вполне объяснимо, так как у Akamai намного лучше покрытие по миру, а качественный CDN для сайта с большим количеством изображений - чуть ли не залог успеха.
90 веб серверов и 50 серверов для API
66 + 66 MySQL серверов на m1.xlarge инстансах EC2
59 серверов Redis
51 серверов memcached
25+1 сервер для отложенной обработки задач на основе Redis
Кластеризованный Solr
6 разработчиков

Весна-лето 2012

Снова сменили CDN, на этот раз в пользу ранее неизвестного мне Edge Cast. Покрытие по всему миру довольно скромное, так что единственное логичное объяснение, которое мне приходит в голову - не потянули Akamai по деньгам.
135 веб серверов и 75 серверов для API
80 + 80 серверов MySQL
110 серверов Redis
60 серверов memcached
60 + 2 сервера для отложенной обработки задач на основе Redis
25 разработчиков

Выбор

Почему Amazon Ec2/S3?

Очень хорошая надежность, отчетность и поддержка
Хорошие дополнительные сервисы: кэш, базы данных, балансировка нагрузки, MapReduce и т.п.
Новые виртуальные машины готовы за считанные секунды

Почему MySQL?

Очень "зрелая", хорошо известная и любимая многими
Редки катастрофичные потери данных
Линейная зависимость времени отклика от частоты запросов
Хорошая поддержка сторонним ПО (XtraBackup, Innotop, Maatkit)
Надежное активное сообщество
Отличная поддержка от Percona
Бесплатна

Почему memcached?

Очень "зрелый", отличная производительность, хорошо известный и любимый многими
Никогда не ломается
Бесплатен

Почему Redis?

Много удобных структур данных
Поддержка персистентности и репликации
Также многим известен и нравится
Стабильно хорошая производительность и надежность
Также бесплатен

Архитектура

Сlustering vs Sharding

Большую часть презентации, на основе которой написана данная статья (ссылка, если не охота листать до секции источников информации), занимает раздел под названием "Clustering vs Sharding". В связи с путаницей в терминологии пришлось несколько раз перечитывать, чтобы понять к чему они клонят, сейчас попробую объяснить.
Вообще есть два фундаментальных способа распределить данные между несколькими серверами:
- Вертикально: разные таблицы (или просто логически разные типы данных) разносятся на разные сервера.
- Горизонтально: каждая таблица разбивается на некоторое количество частей и эти части разносятся на разные сервера по определенному алгоритму.
С первого взгляда казалось, что они пытаются вертикальное разбиение назвать sharding, а горизонтальное - clustering. Хотя вообще они почти синонимы и на русский я их обычно примерно одинаково перевожу.
По факту же оказалось, что под словом clustering они понимают все программные продукты для хранения данных, которые имеют встроенную поддержку работы в кластере. В частности они имеют ввиду Cassandra, Membase, HBase и Riak, которые прозрачно для пользователя горизонтально распределяют данные по кластеру.
За словом sharding в их терминологии стоит аналогичная схема собственной разработки, использующая огромное количество логических БД в MySQL, распределенных между меньшим количеством ~~физических серверов~~ виртуальных машин. Именно по этому пути и пошли в Pinterest, плюс очень похожий подход используется в Facebook.
От себя добавлю, что хоть при наличии должных ресурсов разработка собственной системы распределения данных и может быть целесообразной, в большинстве случаев на начальном этапе проще основываться на готовых решениях вроде перечисленных выше. К слову в opensource доступны и основанные на MySQL подобные решения:
- Vitess от Google / YouTube
- FlockDB от Twitter
В их проекте данная подсистема развивалась следующим образом:
- 1 БД + внешние ключи + join'ы →
- 1 БД + денормализация + кэш →
- 1 БД + master/slave + кэш →
- несколько функциональных разделенных БД + master/slave + кэш →
- вертикально и горизонтально разделенные БД (по идентификаторам) + по резервные БД (пассивный slave) + кэш
При использовании аналогичного решения остерегайтесь:
- Невозможности выполнять большинство запросов с join
- Отсутствия транзакций
- Дополнительных манипуляций для поддержания ограничений уникальности
- Необходимости тщательного планирования для изменений схемы
- Необходимости выполнения одного и того же запроса с последующей агрегацией для построения отчетов

Остальные моменты

Кэширование многоуровневое:
- Коллекции объектов хранятся в списках Redis
- Сами объекты - в memcached
- На уровне SQL запросы в основном примитивны и написаны вручную, так что часты попадания в кэш MySQL
- Кэш файловой системы - само собой
Еще пара фактов про кэширование в Pinterest:
- Кэш разбит также на несколько частей (шардов), для упрощения обслуживания и масштабирования
- В коде для кэширования используются Python'овские декораторы, на вид собственной разработки, хотя точно не уверен
Балансировка нагрузки осуществляется в первую очередь за счет Amazon ELB, что позволяет легко подключать/отключать новые сервера посредством API.
Так как большинство пользователей живут в США по ночам нагрузка сильно падает, что позволяет им по ночам отключать до 40% виртуальных машин. В пиковые часы EC2 обходится порядка 52$ в час, а по ночам - всего 15$.
Elastic Map Reduce, основанный на Hadoop, используется для анализа данных и стоит всего несколько сотен долларов в месяц
Текущие проблемы:
- Масштабирование команды
- Основанная на сервисах архитектура:
  - Ограничения соединений
  - Изоляция функционала
  - Изоляция доступа (безопасность)

Уроки от команды Pinterest

"Оно сломается. Все должно быть просто." - столько раз уже слышу это наставление, но ни разу не видел разработчиков, которые реально к нему прислушивались.
"Кластеризация - страшная штука." - конечно страшная, большая и сложная. Но кому сейчас легко?
"Продолжайте получать удовольствие." - с этим не могу не согласиться, без удовольствия работать совершенно невозможно в любой сфере.

Источники информации

Scaling Pinterest @ MySQL Meetup
- В презентации можно посмотреть примеры кода и SQL-запросов
- Если кто-то знает где можно посмотреть/послушать запись этого мероприятия - поделитесь ссылкой, пожалуйста
Pinterest Architecture Update
Вакансии в Pinterest

Новое поколение MapReduce в Apache Hadoop

Иван Блинков — Sat, 19 Feb 2011 21:23:00 +0300

В большом бизнесе использование нескольких больших кластеров с финансовой точки зрения более эффективно, чем много маленьких. Чем больше машин в кластере, тем большими наборами данных он может оперировать, больше задач могут выполняться одновременно. Реализация MapReduce в Apache Hadoop столкнулась с потолком масштабируемости на уровне около 4000 машин в кластере. Разрабатывается следующее поколение Apaсhe Hadoop MapReduce, в котором появится общий планировщик ресурсов и отдельный мастер для каждой отдельной задач, управляющий выполнением программного кода. Так как простой оборудования по техническим причинам обходится дорого на таком масштабе, высокий уровень доступности проектируется с самого начала, ровно как и безопасность и многозадачность, необходимые для поддержки одновременного использования большого кластера многими пользователями. Новая архитектура также будет более инновационной, гибкой и эффективной с точки зрения использования вычислительных ресурсов.

Предистория

Текущая реализация Hadoop MapReduce устаревает на глазах. Основываясь на текущих тенденциях в размерах кластеров и нагрузок на них, JobTracker требует кардинальных доработок, чтобы исправить его дефекты в области масштабируемости, потребления памяти, многопоточности, надежности и производительности. С точки зрения работы с Hadoop при каждом обновлении кластера (даже если это просто багфикс), абсолютно все компоненты кластера, так и приложений, которые на нем работают, должны быть обновлены одновременно. Это так же очень неудобно, так как каждый раз необходимо тестировать все приложения на совместимость с новой версией.

Требования

Прежде чем кардинально что-то менять в Hadoop mapreduce, необходимо понять какие же основные требования предъявляются к вычислительным кластерам на практике. Наиболее значительными требованиями к Hadoop следующего поколения являются:

Надежность
Доступность
Масштабируемость - кластеры из как минимум 10 тысяч машин, 200 тысяч вычислительных ядер и даже больше
Обратная и прямая совместимость - возможность быть уверенным, что приложение будет работать на новой версии так же, как оно работало на старой
Контроль над обновлениями
Предсказуемые задержки
Эффективное использование ресурсов

Среди менее значительных требований:

Поддержка альтернативных парадигм разработки (помимо MapReduce)
Поддержка сервисов с коротким жизненным циклом

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

MapReduce следующего поколения

Фундаментальной идеей смены архитектуры является разделение двух основных функций JobTracker'а на два отдельных части:

управление ресурсами;
планирования и мониторинга задач.

В итоге появляется несколько новых ролей:

ResourceManager управляет глобальным распределением вычислительных ресурсов между приложениями;
ApplicationMaster управляет планированием и координацией внутри приложения;
NodeManager управляет процессами в рамках одной машины.

ApplicationMaster представляет собой библиотеку, с помощью которой можно получить у ResourceManager квоту на вычислительные ресурсы и работать с NodeManager(ами) для выполнения и мониторинга задач.

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

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

По одному ApplicationMaster запускается для каждого приложения, они ответственны за запрос необходимых ресурсов у планировщика, запуск задач, отслеживание статусов, мониторинг прогресса и обработку сбоев.

Архитектура

Улучшения по сравнению с текущей реализацией MapReduce

Масштабируемость

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

Масштабируемость особенно важна в свете текущих трендов в оборудовании - на данный момент Hadoop может быть развернут на кластере из 4000 машин. Но 4000 средних машин 2009го года (т.е. по 8 ядер, 16Гб памяти, 4Тб дискового пространства) только вдвое менее ресурсоемки, чем 4000 машин 2011го года (16 ядер, 48гб памяти, 24Тб дискового пространства). Помимо этого с точки зрения операционных издержек было выгоднее работать в еще больших кластере от 6000 машин и выше.

Доступность

ResourceManager использует Apache ZooKeeper для обработки сбоев. Когда ResourceManager перестает работать, аналогичный процесс может быстро запуститься на другой машине благодаря тому, что состояние кластера было сохранено в ZooKeeper. При таком сценарии все запланированные и выполняющиеся приложения максимум лишь перезапустятся.
ApplicationMaster - поддерживается создание точек восстановления на уровне приложений. ApplicationMaster может восстановить работу из состояния, сохраненного в HDFS, в случае сбоя.

Совместимость протокола

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

Инновационность и гибкость

Основным плюсом предложенной архитектуры является тот факт, что MapReduce по сути становится просто пользовательской библиотекой. Вычислительная же система (ResourceManager и NodeManager) становятся полностью независимыми от специфики MapReduce.

Клиенты получат возможность одновременного использования разных версий MapReduce в одном и том же кластере. Это становится тривиальным, так как отдельная копия ApplicationMaster'а запускается для каждого приложения. Это дает гибкость в исправлении багов, улучшений и новых возможностей, так как полное обновление кластер перестает быть обязательной процедурой. Это позволяет клиентам обновлять их приложения до новых версий MapReduce вне зависимости от обновлений кластера.

Эффективность использования вычислительных ресурсов

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

Таким образом эта схема избавляет от текущего механизма map и reduce слотов в Hadoop, который негативно влияет на эффективную утилизацию вычислительных ресурсов.

Поддержка других парадигм программирования помимо MapReduce

В предложенной архитектуре используется общий механизм вычислений, не привязанный конкретно к MapReduce, что позволит использовать и другие парадигмы. Имеется возможность реализовать собственный ApplicationMaster, способный запрашивать ресурсы у ResourceManager и использовать их в соответствии с задачей, при этом сохраняются общие принципы изоляции и гарантированного наличия полученных ресурсов. Среди потенциально поддерживаемых парадигм можно назвать MapReduce, MPI, Мaster-Worker, итеративные модели. Все они могут одновременно работать на одном и том же кластере. Это особенно актуально для приложений (например К-средний или Page Rank), где другие подходы более чем на порядок эффективнее MapReduce.

Выводы

Apache Hadoop, и в частности Hadoop MapReduce - очень успешный opensource проект по обработке больших объемов данных. Предложенный Yahoo путь его переработки направлен на исправление недостатков архитектуры текущей реализации, при этом повышая доступность, эффективность использования ресурсов и предоставляя поддержку других парадигм распределенных вычислений.

Осталось дело за малым - собственно реализовать задуманное! :)

Источник информации

Подписаться на RSS можно здесь.

Мероприятия всякие разные

Иван Блинков — Sat, 02 Oct 2010 17:44:00 +0400

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

Mail.ru Technology Forum

14 сентября

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

В первую очередь я пошел в технологическую секцию, где Tom Preston-Werner, сооснователь и тех. директор проекта GitHub, рассказывал о том, как устроен их проект, какие технологии и костыли они используют. Если в двух словах, то у них используются три протокола: http, git и ssh, для каждого используется свой маршрут обработки запроса внутри системы. Основными продуктами, которые они используют являются Ruby on Rails, Unicorn, HAProxy, и собственно git и sshd. Вообще возможно стоило бы под эту историю написать отдельный пост - детали явно выходят за рамки данного повествования, а доклад и правда был интересным. Постараюсь вернуться к этой истории как только появится возможность.

Следующими в этом зале выступали представители самого mail.ru - честно говоря у меня хватило терпения слушать их очередное расхваливание Imagine Framework, который можно посмотреть только устроившись к ним на работу, только первые минут 15 наверное и я благополучно перекочевал во второй зал, где основной тематикой были социальные игры. Вообще за последний год мне довелось немного поработать в данной области и секция могла бы оказаться интересной, но качество докладов тоже было не на высоте - ничего нового ни про монетизацию, ни про привлечение аудитории услышать не удалось. В основном доклады представляли собой либо кейсы, основанные на конкретных не очень успешных приложениях, либо на каких-то общих рекомендациях и так лежащих на поверхности.

Кстати еще на одном из докладов представители мэйла заикались о некой NoSQL базе данных их разработки, которую они опубликовали под opensource лицензией - впоследствии попытался найти, но на http://opensource.mail.ru какая-то другая муть расположена, а гуглится что-то совсем не то. Если кто в курсе - поделитесь ссылкой, пожалуйста.

"MIT Way" by Richard Kivel

20 сентября

Ричард в целом продемонстрировал себя как успешного бизнесмена в сфере информационных и био технологий, но при этом практическая ценность его выступления была невелика. Он является презедентом MIT Enterprise Forum, а также председателем правления Rhapsody Biologics. Выступление проходило в здание ГУ-ВШЭ при поддержке HSE Inc.

Основными моментами его выступления были следующие тезисы:

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

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

В итоге правда оказалось, что основная цель данной лекции была вовсе не научить делать технологический бизнес, а привлечь дополнительных участников в сообщество MIT EF, представительство которого недавно открылось и в России. Мотивацией для присоединения к сообществу было как раз расширение сети бизнес-знакомств и контактов, особенно зарубежом. Членские взносы составляют довольно приличную сумму по меркам московских студентов (которых было большинство в зале) - что-то в районе 150\$/год.

Startup Weekend Brainstorm

25 сентября

Мероприятие являлось по сути подготовкой к самому Startup Weekend, о котором я напишу чуть ниже. Организатором обоих мероприятий является компания Главстарт, целью которой является расширение рынка технологических стартапов, для чего они проводят эти самые мероприятия, занимаются подбором экспертов и менторов, а также помогают проектам получить посевные инвестиции.

Как не трудно догадаться, подготовительная часть под названием Брейншторм направлена на генерацию идей для интернет-проектов. Участников мероприятия разбили на группы по интересам, около 20 человек на группу, где под руководством массовика-затейника и эксперта они придумывали различные идеи проектов, сервисов, целевых аудиторий и их потребностей и проблем. За почти целый день у каждой группы получилось около 10 более-менее продуманных идей, из которых гипотетически могли бы вырости проекты на следующем этапе - самом Startup Weekend.

Сами идеи проектов позвольте не озвучивать - многое не помню, да и большинство из не прошедшх отбор были на грани бреда.

Yet Another Conference

1 октября

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

Первый доклад, на который я пришел где-то к середине, вел инженер из Google и рассказывал про data races и инструмент для их поиска ThreadSanitizer - вроде все понятно и на самом деле слабо пересекается с областью моих интересов. Вторым докладом в этой секции шел Intel и уже через 15 секунд после начала стало понятно, что будет сплошная реклама их линейки проектов для разработки многопоточных приложений - сразу же встал и сбежал в соседнюю секцию.

В другом зале была самореклама уже продукта Яндекса, но уже несколько более завуалированная. Речь шла об их собственном веб-сервере Phantom, который они используют в баннерокрутилке. Основной его фишкой является приоритезация хэндлеров запросов в рамках одного сервера. Написан с нуля на плюсах, с использованием корутин и чуть ли не вообще без использования каких-либо библиотек. Основной плюс: в отличии от других докладчиков, рекламирующих свое детище, они хотябы обещали открыть исходные коды продукта как только допилят поддержку протокола FastCGI.

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

Apache Hadoop и прочие проекты вокруг него, выступал Константин Швачко из Yahoo. Жалко, что в этом проекте так мало всего изменилось за тот год, что я с ним не работал, даже решение проблемных ситуаций с NameNode толком не решили видимо. Слушал и думал "сколько же я уже раз это все слышал и сам рассказывал другим".
Собственная реализация Map Reduce от Яндекса, Александр Дмитриев. Визуально красиво сделанная презентация, судя по твиттеру очень многим понравилось, правда за этим всем терялась суть доклада - слушал честно говоря краем уха, так как судя по всему публиковать в opensource данный проект они пока не планируют. Специфичная реализация публично-известного подхода, реально приспособленная только под конкретные задачи Яндекса - впечатление осталось именно такое.
Евгений Поляков из Яндекса рассказывал о распределенной хэш-таблице Elliptics Network. Об Эллиптикс я ни разу ранее не слышал, а докладчик рассказывал очень вкусно о данном проекте. Основным плюсом данной системы хранения данных является модульность: особенно интересна возможность использовать различные технологии записи данных на диск, а также различные интерфейсы и протоколы, с помощью которых можно получать доступ к данным. Постараюсь на досуге подробнее изучить вопрос и если обнаружится что-то интересное - опубликовать свое более детальное впечатление о данном проекте.

Поводом сбежать с данной секции стал некий разработчик системы статистики для ЖЖ из SUP Fabrik - молодой человек еле ворочал языком, что делало практически невозможным понимание сути доклада. В другом зале как раз началась медийная секция, опять полная саморекламы. Докладчик из проекта videomost.com (видео-конференции) в целом сосредоточил свое внимание на том, что видео-конференции - это очень сложно, что популярные технологии, часто используемые в видео-трансляциях, там работают плохо - и вообще будущее за проприетарными специализированными протоколами, кодеками и системами. В повестке доклада значились способы обхода firewall'ов и NAT'а - но в докладе все ограничилось лишь большой красивой диаграммкой и фразой что-то в духе "в нашем проекте аж 14 способов решать эти проблемы", без каких-либо деталей.

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

Startup Weekend

1-3 октября

Это мероприятие еще не закончилось, я написал этот пост как раз во второй день - по идее в самый разгар. Как уже возможно стало понятно: основная суть мероприятия заключается в превращении идей интернет-проектов в готовые команды и прототипы. По идее здесь можно найти недостающих членов команды, получить советы экспертов, заключить менторское соглашение и найти посевного инвестора. Вчера были выступления представителей идей/проектов, сегодня - приехали "эксперты": сначала выступали в elevator pitch, потом общение с представителями проектов в формате speeddating, потом консультации по расписанию. Выглядит это все хаотично, организаторы пытаются каким-то образом способствовать созданию проектов, но все равно мотивации явно не хватает, чтобы по сути с незнакомыми людьми сделать хоть сколько-нибудь стоящий проект. Что из всего этого выйдет станет ясно завтра, возможно обновлю пост, если будет что сказать.

Заключение

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

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

Если Вы дочитали до конца, но не подписаны на RSS - сейчас самое подходящее время, чтобы это сделать :)