Сегодня очень часто можно услышать множество модный словечек, но даже среди них девопс и микросервисы будоражат умы людей как то по особенному.
Для обычного инженера DevOps и Микросервисы – это всего лишь маркетинговая профанация. Куда важнее “держать DevOps в своих руках” и уметь им пользоваться. Хочется понять где заканчиваются наши и чужие фантазии, где начинаются реально полезные практики, какие инструменты нам помогут и какие фундаментальные принципы помогут увеличить профит от используемых практик и инструментов.
Доклад в первую очередь про внедрение различных технологий, инструментов и методологий в большой организации. Поделюсь проблемами с которыми мы столкнулись при внедрении различных принципов и технологий, расскажу о решениях и выработанных принципах масштабирования процессов/инструментов.
Сегодня наш лозунг будет “DevOps в руках а не в головах”. Но то что в головах всё же важно, хоть это и совсем другая история.
Попытка рассказать и понять, что же такое микросервисы, зачем они нужны или не нужны, как они связаны с архитектурой и.т.д. Все это происходит в атмосфере бесконечного выбора технологий и осознания зачем этот выбор делается. Так же вас ждет пример :)
В программе:
- Немного истории. SOA и закон Конвея
- Принцип LSD
- Парадокс децентрализации
...
- Примеры
Алексей Ильенко "In real-time with Apache Kafka"Fwdays
- will talk about Apache Kafka;
- will learn how to not fear Apache Kafka, as a fire;
- will show how it can unfold in three clicks and use in production;
- how to build a Lua query logging system and what PHP is here for.
Развитие DevOps/NoOps инструментов. Что было, что есть, что будет.Ivan Evtukhovich
Доклад для конференции SQADays 20, обзорно рассказывает про DevOps, переход к NoOps и микросервисной архитектуре, а также почему ручное тестирование умрет.
Попытка рассказать и понять, что же такое микросервисы, зачем они нужны или не нужны, как они связаны с архитектурой и.т.д. Все это происходит в атмосфере бесконечного выбора технологий и осознания зачем этот выбор делается. Так же вас ждет пример :)
В программе:
- Немного истории. SOA и закон Конвея
- Принцип LSD
- Парадокс децентрализации
...
- Примеры
Алексей Ильенко "In real-time with Apache Kafka"Fwdays
- will talk about Apache Kafka;
- will learn how to not fear Apache Kafka, as a fire;
- will show how it can unfold in three clicks and use in production;
- how to build a Lua query logging system and what PHP is here for.
Развитие DevOps/NoOps инструментов. Что было, что есть, что будет.Ivan Evtukhovich
Доклад для конференции SQADays 20, обзорно рассказывает про DevOps, переход к NoOps и микросервисной архитектуре, а также почему ручное тестирование умрет.
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
В докладе будет:
- что такое F.I.R.S.T
- организация кода приложения для повышения его тестируемости, поддерживаемости и производительности
- какой тест-фреймворк выбрать для решения какой задачи?
- какие виды тестирования бывают и за какие из них отвечают разработчики?
- как тратить больше времени на код, а не на тесты
- как и какие метрики тестирования собирать
Быстрое расширение Robot Framework под свои нужды с использованием Pythonautomated-testing.info
Быстрое расширение Robot Framework под свои нужды с использованием Python, Михаил Поляруш
Когда мы начинаем заниматься автоматизацией тестирования ПО, мы редко знаем и понимаем, что нам надо будет делать, а тем более, как это нужно реализовать. Потому, выбираем самые простые решения, которые иногда даже не подразумевают программирования. Вы считаете, что успешная автоматизация может быть без программирования? Я уверен, что НЕТ, и с уверенностью могу сказать, что процесс автоматизации с помощью python и RobotFramework может значительно упростить Вам жизнь. Убедитесь в том, что архитектура RobotFramework очень гибкая, а python – лучший друг автоматизатора. Вас ждет увлекательная теория и много практики в живую.
Codeception + Docker + Robo и что из этого вышлоCOMAQA.BY
Параллелизация тестов, а именно: лучший пхп тулл для автоматизации (Codeception); основы Docker контейнирезации; robo - что это и зачем он нам нужен; profit
Serghei Iakovlev "Chaos engineering in action"Fwdays
Let's talk about what chaos engineering is and how this discipline can be applied in projects where PHP is used as the main language.
Among other things, we will cover the following topics:
What problems does chaos engineering solve?
What are the solutions exist?
How to develop your own solution?
What is a controlled failover?
A little about ZendEngine and what tools are out of the box?
A bit about chaos design.
A bit about the code leading to chaos.
Микросервисы, кто-то только слышал о них, кто-то пытался делать, кто-то уже использует в продакшене. Идеи, заложенные в концепцию микросервисов, не новы и основные постулаты уже звучали раньше. Так почему же в последнее время мы всё чаще слышим о микросервисах? Что такое микросервисы для нас и чем они отличаются от старого доброго подхода SOA? Как теперь разрабатывать enterprise-приложения с микросервисным подходом на нашем любимом языке программирования Java?
На эти и некоторые другие вопросы постараемся ответить во время встречи. Наши гости, Кирилл Толкачёв и Александр Тарасов, в режиме live coding попытаются создать небольшой стартап, попутно использовав новомодные подходы и инструменты.
На пути к релизу стартапа будут затронуты основные проблемы выбранных подходов в целом и технологий в частности:
Микросервис — что это, для чего и как с этим дальше жить. Где теория брат? ;)
На чём писать API: REST или RPC, и почему Thrift имеет право на жизнь в эпоху тотального распространения JSON-а. Упрощай и превозмогай с помощью Spring boot starter;
Какой стек выбрать для разработки, что выбрали мы и почему. Небольшое сравнение легковесных и не очень java фреймворков а так же сопутствующих инструментов;
Способы упаковки, дистрибуции и разворачивания микросервисов, как Spring Boot и Docker помогают нам в решении этих непростых для разработчика проблемах;
Как микросервисам найти друг друга, как готовить Spring Cloud и как обойти существующие проблемы и ограничения. Не доверяйте технологиям, доверяйте только себе;
API Gateway. Предохраняй и сохраняй свои микросервисы.
Так же речь пойдет о других распространенных проблемах распределенных систем и их решениях.
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Highload...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Highload и стартап на Java - как совместить?", Александр Константинов (основатель FriendRent, разрабочик в JetBrains)
Аннотация
Если долгое время создавал высоконагруженные и распределенные системы, а затем начал делать стартап, то в голове сразу же прорисовывается архитектура, которая должна быть у такого сервиса. Однако понятно, что создать за месяц большую и сложную систему - крайне затруднительно. Работая в Яндексе и JetBrains, мы накопили большой опыт разработки таких сервисов. В своём докладе я расскажу, как создать в стартапе архитектуру так, чтобы это заняло минимум времени, но при этом система могла бы легко выдержать миллион просмотров в месяц. От чего стоит отказаться, а на что наоборот следует обратить внимание, как упрощать систему, но при этом оставлять возможность расширения. Ключевые слова: Java, Spring, MySQL, JSP, Nginx.
Биография
Совладелец проекта FriendRent повященного аренде недвижимости через социальные сети. Senior Developer в компании JetBrains. В студенческие годы разрабатывал приложения для Вконтакте.
D2D Pizza JS Илья Беда "Куда мы все катимся?"Dev2Dev
Окружение JavaScript, наверно, самая быстроразвивающаяся отрасль в мире разработки программного обеспечения. Все слышали шутку про книгу “36 новых JavaScript фреймворков, выпущенных в марте”, и это не далеко от правды.
В своем обзорном докладе я расскажу о своем пути во frontend. О том, как вижу современную индустрию, о существующих проблемах и путях их решения. Все не так уж радужно, как может показаться. Надеюсь, мой доклад позволит вам взглянуть на мир JavaScript с другой стороны или, по крайней мере, задуматься о том, в правильном ли направлении вы движетесь?
Доклад с конференции D2D Pizza JS - http://dev2dev.ru/events/8/
В рамках доклада я хотел бы рассмотреть сложности, которые мы испытываем с построением инфраструктуры распределенных систем.
Можно ли строить приложения и не думать о серверах и контейнерах? Насколько это будет дорого?
Ответить на эти вопросы помогут принципы «Бессерверной архитектуры». На простых примерах мы рассмотрим из чего состоит приложение, не зависящее от серверов. А также, рассмотрим возможности, которые предоставляют популярные провайдеры облачных сервисов, для построения таких приложений.
Evolution of web-project requires scalable architecture and scalable development process. In my presentation (in Russian): different techniques, how to achieve this if talking about Perl-based web project.
Микросервисная архитектура на базе CoreOS и KubernetesDenis Izmaylov
13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.
В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.
Особенности тестирования 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 в рамках РИФ Воронеж
Jenkins Imperative Pipeline vs Declarative Pipeline Кирилл Толкачёв
Презентация со встерчи JUG MSK про Groovy DSL
Проводитили сравнение новой фичи Jenkins – Declarative Pipelines путем попытки переписать уже существующий пайплайн по доставке ПО на декларативный. Описали подводные камни и обсудили проблемы.
Видео можно будет найти тут https://vk.com/jugmsk или тут https://plus.google.com/communities/115981831554057619568
More Related Content
Similar to Wild microservices and imaginary DevOps
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
В докладе будет:
- что такое F.I.R.S.T
- организация кода приложения для повышения его тестируемости, поддерживаемости и производительности
- какой тест-фреймворк выбрать для решения какой задачи?
- какие виды тестирования бывают и за какие из них отвечают разработчики?
- как тратить больше времени на код, а не на тесты
- как и какие метрики тестирования собирать
Быстрое расширение Robot Framework под свои нужды с использованием Pythonautomated-testing.info
Быстрое расширение Robot Framework под свои нужды с использованием Python, Михаил Поляруш
Когда мы начинаем заниматься автоматизацией тестирования ПО, мы редко знаем и понимаем, что нам надо будет делать, а тем более, как это нужно реализовать. Потому, выбираем самые простые решения, которые иногда даже не подразумевают программирования. Вы считаете, что успешная автоматизация может быть без программирования? Я уверен, что НЕТ, и с уверенностью могу сказать, что процесс автоматизации с помощью python и RobotFramework может значительно упростить Вам жизнь. Убедитесь в том, что архитектура RobotFramework очень гибкая, а python – лучший друг автоматизатора. Вас ждет увлекательная теория и много практики в живую.
Codeception + Docker + Robo и что из этого вышлоCOMAQA.BY
Параллелизация тестов, а именно: лучший пхп тулл для автоматизации (Codeception); основы Docker контейнирезации; robo - что это и зачем он нам нужен; profit
Serghei Iakovlev "Chaos engineering in action"Fwdays
Let's talk about what chaos engineering is and how this discipline can be applied in projects where PHP is used as the main language.
Among other things, we will cover the following topics:
What problems does chaos engineering solve?
What are the solutions exist?
How to develop your own solution?
What is a controlled failover?
A little about ZendEngine and what tools are out of the box?
A bit about chaos design.
A bit about the code leading to chaos.
Микросервисы, кто-то только слышал о них, кто-то пытался делать, кто-то уже использует в продакшене. Идеи, заложенные в концепцию микросервисов, не новы и основные постулаты уже звучали раньше. Так почему же в последнее время мы всё чаще слышим о микросервисах? Что такое микросервисы для нас и чем они отличаются от старого доброго подхода SOA? Как теперь разрабатывать enterprise-приложения с микросервисным подходом на нашем любимом языке программирования Java?
На эти и некоторые другие вопросы постараемся ответить во время встречи. Наши гости, Кирилл Толкачёв и Александр Тарасов, в режиме live coding попытаются создать небольшой стартап, попутно использовав новомодные подходы и инструменты.
На пути к релизу стартапа будут затронуты основные проблемы выбранных подходов в целом и технологий в частности:
Микросервис — что это, для чего и как с этим дальше жить. Где теория брат? ;)
На чём писать API: REST или RPC, и почему Thrift имеет право на жизнь в эпоху тотального распространения JSON-а. Упрощай и превозмогай с помощью Spring boot starter;
Какой стек выбрать для разработки, что выбрали мы и почему. Небольшое сравнение легковесных и не очень java фреймворков а так же сопутствующих инструментов;
Способы упаковки, дистрибуции и разворачивания микросервисов, как Spring Boot и Docker помогают нам в решении этих непростых для разработчика проблемах;
Как микросервисам найти друг друга, как готовить Spring Cloud и как обойти существующие проблемы и ограничения. Не доверяйте технологиям, доверяйте только себе;
API Gateway. Предохраняй и сохраняй свои микросервисы.
Так же речь пойдет о других распространенных проблемах распределенных систем и их решениях.
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Highload...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Highload и стартап на Java - как совместить?", Александр Константинов (основатель FriendRent, разрабочик в JetBrains)
Аннотация
Если долгое время создавал высоконагруженные и распределенные системы, а затем начал делать стартап, то в голове сразу же прорисовывается архитектура, которая должна быть у такого сервиса. Однако понятно, что создать за месяц большую и сложную систему - крайне затруднительно. Работая в Яндексе и JetBrains, мы накопили большой опыт разработки таких сервисов. В своём докладе я расскажу, как создать в стартапе архитектуру так, чтобы это заняло минимум времени, но при этом система могла бы легко выдержать миллион просмотров в месяц. От чего стоит отказаться, а на что наоборот следует обратить внимание, как упрощать систему, но при этом оставлять возможность расширения. Ключевые слова: Java, Spring, MySQL, JSP, Nginx.
Биография
Совладелец проекта FriendRent повященного аренде недвижимости через социальные сети. Senior Developer в компании JetBrains. В студенческие годы разрабатывал приложения для Вконтакте.
D2D Pizza JS Илья Беда "Куда мы все катимся?"Dev2Dev
Окружение JavaScript, наверно, самая быстроразвивающаяся отрасль в мире разработки программного обеспечения. Все слышали шутку про книгу “36 новых JavaScript фреймворков, выпущенных в марте”, и это не далеко от правды.
В своем обзорном докладе я расскажу о своем пути во frontend. О том, как вижу современную индустрию, о существующих проблемах и путях их решения. Все не так уж радужно, как может показаться. Надеюсь, мой доклад позволит вам взглянуть на мир JavaScript с другой стороны или, по крайней мере, задуматься о том, в правильном ли направлении вы движетесь?
Доклад с конференции D2D Pizza JS - http://dev2dev.ru/events/8/
В рамках доклада я хотел бы рассмотреть сложности, которые мы испытываем с построением инфраструктуры распределенных систем.
Можно ли строить приложения и не думать о серверах и контейнерах? Насколько это будет дорого?
Ответить на эти вопросы помогут принципы «Бессерверной архитектуры». На простых примерах мы рассмотрим из чего состоит приложение, не зависящее от серверов. А также, рассмотрим возможности, которые предоставляют популярные провайдеры облачных сервисов, для построения таких приложений.
Evolution of web-project requires scalable architecture and scalable development process. In my presentation (in Russian): different techniques, how to achieve this if talking about Perl-based web project.
Микросервисная архитектура на базе CoreOS и KubernetesDenis Izmaylov
13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.
В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.
Особенности тестирования 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 в рамках РИФ Воронеж
Jenkins Imperative Pipeline vs Declarative Pipeline Кирилл Толкачёв
Презентация со встерчи JUG MSK про Groovy DSL
Проводитили сравнение новой фичи Jenkins – Declarative Pipelines путем попытки переписать уже существующий пайплайн по доставке ПО на декларативный. Описали подводные камни и обсудили проблемы.
Видео можно будет найти тут https://vk.com/jugmsk или тут https://plus.google.com/communities/115981831554057619568
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
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...
Особенности тестирования 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"
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
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...
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"
5. 5
→ Theory
→ Practice
→ QA
В программе:
1. Дикости 21го века – DevOps и Микросервисы
2. Немного интерактива
3. Проблемы понимания и внедрения этих дикостей
4. Поделюсь своей историей в их осознания
a. Масштабирование на команды
b. Выработанные принципы
c. Используемые инструменты
5. Сделаем быстрые выводы (если успеем)
Agenda
11. Re: Re: Re: Re: Re: Re: ….
Привет Y, Мне сказали ты можешь сделать нам X, сделай! У
нас в проекте DevOps!
С уважением
Работник Большой Компании <Лого Компании>
12. Re: Re: Re: Re: Re: Re: ….
Привет Дружище, мне сказали ты можешь помочь сделать
нам X, помоги нам пожалуйста, ведь у нас в проекте DevOps!
С уважением
Работник Большой Компании <Лого Компании>
13. Re: Re: Re: Re: Re: Re: ….
Привет Дружище, мне сказали ты можешь помочь сделать
нам X, помоги нам пожалуйста, ведь у нас в проекте DevOps!
С уважением
Работник Большой Компании <Лого Компании>
14. Re: Re: Re: Re: Re: Re: ….
Привет Дружище, мне сказали ты можешь помочь сделать
нам X, помоги нам пожалуйста, ведь у нас в проекте DevOps!
С уважением
Работник Большой Компании <Лого Компании>
27. Таблицы половозрелости
Используется Jenkins да Уровень 1
Пишутся тесты да Уровень 1
Автоматизирована доставка да Уровень 2
Еще что то нет Уровень 2
Еще что то сложное нет Уровень 3
62. DevOps – это про взаимоотношения
→ Никто не делает продукт для одного клиента
→ Никто не должен строить процесс вокруг {dev,ops,dba,etc}
→ Работать вместе над всем циклом создания продукта
→ Обучать не только "своих"
→ Не строить стен и колодцев
75. In short, the microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its own process
and communicating with lightweight mechanisms, often an HTTP resource
API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery. There is a bare
minimum of centralized management of these services, which may be written
in different programming languages and use different data storage
technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
75
76. In short, the microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its own process
and communicating with lightweight mechanisms, often an HTTP resource
API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery. There is a bare
minimum of centralized management of these services, which may be written
in different programming languages and use different data storage
technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
76
77. Размер имеет значение?
→ Method/Function = Microservice?
→ 10-300 LOC = Microservice?
→ 1 week = Microservice?
→ 1 developer = Microservice?
77
78. Размер не имеет значения*
→ Single Responsibility
→ One capability
→ Bounded context
“In your organization, you should be thinking not in terms of
data that is shared, but about the capabilities those contexts
provide the rest of the domain.”
– Sam Newman, Building Microservices
*до разумных пределов конечно78
80. In short, the microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its own process
and communicating with lightweight mechanisms, often an HTTP resource
API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery. There is a bare
minimum of centralized management of these services, which may be written
in different programming languages and use different data storage
technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
80
82. In short, the microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its own process
and communicating with lightweight mechanisms, often an HTTP resource
API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery. There is a bare
minimum of centralized management of these services, which may be written
in different programming languages and use different data storage
technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
82
84. In short, the microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its own process
and communicating with lightweight mechanisms, often an HTTP resource
API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery. There is a bare
minimum of centralized management of these services, which may be written
in different programming languages and use different data storage
technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
84
97. Немного LSD для вас
→ три языка программирования
→ два в среднем фреймворка на язык
→ семь типов источников данных
⇢ legacy WS, mongo db
⇢ OLTP, OLAP
⇢ elasticsearch, neo4j
⇢ Мишкина база %)
97
117. ~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.gdg.rostov]:
117
118. ~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.gdg.rostov]:
Define value for 'version' [0.0.1]:
118
119. ~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.gdg.rostov]:
Define value for 'version' [0.0.1]:
srv1
├──srv2
└──srv3
logging
sleuth
Define value for 'dependencies' [logging,sleuth]:
119
120. ~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.gdg.rostov]:
Define value for 'version' [0.0.1]:
srv1
├──srv2
└──srv3
logging
sleuth
Define value for 'dependencies' [logging,sleuth]:
Project created for rent-service!
120
124. 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();
124
125. 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(); 125
132. @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 132
Fluent annotations
133. @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 133
Fluent annotations
136. 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
...
136
137. 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[]
137
138. 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[]
138
139. Payment Service[jar,doc] Insurance Service [jar,doc]
One Point of View
[UberDoc.zip]
Rent Service[jar,doc] Other Service [jar,doc]
Агрегация информации
139
140. Парадокс централизации
Чтобы эффективно разрабатывать распределённые
приложения, нам нужны очень хорошие централизованные
библиотеки и инструменты
Например: логирование, health-checking, метрики,
обработка типовых ошибок, автодокументирование
140
141. Парадокс централизации
Чтобы эффективно разрабатывать распределённые
приложения, нам нужны очень хорошие централизованные
библиотеки и инструменты
Но: не выносите бизнес-логику или доменные объекты!
Не размывайте бизнес-контекст вашего API
141
216. 216
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
229. 1. Не пишите в резюме DevOps Инженер
2. SOA принципы живы
3. Принцип LSD
4. Изоляция данных делает жизнь приятнее
5. Парадокс централизации
6. Планируй ресурсы динамически
7. Любите и поддерживайте друг друга
(и не важно что такое DevOps)
Придерживайтесь принципов
229
230. DevOps – образ мышления
команды, при котором все
осознают что нужно для
предоставления сервиса
https://twitter.com/bsideup/status/906154114991652864
233. 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
233