Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Release management with Gradle #JokerConf2016Кирилл Толкачёв
Talk about Gradle. Best practice and Caveats.
Share build logic between project/team and discuss about result
Use netflix #nebula plugins.
Create super gradle plugin for apply other plugin and configure tasks by one line.
Zerg Rush strategy for developers - it`s good or bad? May be ugly? :)
And other topics and questions...
Сейчас только ленивый не говорит про DevOps, краеугольным камнем которого является организация потока непрерывной доставки ценности клиенту. Continuous Delivery перестаёт быть опцией и становится обязательным требованием.
В докладе будут рассмотрены:
- общие подходы к организации Continuous Delivery на базе Jenkins-а в совсем не тепличных условиях
- практики и подходы, которые позволяют быстро настраивать и собирать десятки микросервисов
- подводные камни, с которыми пришлось столкнуться, и способы борьбы с ними
Jenkins Imperative Pipeline vs Declarative Pipeline Кирилл Толкачёв
Презентация со встерчи JUG MSK про Groovy DSL
Проводитили сравнение новой фичи Jenkins – Declarative Pipelines путем попытки переписать уже существующий пайплайн по доставке ПО на декларативный. Описали подводные камни и обсудили проблемы.
Видео можно будет найти тут https://vk.com/jugmsk или тут https://plus.google.com/communities/115981831554057619568
There is a problem of finding the best instance of a service in distributed systems with dynamic configuration. Nowadays, there are many products for the configuration storage and service discovery. It should be mentioned at least Netflix Eureka, Consul, etc or good old Zookeeper. These products can keep and give configuration, manage service instances lifecycle and some of them even can be as dynamic DNS service. But main question is not about what instance may be called at the certain time. It is about what instance is better for call? This means that smart load balancing top on service discovery is required. Spring Cloud project allows to integrate these products to your project and provides powerful solutions for typical problems, that make cloud native services developing easier. This talk will review the internal structure of SpringCloud implementation of Client-Side Service Discovery and Client Load Balancing patterns. It also will include specific details of concrete implementations with examples from official libraries and the author’s own library.
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Talk about Gradle in a big company. Best practice and Caveats.
How to share build logic between projects and teams.
Netflix way to solve this problem with #nebula plugins.
Create your own super gradle plugin for apply other plugins and configure tasks by one line.
Zerg Rush strategy for developers - it`s good or bad? May be ugly? :)
And other topics and questions...
Самоорганизующаяся сервисная инфраструктура на базе Docker / Данила Штань (То...Ontico
РИТ++ 2017, RootConf
Зал Конгресс-Холл, 5 июня, 17:00
Тезисы:
http://rootconf.ru/2017/abstracts/2799.html
Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.
Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.
Release management with Gradle #JokerConf2016Кирилл Толкачёв
Talk about Gradle. Best practice and Caveats.
Share build logic between project/team and discuss about result
Use netflix #nebula plugins.
Create super gradle plugin for apply other plugin and configure tasks by one line.
Zerg Rush strategy for developers - it`s good or bad? May be ugly? :)
And other topics and questions...
Сейчас только ленивый не говорит про DevOps, краеугольным камнем которого является организация потока непрерывной доставки ценности клиенту. Continuous Delivery перестаёт быть опцией и становится обязательным требованием.
В докладе будут рассмотрены:
- общие подходы к организации Continuous Delivery на базе Jenkins-а в совсем не тепличных условиях
- практики и подходы, которые позволяют быстро настраивать и собирать десятки микросервисов
- подводные камни, с которыми пришлось столкнуться, и способы борьбы с ними
Jenkins Imperative Pipeline vs Declarative Pipeline Кирилл Толкачёв
Презентация со встерчи JUG MSK про Groovy DSL
Проводитили сравнение новой фичи Jenkins – Declarative Pipelines путем попытки переписать уже существующий пайплайн по доставке ПО на декларативный. Описали подводные камни и обсудили проблемы.
Видео можно будет найти тут https://vk.com/jugmsk или тут https://plus.google.com/communities/115981831554057619568
There is a problem of finding the best instance of a service in distributed systems with dynamic configuration. Nowadays, there are many products for the configuration storage and service discovery. It should be mentioned at least Netflix Eureka, Consul, etc or good old Zookeeper. These products can keep and give configuration, manage service instances lifecycle and some of them even can be as dynamic DNS service. But main question is not about what instance may be called at the certain time. It is about what instance is better for call? This means that smart load balancing top on service discovery is required. Spring Cloud project allows to integrate these products to your project and provides powerful solutions for typical problems, that make cloud native services developing easier. This talk will review the internal structure of SpringCloud implementation of Client-Side Service Discovery and Client Load Balancing patterns. It also will include specific details of concrete implementations with examples from official libraries and the author’s own library.
Moscow Jenkins Meetup #1. Pipeline для инженеров. Обзор экосистемыOleg Nenashev
Рассказ о Configuration as Code в Jenkins и возможностях Pipeline: DSL, Multi-Branch, Pipeline Model Definition, восстановление после ошибок, параллелизация задач, интеграции. В каком направлении развивается экосистема?
Talk about Gradle in a big company. Best practice and Caveats.
How to share build logic between projects and teams.
Netflix way to solve this problem with #nebula plugins.
Create your own super gradle plugin for apply other plugins and configure tasks by one line.
Zerg Rush strategy for developers - it`s good or bad? May be ugly? :)
And other topics and questions...
Самоорганизующаяся сервисная инфраструктура на базе Docker / Данила Штань (То...Ontico
РИТ++ 2017, RootConf
Зал Конгресс-Холл, 5 июня, 17:00
Тезисы:
http://rootconf.ru/2017/abstracts/2799.html
Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.
Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.
Общедоступные программы и библиотеки подкупают своей бесплатностью. Если же исходный код открыт, то все сразу думают, что «умные дядьки уже исправили всё, что нужно». На практике же оказывается, что грабли разложены там, где их мало кто ждёт. Тормозит всё, кроме, разве что, самой java. В докладе мы рассмотрим примеры проблем производительности при использовании таких библиотек как Wildfly, Spring, HornetQ, pgjdbc.
Например, оказывается, что spring.getBean тормозит, а в комбинации с autoproxy вообще может занимать до 50% времени приложения. Cglib мешает работе garbage collector’а в попытках проксировать Object#finalize, а HornetQ внезапно притормаживает отправку JMS, что запросто приводит к 5-и секундным задержкам на одно сообщение. Узнаем как их опознать и обезвредить.
В докладе рассказывается об опыте применения «инверсия управления» (Inversion of Control) при разработке новой версии KES. Этот подход заключается в том, что более высокоуровневый код не зависит напрямую от конкретной реализации нижележащего слоя. Вместо этого он зависит от абстрактного протокола (интерфейса), конкретный же компонент подставляется конфигурационным кодом-клиентом. Эта практика позволяет понизить loose coupling программных модулей и применяется практически в любых крупных проектах.
При разработке новой версии KES было принято решение изменить подход к реализации инверсии управления. Было решено отказаться от централизованного обобщенного реестра доступных компонентов (шаблон (паттерн) Service Locator) в пользу явной передачи зависимостей конфигуратором (ручная инъекция зависимостей (manual Dependency Injection)). При это возникли проблемы с использованием готовых библиотек Dependency Injection Frameworks. Применение подобных библиотек стало стандартом в мире разработки Java/C# за последние 10-15 лет, но в мире C++ они пока не получили подобного распространения. В докладе делается обзор и сравнение актуальных DI-Framework’ов на C++, анализируется их применимость к практическим задачам ЛК. Анализируется, что могут привнести стандарты C++11/14 для упрощения решения таких задач.
This is a war-story about deploying and managing Jenkins instances in the cloud in our company. For this purpose, we use Mesos and Docker plugins. In the talk I focus on our requirements to Jenkins in the Cloud, prerequisites and the preparation process. The presentation also covers the current state of the deployment and the lessons learnt.
We are hiring! Msk and Spb: https://goo.gl/HjfOz5
SPb Jenkins Meetup #5. Jenkins in da Cloud. ВнутренностиOleg Nenashev
Доклад о возможностях ядра Jenkins и плагинах, с помощью которых можно управлять инстансами Jenkins в облаке. Ключевые слова: Configuration as Code, Docker, External Logging, Pluggable Storage, Pipeline
Реактивный двигатель вашего Android приложенияMatvey Malkov
Презентация, объясняющая концепцию реактивных потоков с использованием Android SDK и RxJavа. Рассчитано на программистов с любым стажем, которые жеалют начать использовать эту концепцию в своих программах.
Реактивные потоки -- это круто.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
* Почему Angular 2 такой быстрый и как его ускорить еще сильнее?
* Как работает Change Detection механизм и как им управлять?
* Зачем нам Zone.js и Функциональное Реактивное Программирование?
* Как работать с Redux и Mobx в Angular 2 и что можно от этого выиграть?
Об этом и ряде других вещей вы узнаете из этого доклада.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Алексей Романчук «Реактивное программирование»DevDay
Старые подходы к построению программных систем не так актуальны для создания современных решений. В дополнение к масштабируемости добавляются требования отзывчивости, отказоустойчивости и событийности. Пытаться работать на родном старом или посмотреть в сторону новых технологий? В своем выступлении я расскажу про концепцию reactive programming. Какие технологии реализуют концепцию и как сделать первые шаги в этом новом прекрасном мире.
В этой презентации я рассказываю не только об автотестах, а о целом комплексе автоматических инструментов для обеспечения качества веб-сервиса на разных этапах разработки.
Как обеспечить проверку формата? Как поддерживать документацию в актуальном виде? Какую архитектуру выбрать для функциональных тестов?
Немного интересного про JSON-схемы и параметризованные тесты, про тестирование API методом чёрного ящика и про выбор исходных данных для тестирования.
Общедоступные программы и библиотеки подкупают своей бесплатностью. Если же исходный код открыт, то все сразу думают, что «умные дядьки уже исправили всё, что нужно». На практике же оказывается, что грабли разложены там, где их мало кто ждёт. Тормозит всё, кроме, разве что, самой java. В докладе мы рассмотрим примеры проблем производительности при использовании таких библиотек как Wildfly, Spring, HornetQ, pgjdbc.
Например, оказывается, что spring.getBean тормозит, а в комбинации с autoproxy вообще может занимать до 50% времени приложения. Cglib мешает работе garbage collector’а в попытках проксировать Object#finalize, а HornetQ внезапно притормаживает отправку JMS, что запросто приводит к 5-и секундным задержкам на одно сообщение. Узнаем как их опознать и обезвредить.
http://javapoint.ru/talks/sitnikov/
Legacy в коробочке. Dev-среда на базе Kubernetes / Илья Сауленко (Avito)Ontico
РИТ++ 2017
Зал Сан-Паулу, 5 июня, 15:00
Тезисы:
http://ritfest.ru/2017/abstracts/2653.html
Новые микросервисы появляются, но монолит никуда не исчезает. Мы в Avito разрабатываем и деплоим сервисы с помощью связки Docker и Kubernetes. Зачастую интегрировать монолит с сервисами довольно проблематично. А что, если монолит тоже завернуть в Docker+Kubernetes и применять те же практики, что и для микросервисов?
В докладе речь пойдёт о том, как изменилась Dev-среда в Avito в связи с переходом на микросервисную архитектуру. В частности, поговорим про:
- подход "legacy in a box";
- то, как мы решали проблемы с базами и sphinxsearch;
- то, как Docker и Kubernetes помогли нам сократить различия между окружениями;
- Developer Experience.
Доклад будет полезен как командам, планирующим или переживающим распил монолита, так и всем тем, кому приходится работать со сторонними legacy-системами.
Как показывает практика, повсеместное применение классического, основанного на callback’ах подхода к асинхронному программированию обычно оказывается неудобным. Для упрощения написания и поддержки сложного асинхронного кода можно использовать иной подход — с использованием сопрограмм. Он значительно сокращает объём и сложность кода, превращая код из асинхронного в синхронный.
Попытка рассказать и понять, что же такое микросервисы, зачем они нужны или не нужны, как они связаны с архитектурой и.т.д. Все это происходит в атмосфере бесконечного выбора технологий и осознания зачем этот выбор делается. Так же вас ждет пример :)
В программе:
- Немного истории. SOA и закон Конвея
- Принцип LSD
- Парадокс децентрализации
...
- Примеры
Общедоступные программы и библиотеки подкупают своей бесплатностью. Если же исходный код открыт, то все сразу думают, что «умные дядьки уже исправили всё, что нужно». На практике же оказывается, что грабли разложены там, где их мало кто ждёт. Тормозит всё, кроме, разве что, самой java. В докладе мы рассмотрим примеры проблем производительности при использовании таких библиотек как Wildfly, Spring, HornetQ, pgjdbc.
Например, оказывается, что spring.getBean тормозит, а в комбинации с autoproxy вообще может занимать до 50% времени приложения. Cglib мешает работе garbage collector’а в попытках проксировать Object#finalize, а HornetQ внезапно притормаживает отправку JMS, что запросто приводит к 5-и секундным задержкам на одно сообщение. Узнаем как их опознать и обезвредить.
В докладе рассказывается об опыте применения «инверсия управления» (Inversion of Control) при разработке новой версии KES. Этот подход заключается в том, что более высокоуровневый код не зависит напрямую от конкретной реализации нижележащего слоя. Вместо этого он зависит от абстрактного протокола (интерфейса), конкретный же компонент подставляется конфигурационным кодом-клиентом. Эта практика позволяет понизить loose coupling программных модулей и применяется практически в любых крупных проектах.
При разработке новой версии KES было принято решение изменить подход к реализации инверсии управления. Было решено отказаться от централизованного обобщенного реестра доступных компонентов (шаблон (паттерн) Service Locator) в пользу явной передачи зависимостей конфигуратором (ручная инъекция зависимостей (manual Dependency Injection)). При это возникли проблемы с использованием готовых библиотек Dependency Injection Frameworks. Применение подобных библиотек стало стандартом в мире разработки Java/C# за последние 10-15 лет, но в мире C++ они пока не получили подобного распространения. В докладе делается обзор и сравнение актуальных DI-Framework’ов на C++, анализируется их применимость к практическим задачам ЛК. Анализируется, что могут привнести стандарты C++11/14 для упрощения решения таких задач.
This is a war-story about deploying and managing Jenkins instances in the cloud in our company. For this purpose, we use Mesos and Docker plugins. In the talk I focus on our requirements to Jenkins in the Cloud, prerequisites and the preparation process. The presentation also covers the current state of the deployment and the lessons learnt.
We are hiring! Msk and Spb: https://goo.gl/HjfOz5
SPb Jenkins Meetup #5. Jenkins in da Cloud. ВнутренностиOleg Nenashev
Доклад о возможностях ядра Jenkins и плагинах, с помощью которых можно управлять инстансами Jenkins в облаке. Ключевые слова: Configuration as Code, Docker, External Logging, Pluggable Storage, Pipeline
Реактивный двигатель вашего Android приложенияMatvey Malkov
Презентация, объясняющая концепцию реактивных потоков с использованием Android SDK и RxJavа. Рассчитано на программистов с любым стажем, которые жеалют начать использовать эту концепцию в своих программах.
Реактивные потоки -- это круто.
SDN & DEVOPS ?= ❤: Практики использования SDN / Александр Шалимов (ЦПИКС, МГУ)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2679.html
Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".
...
* Почему Angular 2 такой быстрый и как его ускорить еще сильнее?
* Как работает Change Detection механизм и как им управлять?
* Зачем нам Zone.js и Функциональное Реактивное Программирование?
* Как работать с Redux и Mobx в Angular 2 и что можно от этого выиграть?
Об этом и ряде других вещей вы узнаете из этого доклада.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Алексей Романчук «Реактивное программирование»DevDay
Старые подходы к построению программных систем не так актуальны для создания современных решений. В дополнение к масштабируемости добавляются требования отзывчивости, отказоустойчивости и событийности. Пытаться работать на родном старом или посмотреть в сторону новых технологий? В своем выступлении я расскажу про концепцию reactive programming. Какие технологии реализуют концепцию и как сделать первые шаги в этом новом прекрасном мире.
В этой презентации я рассказываю не только об автотестах, а о целом комплексе автоматических инструментов для обеспечения качества веб-сервиса на разных этапах разработки.
Как обеспечить проверку формата? Как поддерживать документацию в актуальном виде? Какую архитектуру выбрать для функциональных тестов?
Немного интересного про JSON-схемы и параметризованные тесты, про тестирование API методом чёрного ящика и про выбор исходных данных для тестирования.
Общедоступные программы и библиотеки подкупают своей бесплатностью. Если же исходный код открыт, то все сразу думают, что «умные дядьки уже исправили всё, что нужно». На практике же оказывается, что грабли разложены там, где их мало кто ждёт. Тормозит всё, кроме, разве что, самой java. В докладе мы рассмотрим примеры проблем производительности при использовании таких библиотек как Wildfly, Spring, HornetQ, pgjdbc.
Например, оказывается, что spring.getBean тормозит, а в комбинации с autoproxy вообще может занимать до 50% времени приложения. Cglib мешает работе garbage collector’а в попытках проксировать Object#finalize, а HornetQ внезапно притормаживает отправку JMS, что запросто приводит к 5-и секундным задержкам на одно сообщение. Узнаем как их опознать и обезвредить.
http://javapoint.ru/talks/sitnikov/
Legacy в коробочке. Dev-среда на базе Kubernetes / Илья Сауленко (Avito)Ontico
РИТ++ 2017
Зал Сан-Паулу, 5 июня, 15:00
Тезисы:
http://ritfest.ru/2017/abstracts/2653.html
Новые микросервисы появляются, но монолит никуда не исчезает. Мы в Avito разрабатываем и деплоим сервисы с помощью связки Docker и Kubernetes. Зачастую интегрировать монолит с сервисами довольно проблематично. А что, если монолит тоже завернуть в Docker+Kubernetes и применять те же практики, что и для микросервисов?
В докладе речь пойдёт о том, как изменилась Dev-среда в Avito в связи с переходом на микросервисную архитектуру. В частности, поговорим про:
- подход "legacy in a box";
- то, как мы решали проблемы с базами и sphinxsearch;
- то, как Docker и Kubernetes помогли нам сократить различия между окружениями;
- Developer Experience.
Доклад будет полезен как командам, планирующим или переживающим распил монолита, так и всем тем, кому приходится работать со сторонними legacy-системами.
Как показывает практика, повсеместное применение классического, основанного на callback’ах подхода к асинхронному программированию обычно оказывается неудобным. Для упрощения написания и поддержки сложного асинхронного кода можно использовать иной подход — с использованием сопрограмм. Он значительно сокращает объём и сложность кода, превращая код из асинхронного в синхронный.
Попытка рассказать и понять, что же такое микросервисы, зачем они нужны или не нужны, как они связаны с архитектурой и.т.д. Все это происходит в атмосфере бесконечного выбора технологий и осознания зачем этот выбор делается. Так же вас ждет пример :)
В программе:
- Немного истории. SOA и закон Конвея
- Принцип LSD
- Парадокс децентрализации
...
- Примеры
Раньше PaaS системы казались чем-то сложным и недосягаемым. И немногие могли попытаться реализовать такую систему самостоятельно. Но стремительное развитие технологий снизило порог входа в мир PaaS. Появилось множество готовых продуктов. И более того, вы сами можете сделать свой PaaS.
В своём докладе я поделюсь опытом проектирования и создания PaaS системы на базе docker, registrator, etcd, confd и ansible. Расскажу, почему я решил сделать его самостоятельно, а не взять готовый, поделюсь опытом реального использования этого продукта в production.
Сегодня очень часто можно услышать множество модный словечек, но даже среди них девопс и микросервисы будоражат умы людей как то по особенному.
Для обычного инженера DevOps и Микросервисы – это всего лишь маркетинговая профанация. Куда важнее “держать DevOps в своих руках” и уметь им пользоваться. Хочется понять где заканчиваются наши и чужие фантазии, где начинаются реально полезные практики, какие инструменты нам помогут и какие фундаментальные принципы помогут увеличить профит от используемых практик и инструментов.
Доклад в первую очередь про внедрение различных технологий, инструментов и методологий в большой организации. Поделюсь проблемами с которыми мы столкнулись при внедрении различных принципов и технологий, расскажу о решениях и выработанных принципах масштабирования процессов/инструментов.
Сегодня наш лозунг будет “DevOps в руках а не в головах”. Но то что в головах всё же важно, хоть это и совсем другая история.
D2D Pizza JS Илья Беда "Куда мы все катимся?"Dev2Dev
Окружение JavaScript, наверно, самая быстроразвивающаяся отрасль в мире разработки программного обеспечения. Все слышали шутку про книгу “36 новых JavaScript фреймворков, выпущенных в марте”, и это не далеко от правды.
В своем обзорном докладе я расскажу о своем пути во frontend. О том, как вижу современную индустрию, о существующих проблемах и путях их решения. Все не так уж радужно, как может показаться. Надеюсь, мой доклад позволит вам взглянуть на мир JavaScript с другой стороны или, по крайней мере, задуматься о том, в правильном ли направлении вы движетесь?
Доклад с конференции D2D Pizza JS - http://dev2dev.ru/events/8/
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Любите ли вы велосипеды? Все разработчики любят свои ненаколеночныерешения велосипеды! И мы не исключение. В нашем докладе мы покажем как собирать, сколачивать, вылепливать собственный велосипед так, чтобы на нем потом могла ездить без слёз вся команда, компания, или может весь мир.
Что в докладе будет:
- много Spring Boot-а;
- live coding;
- создание собственного Spring Boot Starter-а;
- Apache Thrift в качестве подопытного кролика.
Чего не будет:
- бенчмарков и сравнений Thrift vs REST vs gRPC vs XXX.
Рано или поздно возникает необходимость в собственных инструментах по разным причинам: либо не хватает готовых, либо есть какая-то особенность в проекте. Разработка инструментов, работающих в браузере, является непростой задачей. Самое сложное — чтобы они умели работать удаленно, вне страницы. Это многих пугает — нужно много сделать и во многом разобраться. Но если большая часть проблем уже решена, и можно сосредоточиться лишь на основной функции инструмента? Что если такие инструменты смогут работать в произвольном WebView, будь оно встроено в браузер, редактор или другое приложение на любом устройстве? Доклад про удалённые инструменты: какие есть сложности и как их обойти, как перестать бояться и начать делать инструменты под свои задачи и технологический стек.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
Юрий Крутилин. Инструментарий для реверс-инжиниринга Android-приложений Mail.ru Group
Юрий Крутилин, разработчик в DevExpress
«Инструментарий для реверс-инжиниринга Android-приложений. Немного о DEX (Dalvik Executable) формате».
Спикер рассказывает о существующем наборе инструментов для анализа и разбора Android-приложений, коснется структуры формата DEX (Dalvik Executable) и инструментов для работы с ним. Также рассмотрены случаи практического применения.
Особенности тестирования Spring Boot приложения. Нововведения с версии spring-boot 1.4.+
В программе:
* Старые подходы
** @ContextConfiguration
** @ContextHierarchy && @DirtiesContext
** @ActiveProfiles
* Что нового нам приготовил Spring Boot?
** @SpringBootTest
** @TestConfiguration
** @SpringBootConfiguration и его связь с @SpringBootApplicatoin
** @MockBean && @SpyBean && @*Beans
** @DataJpaTest
** @WebMvcTest
* Кэширование spring контекстов
* Шкала тестов
* Порядок сканирвоания контекста test+main. Подводные камни этого процесса
Слайды с доклада "Проклятие Spring Boot Test" на JUG в рамках РИФ Воронеж
Talk about Spring Boot Internals
* Spring Ripper retrospective
* how to build spring boot project. Maven/Gradle plugins
** DependencyManagement in gradle and maven
** Executable artifacts (war or jar)
** War and Jar anatomy
** Embeded tomcat and standalone tomcat integration – SPI. WebApplicationInitializer and ServletContainerInitializer
** Tomcat in Tomcat like a Crank
** Executable jar anatomy
** Main Class and Start-Class. Java MANIFEST.MF anatomy
** Jar like a War, but Jar – JarCraft
** Runtime ClassPath in spring boot applications
* SpringApplication.run ...
** Arguments
** Sources types
** Two general context type in spring boot app
** Starters and autoconfiguration
** spring.factories and SpringFactoriesLoader
** Merge app sources
** Environment and EnvironmentPostProcessor
** ConfigFileApplicationListener mistakes
** Spring Events vs Spring Boot Events
** Application Initializers
** Context prepare
** BeanDefinitionLoader
* @SpringBootApplication anatomy
** @Import – Three types of arguments
*** ImportSelector
*** @Configuration
*** ImportBeanDefinitionRegistrar
** Who is your boss starters? @EnableAutoConfiguration anatomy
** Ugly internal spring boot starter
** ConfigurationClassParser
*** Configuration and Lite Configuration
** Conditional and shouldSkip in different context initialisation steps
Особенности тестирования Spring Boot приложения. Нововведения с версии spring-boot 1.4.+
В программе:
* Старые подходы
** @ContextConfiguration
** @ContextHierarchy && @DirtiesContext
** @ActiveProfiles
* Что нового нам приготовил Spring Boot?
** @SpringBootTest
** @TestConfiguration
** @SpringBootConfiguration и его связь с @SpringBootApplicatoin
** @MockBean && @SpyBean && @*Beans
** @DataJpaTest
** @WebMvcTest
* Кэширование spring контекстов
* Шкала тестов
* Порядок сканирвоания контекста test+main. Подводные камни этого процесса
Слайды с доклада "Проклятие Spring Boot Test"
Обсудим что нового в Spring Boot Test 1.4.0+
В программе:
* Старые подходы
** @ContextConfiguration
** @ContextHierarchy && @DirtiesContext
** @ActiveProfiles
* Что нового нам приготовил Spring Boot?
** @SpringBootTest
** @TestConfiguration
** @MockBean && @SpyBean && @*Beans
** @DataJpaTest
** @WebMvcTest
* Кэширование spring контекстов
* Шкала тестов
Слайды с доклада "Проклятие Spring Boot Test"
Java Day Minsk 2016 Keynote about Microservices in real worldКирилл Толкачёв
Slides from #javaday #keynote about microservices.
Everyone has heard about microservices. Someone tries to implement them in practice. And only the bravests of us have already used them in production environment.But then why so many people hype around microservices, if the idea is not quite new? What are microservices? What is the difference between it and good old SOA approach? How can developers create modern enterprise applications in Java easily with the help of this approach?
We discuss about history of microservices, share our practical experience, and try to find answer for question "How to use microservices approach in production"
34. 34
Проблемы архитектуры
● Сильная связанность между модулями
● Слабое тестовое прикрытие
● Регрессионная спираль смерти
○ частично решалась Selenium-тестами
○ но это дорого
48. 48
Проблема эволюции
● Начинали с одного проекта
○ одна команда
○ ui + три сервиса
● Более 10-ти однотипных проектов
○ несколько команд
○ десятки сервисов
○ технологически одинаковые
52. 52
● Spring Boot/Spring Cloud
● Ratpack
● Dropwizard
● Vert.x
● Restlet
● Spark
● KumuluzEE
Выбирайте то,
что больше
нравится
/
в чем есть
экспертиза
55. Принцип LSD
- L языков программирования
- S среднее число фреймворков на язык
- D типов источников данных
complexity = L * S * D
55
56. Немного LSD для вас
- три языка программирования
- два в среднем фреймворка на язык
- семь типов источников данных
- legacy WS, mongo db
- OLTP, OLAP
- elasticsearch, neo4j
- Мишкина база %)
complexity = 3 * 2 * 7 = 42 (!)
56
74. ~home > lazybones create api 0.0.1 rent-service
Creating project from template api 0.0.1 in 'rent-service'
Define value for 'group' [ru.joker]:
74
75. ~home > lazybones create api 0.0.1 rent-service
Creating project from template api 0.0.1 in 'rent-service'
Define value for 'group' [ru.joker]:
Define value for 'version' [0.0.1]:
75
76. ~home > lazybones create api 0.0.1 rent-service
Creating project from template api 0.0.1 in 'rent-service'
Define value for 'group' [ru.joker]:
Define value for 'version' [0.0.1]:
srv1
├──srv2
└──srv3
logging
sleuth
Define value for 'dependencies' [logging,sleuth]:
76
77. ~home > lazybones create api 0.0.1 rent-service
Creating project from template api 0.0.1 in 'rent-service'
Define value for 'group' [ru.joker]:
Define value for 'version' [0.0.1]:
srv1
├──srv2
└──srv3
logging
sleuth
Define value for 'dependencies' [logging,sleuth]:
Project created for rent-service!
77
81. TServerTransport serverTransport = new TServerSocket(
new
InetSocketAddress(InetAddress.getLocalHost(), port));
TProcessor processor = new
TInsuranceService.Processor<>(
//business value here
);
server = new TSimpleServer(
new
TServer.Args(serverTransport).processor(processor));
server.serve();
81
82. TSocket transport = new TSocket(host, port);
transport.open();
TBinaryProtocol tBinaryProtocol = new
TBinaryProtocol(transport);
TInsuranceService.Client client =
new TInsuranceService.Client(tBinaryProtocol);
perform(client); //business value here
transport.close(); 82
88. @Getter // generate getters
@Setter // generate setters
@Aspect // we are an aspect
@ToString // generate toString()
@EnableWs // SOAP is so enterprisy, we definitely need it
@Endpoint // Seriously, just read above
@EnableWebMvc // we want MVC
@EnableCaching // and we want to cache stuff
@Configuration // this class can configure itself
@RestController // we want some REST
@XmlRootElement // this component is marshallable
@EnableWebSocket // we want web socket, it's so new-generation
@RedisHash("cat") // this class is an entity saved in redis
@EnableScheduling // we want scheduled tasks
@EnableWebSecurity // and some built-in security
@NoArgsConstructor // generate no args constructor
@ContextConfiguration // we want context configuration for unit testing
@SpringBootApplication // this is a Sprint Boot application
@Accessors(chain = true) // getters/setters are chained (ala jQuery)
@EnableAspectJAutoProxy // we want AspectJ auto proxy
@EnableAutoConfiguration // and auto configuration
@EnableRedisRepositories // since it is an entity we want to enable spring data repositories for redis
@EnableWebSocketMessageBroker // we want a broker for web socket messages
88
91. Not smart
= This is main documentation
This document describes how to be the most fundamental and important
document in the world of documents
...
COPY-PASTE documentation from another document
...
91
92. Not so smart
= This is main documentation
This document describes how to be the most fundamental and important document
in the world of documents
include::https://raw.github.com/asciidoctor/asciidoctor/master/Gemfile[]
include::../other.adoc[]
include::/home/tolkv/git/docs-0/superdoc.adoc[]
92
93. Really smart
= This is main documentation
This document describes how to be the most fundamental and important document
in the world of documents
include::https://raw.github.com/asciidoctor/asciidoctor/master/Gemfile[]
include::gradle://gradle-advanced:service-with-deps:1.0/deps.adoc[]
include::gradle://:service/doc.adoc[]
93
94. Payment Service[jar,doc] Insurance Service [jar,doc]
One Point of View
[UberDoc.zip]
Rent Service[jar,doc] Other Service [jar,doc]
Агрегация информации
94
95. Парадокс централизации
Чтобы эффективно разрабатывать распределённые
приложения, нам нужны очень хорошие
централизованные библиотеки и инструменты
Например: логирование, health-checking, метрики,
обработка типовых ошибок, автодокументирование
95
96. Парадокс централизации
Чтобы эффективно разрабатывать распределённые
приложения, нам нужны очень хорошие
централизованные библиотеки и инструменты
Но: не выносите бизнес-логику или доменные объекты!
Не размывайте бизнес-контекст вашего API
96
168. 168
RentService
PaymentService
SecurityServiceBlockchainService
TraceId = X
SpanId = A
No TraceId
No SpanId
TraceId = X
SpanId = A
TraceId = X
SpanId = A
TraceId = X
SpanId = B
TraceId = X
SpanId = B
TraceId = X
SpanId = C
TraceId = X
SpanId = C
TraceId = X
SpanId = D
TraceId = X
SpanId = D
TraceId = X
SpanId = E
TraceId = X
SpanId = E
TraceId = X
SpanId = F
TraceId = X
SpanId = G
180. 1. Архитектура – функция от множества
переменных
Простить, потому что
180
181. 1. Архитектура – функция от множества
переменных
2. Архитектура – результат эволюции на
протяжении времени
Простить, потому что
181
182. 1. Архитектура – функция от множества
переменных
2. Архитектура – результат эволюции на
протяжении времени
3. Принципы должны быть “вечны”, а
инструменты актуальны и эффективны
Простить, потому что
182
184. 1. SOA принципы живы
2. Принцип LSD
Придерживайтесь принципов
184
185. 1. SOA принципы живы
2. Принцип LSD
3. Изоляция данных делает жизнь приятнее
Придерживайтесь принципов
185
186. 1. SOA принципы живы
2. Принцип LSD
3. Изоляция данных делает жизнь приятнее
4. Парадокс централизации
Придерживайтесь принципов
186
187. 1. SOA принципы живы
2. Принцип LSD
3. Изоляция данных делает жизнь приятнее
4. Парадокс централизации
5. Планируй ресурсы динамически
Придерживайтесь принципов
187
188. Links
Лекция Жени Кривошеева про архитектуру:
https://www.youtube.com/watch?v=_Kex5hwGE-w
Пример Smart-библиотеки:
https://github.com/lavcraft/grpc-spring-boot-starter
Пример реализации “умной документации”:
https://github.com/aatarasoff/documentation-plugin-demo
188