Антон Пискунов. Независимый разработчик.
«BeeGo для веб-приложений, API и демонов»
- Почему BeeGo? vs Revel and another guys.
- Что мы пишем на BeeGo? Наш личный опыт.
- Как написать облачный стартап и инфраструктурные сервисы на BeeGo за две недели.
- Sweet API, нэймспейсы и автодокументация.
- Демонизация BeeGo, к чему мы пришли?
- Разработчики, мэйнтейнинг, существующие проблемы
http://go-meetup-spb.timepad.ru/event/169777/
Субъективная точка зрения на фронтенд разработку.
Площадка: IT-бар КЛЮЧ, https://vk.com/event69759919
Видео с доклада: https://www.youtube.com/watch?v=pyAYbbDJjPo
Быстрый рендеринг с DOM шаблонизаторами / Борис Каплуновский (aviasales.ru)Ontico
1. Типы шаблонизаторов DOM/innerHTML.
2. Внутренности AngularJS и почему он тормозит.
3. Внутренности ReactJS и почему он тормозит.
4. Менее раскрученные решения Blaze/PaperclipJS/Riot и что там сделано лучше.
5. Плюсы и минусы virtualdom.
6. Работа с DOM может быть быстрее, если:
6.1 Использовать одни и те-же участки DOM несколько раз.
6.2 Сокращать количество reflow с DocumentFragment.
6.3 Быстрое создание повторяющихся участков DOM с помощью cloneNode.
6.4 Создавать куски DOM ahead of time.
7. Встречаем temple - шаблонизатор, работающий в разы быстрее reactjs и не требующий загрузки 40k библиотеки времени исполнения.
Антон Пискунов. Независимый разработчик.
«BeeGo для веб-приложений, API и демонов»
- Почему BeeGo? vs Revel and another guys.
- Что мы пишем на BeeGo? Наш личный опыт.
- Как написать облачный стартап и инфраструктурные сервисы на BeeGo за две недели.
- Sweet API, нэймспейсы и автодокументация.
- Демонизация BeeGo, к чему мы пришли?
- Разработчики, мэйнтейнинг, существующие проблемы
http://go-meetup-spb.timepad.ru/event/169777/
Субъективная точка зрения на фронтенд разработку.
Площадка: IT-бар КЛЮЧ, https://vk.com/event69759919
Видео с доклада: https://www.youtube.com/watch?v=pyAYbbDJjPo
Быстрый рендеринг с DOM шаблонизаторами / Борис Каплуновский (aviasales.ru)Ontico
1. Типы шаблонизаторов DOM/innerHTML.
2. Внутренности AngularJS и почему он тормозит.
3. Внутренности ReactJS и почему он тормозит.
4. Менее раскрученные решения Blaze/PaperclipJS/Riot и что там сделано лучше.
5. Плюсы и минусы virtualdom.
6. Работа с DOM может быть быстрее, если:
6.1 Использовать одни и те-же участки DOM несколько раз.
6.2 Сокращать количество reflow с DocumentFragment.
6.3 Быстрое создание повторяющихся участков DOM с помощью cloneNode.
6.4 Создавать куски DOM ahead of time.
7. Встречаем temple - шаблонизатор, работающий в разы быстрее reactjs и не требующий загрузки 40k библиотеки времени исполнения.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
«Масштабируемый DevOps» Александр КолесеньIT Share
Типичные подходы к развертыванию приложений: как правильные, так и неправильные, но повсеместно применяемые.
Как сделать так, чтобы развертывание не стало проблемой с линейным ростом количества поддерживаемых окружений.
Методы обновления проекта с нулевым временем простоя: когда это уместно и принципиально возможно.
HTML5 Web Components: следующий шаг к модульности вашего проекта / Андрей Рах...Ontico
На сегодняшний день frontend-технологии - одна из наиболее динамично развивающихся отраслей информационных технологий. Появилось множество реализаций известных шаблонов проектирования, написаны тысячи строк Javascript-кода и потрачены сотни часов на stackoverflow для понимания работы этого самого кода. Несмотря на различные подходы, все эти инструменты служат нескольким важным принципам: снижению сложности, улучшению модульности и архитектуры в целом.
HTML5 Web Components стандартизируют эти идеи, прошедшие через огонь, воду и тяжелые Javascript-фреймворки. Мы поделимся опытом внедрения Web Components в проект с объемной single-page логикой, расскажем, как удобнее работать с веб-компонентами, принимая во внимание текущее состояние реализации, а также дадим советы, где постелить соломы при вашем собственном старте работы с веб-компонентами.
Основные моменты доклада:
— Для каких проектов Web Components будут полезны в первую очередь;
— Действительно ли Web Components настолько удобны? Примеры “до” и “после”;
— Текущие проблемы реализации в браузерах и их решение;
— Как быть с текущими фреймворками и шаблонизаторами: что можно подружить, а от чего проще отказаться;
— Как начать интегрировать Web Components в текущее решение и на какие стороны вашего проекта обратить особое внимание.
От репозитория до CI/CD-инфраструктуры в продакшне за неделю / Дмитрий Чумак ...Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2810.html
В докладе я разберу развертывание CI/CD в сжатые сроки на реальном технологически нагруженном проекте. Несколько PostgreSQL, кластер Neo4J, нейронные сети, dev-stage-prod окружения.
Планирование архитектуры проекта с точки зрения приложения, мотивация выбора конкретной схемы.
Как настроить связку Ansible+Docker+Consul на живом проекте за три дня. Почему Amazon не всегда хорошо, проблемы с балансерами, VPC и нюансы ECS.
Этапы разворачивания CD, планирование, концепции, реальность. Коррективы со стороны разработчиков и влияние требований разработки на итоговую инфраструктуру.
Разбор того, что же получилось в итоге, и какие есть дальнейшие перспективы развития инфраструктуры.
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
«Масштабируемый DevOps» Александр КолесеньIT Share
Типичные подходы к развертыванию приложений: как правильные, так и неправильные, но повсеместно применяемые.
Как сделать так, чтобы развертывание не стало проблемой с линейным ростом количества поддерживаемых окружений.
Методы обновления проекта с нулевым временем простоя: когда это уместно и принципиально возможно.
HTML5 Web Components: следующий шаг к модульности вашего проекта / Андрей Рах...Ontico
На сегодняшний день frontend-технологии - одна из наиболее динамично развивающихся отраслей информационных технологий. Появилось множество реализаций известных шаблонов проектирования, написаны тысячи строк Javascript-кода и потрачены сотни часов на stackoverflow для понимания работы этого самого кода. Несмотря на различные подходы, все эти инструменты служат нескольким важным принципам: снижению сложности, улучшению модульности и архитектуры в целом.
HTML5 Web Components стандартизируют эти идеи, прошедшие через огонь, воду и тяжелые Javascript-фреймворки. Мы поделимся опытом внедрения Web Components в проект с объемной single-page логикой, расскажем, как удобнее работать с веб-компонентами, принимая во внимание текущее состояние реализации, а также дадим советы, где постелить соломы при вашем собственном старте работы с веб-компонентами.
Основные моменты доклада:
— Для каких проектов Web Components будут полезны в первую очередь;
— Действительно ли Web Components настолько удобны? Примеры “до” и “после”;
— Текущие проблемы реализации в браузерах и их решение;
— Как быть с текущими фреймворками и шаблонизаторами: что можно подружить, а от чего проще отказаться;
— Как начать интегрировать Web Components в текущее решение и на какие стороны вашего проекта обратить особое внимание.
От репозитория до CI/CD-инфраструктуры в продакшне за неделю / Дмитрий Чумак ...Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2810.html
В докладе я разберу развертывание CI/CD в сжатые сроки на реальном технологически нагруженном проекте. Несколько PostgreSQL, кластер Neo4J, нейронные сети, dev-stage-prod окружения.
Планирование архитектуры проекта с точки зрения приложения, мотивация выбора конкретной схемы.
Как настроить связку Ansible+Docker+Consul на живом проекте за три дня. Почему Amazon не всегда хорошо, проблемы с балансерами, VPC и нюансы ECS.
Этапы разворачивания CD, планирование, концепции, реальность. Коррективы со стороны разработчиков и влияние требований разработки на итоговую инфраструктуру.
Разбор того, что же получилось в итоге, и какие есть дальнейшие перспективы развития инфраструктуры.
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
Доклад с PUG#6 https://www.facebook.com/events/837043689707114/
1. Почему стоит обратить внимание на этот фреймворк. Какие очевидные плюсы и выгоды мы можем из этого извлечь.
2. Реализация основных компонентов фреймворка, безопасность и архитектура.
3. Инструменты для масштабирования highload-проекта, предусмотренные самим фреймворком.
Велосипед уже изобретен. Что умеют промышленные СХД? / Антон Жбанков (Nutanix)Ontico
Зачем мы каждый раз изобретаем велосипед, только потому что можем? Корпоративные СХД существуют более 25 лет и умеют очень многое.
Защита данных, качество обслуживания, многоуровневое хранение и кэширование на флэш-памяти. Система хранения данных - это не только гигабайт по минимальной цене, но так же и гарантированная производительность и отказоустойчивость.
Вы узнаете, как можно обеспечить своим данным высокую степень защиты, значительно сократив время реализации проекта. Или, наоборот, убедитесь в том, что СХД корпоративного класса вашему проекту не подходят.
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуат...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуатация HBase на паре жизненных примеров", Александр Чистяков (ведущий разработчик Git in Sky)
Dmytro Nemesh "Building the perfect infrastructure with Kubernetes"Fwdays
Every company comes to a point where it’s infrastructure no longer fits team and business needs, and kludges are not working anymore. That’s the time to re-think and redesign the whole infrastructure. This is exactly where our company was half a year ago. I will talk about our experience dealing with this challenge while balancing between existing technology, costs, today’s reality and future needs.
"How to build powerful CI / CD based on GitLab and Docker", Aleksandr Matkovs...Provectus
Aleksandr Matkovskiy – Head of IT Department lives and works with the motto "Scaling and load balancing is our all!". Therefore, he has 3 sons and dreams to find DEV for his OPS.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
Vladislav Anikin – Team Leader & Software Architect, specializing in SAAS flexible and scalable solutions for business. Driving DDD/TDD oriented squad of awesome SOLID developers.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
3. Кто здесь?
● Максим, администратор серверных систем
● Отвечаю за производительность
● Состою в скромной команде архитекторов
● Холю и лелею инфраструктуру
До Колёс:
● много VoIP’а на цисках и линуксах
● линуксы дома, на работе, в отпуске…
10. OpenVZ
Минусы:
● одно ядро на всех
● «хитрое» управление памятью (MongoDB и JVM передают
привет!)
● ФС для контейнеров
● видимость ограничена
● постоянные танцы с бубном вокруг user_beancounters
11. KVM
Плюсы:
● полная изоляция ВМ друг от друга и от хоста
● MongoDB и JVM улыбаются и пляшут
● быстрая работа с диском
● видимость всех ресурсов ВМ
● virtio, vhost_net, KSM
13. OpenVZ, давай, до свидания!
● Несколько недель не спим
● Переносим контейнеры в ВМ
● …
● PROFIT!
P.S. До сих пор KVM ни разу не становился настолько
узким местом, чтобы хотелось от него отказаться.
15. Немного про overprovisioning
Он же оверселлинг, он же оверсабскрайбинг, он же
большая радость хостера и засада клиента:
● позволяет продать больше, чем имеешь
● провоцирует «драку» за ресурсы
● распределение ресурсов становится
«тяжелой», но приоритетной задачей
● совершенно нам не подходит
17. Почему же?
● большая коробка — половину в другой ЦОД не
отпилишь
● аренда места в ЦОД стоит космических денег
● заполненность на 25% экономически невыгодна
● сэкономили на сетевой части
● недешевый бренд
18. Наш выбор — Supermicro Twin²
● один такой заменит блэйд
● компактный
● производительный
● в 4 раза меньше
● в 2 раза дешевле
● недорогой бренд
● даже с учётом электричества, аренда обходится
дешевле
19. GlusterFS
● как NFS, только от Red Hat
● плюшки в виде репликации
● и распределенности
● которые никто не заюзал
● ибо хранилище было одно
● в самом низу — родная ФС (ext3/4, xfs)
20. Что лежало на хранилке
Объявления:
/mnt/data/live/0007/654/321/data.xml
Фотографии:
/mnt/data/live/0007/654/321/photos/1/60x45.jpg
/mnt/data/live/0007/654/321/photos/1/120x90.jpg
/mnt/data/live/0007/654/321/photos/1/400x300.jpg
/mnt/data/live/0007/654/321/photos/1/full.jpg
~ 2 ТБ данных к середине 2012-го
24. Проблема
Задержки:
● HDD
● сетевая ФС
● ФС как структура вообще
● множественный доступ (кэш не спасёт)
● бэкап данных за неделю длится неделю
25. Решение для объявлений
● Никаких каталогов
● Никаких файлов
● Вкусный JSON вместо XML
● Репликация
● Резервное копирование (с бубном)
26. В итоге
● драматическое падение задержек
● катастрофический прирост производительности
● ещё два года Колёса живут без шардинга
27. Решение для фотографий
● храним объекты
● намного меньше метаданных
● доступ по HTTP
● nginx для кэша и HTTPS
● распределенная система
● избыточно (3 копии данных)
● задержки по-прежнему высоковаты :(
28. Цифры (Swift vs Хранилка)
● стоимость: 30% старой системы
● расходы: на 20% выше
● тройная избыточность
● защита от сбоев
● распределенность
29. Миграция
1. поднимаем новую систему
2. включаем запись в обе системы
3. запускаем перенос данных из старой в новую
систему
4. начинаем читать с новой системы
5. дожидаемся окончания переноса
6. ждём «на всякий случай»
7. отключаем старую систему
30. Фотографии (сейчас)
● 2к запросов/сек
● 260 Мбит/сек
● 220 ГБ кэш (memcached)
● кэш спасает, но продолжаем ускоряться
● SSD для метаданных
32. 2013 …
● появились мобильные приложения
● доросли до конца года до 1.5М просмотров и
120к визитов
● масштабируемся каждый день
● все хотят в API, а API всех ненавидит
● присутствуем в двух ЦОДах
34. Немного уже не узких мест
● CDN для фотографий и статики
○ два ЦОДа
○ балансировка на уровне DNS
● загрузка фото
○ кэш для свежезагруженных изображений
○ фоновый перенос в Swift
● жесткие диски
○ SSD уже не дорого
○ и очень быстро
35. Автоматизация
● серверов всё больше
● конфигурации всё изощрённее
● зависимость A->B->C->D->A
● нужно же что-то делать, Петька!
36. Chef
● сервер управления конфигурацией
● для всех *nix
● пишем рецепты, а оно их исполняет
● только там, где нужно
● попутная инвентаризация
● только pull
● пришлось учить ruby
● программисты смеялись :(
37. Примеры
● добавлять все новые серверы в мониторинг
● установить nginx на серверы группы web
● найти все серверы, с драйвером e1000 и
наложить патч
40. Что дальше?
● вчерашние паттерны уже антипаттерны
● на горизонте маячит HTTP2
● оптимизация под dial-up снова в моде
● только теперь 1080p и 4K
● зато даже в самолёте