Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации
30 сентября
и 1 октября 2019
Москва, Инфопространство

Заявки на доклады

Поиск по тегам:

Непрерывная поставка

История развития систем CI/CD в Wargaming Platform

Как известно, построение CI/CD — дело непростое. Приглашаю вас за кулисы этого трудоемкого процесса в Wargaming Platform. Я расскажу, какими путями мы двигались и продолжаем двигаться на пути к поставленным целям, и покажу, как мы развивали инструментарий и совершенствовали команду, чтобы решать возникающие вопросы минимальными усилиями.

Доклад принят в программу конференции

НТ в CI/CD большого решения

Как не улететь при нагрузке и проходить QG быстро на примере Единого Биллинга МегаФон.

Оптимизация производительности
,
Непрерывное развертывание и деплой
,
Большие проекты/команды
,
Работа со внешним заказчиком/исполнителем
,
Нагрузочное тестирование
,
Интеграционное тестирование
Доклад принят в программу конференции

Reversive Decentralized Deployment: Zold Cryptocurrency Example

A traditional deployment scenario includes a central point of control, which sends updates to server nodes. In our Zold cryptocurrency project we were forced to create a different and reversive deployment model, where distributed and anonymous servers pull updates from an open public repository and restart themselves. The biggest problems we had to solve were related to error tracking and resolving of exceptional situations. In the presentation I will demonstrate how it works and we will deploy a new version right on the stage.

Управление конфигурацией
,
Непрерывное развертывание и деплой
Доклад принят в программу конференции

Progressive Delivery, for sleeping better at night

All of us enterprise developers are doing proper Continuous Delivery, including end-to-end testing, database migrations, canarying, monitoring, and rollbacks, all in a fully automated approach, right? Most real-world projects are not quite there (yet). The reasons, or excuses, are mostly complexity, insufficient testing, discrepancies between environments, or database migrations.

This session shows how a fully-fledged pipeline approach can be implemented, using Jenkins X, for enterprise applications that run in cloud native environments. We’ll see why automated testing only allows us to fully automate our setup, how to handle data in test scenarios, and how to tackle database schema changes. We’ll have a look at typical scenarios and pitfalls and how to effectively introduce CD without writing much code or configuration ourselves. We’ll furthermore see how Progressive Delivery and automated canarying approaches limit the blast radius of our changes. Join us if you strive to improve how your projects are shipped with fast pace and predictable quality, or if you simply want to sleep better at night.

Миграции данных
,
Непрерывное развертывание и деплой
Доклад принят в программу конференции

DevOps-трансформация

Ускорение сайта Якитория в 5 раз без переписывания кода за счет DevOps-инструментов

В рамках обслуживания сайта Якитория мы провели соревнование между командой администраторов и командой разработки, кто сделает лучшее предложение клиенту. В результате использования DevOps-инструментов мы не только нашли наиболее интересный вариант модернизации проекта, но и ускорили работу сайта в 5 раз, сократив издержки на сервера.

Доклад принят в программу конференции

Приносим DevOps в DWH/BI. Проблемы и их решение

- Как развивать IT-культуру в разработке данных;
- фундаментальные проблемы в DWH/BI с т.з. DevOps;
- как привнести культуру DevOps в работу с данными? Практические советы;
- в чем отличия Pipeline для работы с данными от “классических” приложений;
- какие средства автоматизации реально полезны в контексте работы с данными.

Базы данных / другое
,
Методы и техника разработки ПО
,
Архитектура данных, потоки данных, версионирование
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Совместная работа, система контроля версий, организация веток
,
Корпоративная культура и мотивация
,
Внедрение и поддержка
,
ETL
Доклад принят в программу конференции

Наследование legacy-систем и процессов, или Первые 90 дней в роли CTO

Реальная история в картинках о наследовании устаревших систем и ожидаемых (и неожиданных) проблемах, которые часто идут в комплекте. История о приоритете задач, систематизированном подходе, внедрении Agile и работе с людьми, а также об адаптации к ситуациям, когда весь прошлый опыт оказывается бесполезным.

В этом докладе я поделюсь историями и некоторыми решениями из собственного опыта навигации организаций через DevOps-трансформацию.

Доклад принят в программу конференции

Применение DevOps в разработке сложного кросс-платформенного фреймворка – платформы 1С:Предприятие

1С производит инструменты для быстрой разработки кросс-платформенных бизнес-приложений и рантайм для их работы (общее название – платформа «1С:Предприятие»). Бизнес-софт, разработанный на нашей платформе, работает на Windows, Linux, macOS, Android, iOS, в браузерах, использует СУБД MS SQL, Oracle, IBM DB2, PostgreSQL. Наш софт используют 5 миллионов конечных пользователей в 1.5 миллионах организаций. Исходники платформы «1С:Предприятие» - более 10 млн. строк кода (C++, Java, JavaScript).

С одной стороны, мы производим среду разработки бизнес-софта, и это напоминает Visual Studio или Eclipse. С другой стороны, мы производим рантайм для бизнес-софта, и это продукт типа .NET Framework или Java runtime. Одновременно в работе у нас находится до 6 версий продукта, включая как уже выпущенные и поддерживаемые версии, так и новые, пока не пошедшие в релиз.

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

JavaScript
,
Фреймворки
,
Java
,
C/C++
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Архитектурные паттерны
,
Отказоустойчивость
,
Методы и техника разработки ПО
,
Управление конфигурацией
,
Непрерывная интеграция
,
Совместная работа, система контроля версий, организация веток
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Функциональное тестирование
,
Нагрузочное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
,
Профилирование и отладка кода
,
Тестирование фронтенда
,
Кросплатформенная разработка
Доклад принят в программу конференции

От релиза до FastTrack

· Внедрение в условиях масштабной архитектурной трансформации.
· Высокоскоростное внедрение изменений в распределенной инфраструктуре компании.
· Способы достижения быстрого цикла внедрения.
· Объединенные кросс-функциональные команды как целевая схема взаимодействия с производством вендора.
· Уровни зрелости продуктов и требования к увеличению зрелости.
· Участие заказчика в командах разработки и внедрения.


Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
,
Devops / другое
,
Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Работа со внешним заказчиком/исполнителем
,
Продуктовая разработка
,
Антикризисный менеджмент
,
Enterprise-системы
Доклад принят в программу конференции

DevOps в заказной разработке. Путь к Continuous Deployment в биллинге у телеком-оператора

Поговорим о том:
* как мы живем в биллинге с заказной разработкой от нескольких поставщиков ПО;
* как выполняем сценарии развертывания и управления высоконагруженных биллинговых приложений на базе Jenkins, Ansible, Git, сохраняя требуемый уровень отказоустойчивости;
* как нам удалось построить единый пайплайн управления циклом доставки для всех продуктов по средствам Active Choice Parameter, Shared Library и Scripted Pipeline Jenkins;
* каким образом осуществляется управление сервисами после их установки;
* как обеспечивается катастрофоустойчивость.

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Devops / другое
Доклад принят в программу конференции

Основы DevOps - вхождение в проект с нуля

Многие не понимают саму суть DevOps. Как правильно анализировать спектр проблем, как выстроить план деятельности? Как правильно рассчитать KPI и когда следует вовремя остановиться.

Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Аппаратное обеспечение
,
Сетевое администрирование
,
Devops / другое
Доклад принят в программу конференции

Automation tools don’t fix bad processes

So often, organizations working to adopt DevOps initially focus on selecting tools and manipulating their choices to automate bad practices hoping to maximize efficiency. Automation is the easy part. But without culture transformation and process optimization, an organization will never realize their true potential. Optimizing the system as a whole – a system made up of people, processes and tools - means reviewing, questioning and potentially changing how things are across the entire lifecycle. During this meetup, let’s collaborate on techniques to change culture, the value of mapping the value stream, and the automation tools available to help.

Программный комитет ещё не принял решения по этому докладу

Как стать кросс-функциональной командой

В жизни (почти) каждого ИТ-специалиста рано или поздно наступает момент, когда он попадает в маленькую agile/devops-команду, которая должна раз в 2 недели поставлять клиенту "ценность". Иногда эта метаморфоза случается даже без смены работы - это называют digital-трансформацией. И тогда наш (почти) каждый ИТ-специалист обычно нервно усмехается и говорит: "Камон, ребята, вдесятером за две недели придумать, разработать, протестировать и внедрить новый функционал в высоконагруженный сервис? Да вы издеваетесь!".

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

Распределенные системы
,
Менеджмент в эксплуатации
,
Devops / другое
,
Продуктовая разработка
,
Управление / другое
,
Enterprise-системы
Доклад принят в программу конференции

SRE-практики

Что мы узнали об SRE, когда обработали первые 150к production-инцидентов

Мы в Amixr.IO пропускаем через свой бэкенд production-инциденты клиентов. Готовы поделиться статистикой, инсайтами о том, как десятки команд по всему миру дежурят, разбирают инциденты, организуют работу и строят надежные системы.

Это вариант вводной лекции по SRE через кейсы из реальной жизни, подкрепленные статистикой и нашим опытом.

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Devops / другое
Доклад принят в программу конференции

Почему стартапу нужны SRE-практики

В Prisma мы обрабатываем на сервере более 500 тысяч фотографий в сутки.

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

PostgreSQL
,
Логирование и мониторинг
,
Непрерывное развертывание и деплой
,
GO
Доклад принят в программу конференции

Под капотом хранилища большого облака, или Отказ Шрёдингера

Публичные облака — это и высокие нагрузки, и большая ответственность. Какое бы решение ни было использовано для построения облака, в его основе всегда минимум один компонент, от которого зависят все остальные — блочное хранилище.

Мы расскажем, как из источника проблем превратили блочный сторадж, поверх которого работают сервисы Compute Cloud, в один из самых стабильных компонентов платформы Mail.ru Cloud Solutions. Это блочное хранилище используется большинством компонентов IaaS и PaaS, включая наши сервисы, популярные в DevOps-практике: базы данных Mail.ru Cloud Databases и кластеры Kubernetes в облаке Mail.ru Cloud Containers.

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

Доклад принят в программу конференции

Путь разработчика в SRE. История о том, что может побудить пойти в инфраструктуру целую команду разработчиков и что из этого получилось

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

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

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

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

Методы и техника разработки ПО
,
Архитектуры / другое
,
Менеджмент в эксплуатации
,
Devops / другое
Доклад принят в программу конференции

SDLC & Compliance. Через тернии в продакшн

Когда вы — глобальный банк, и в вашем портфолио десятки тысяч приложений, вам не остается ничего другого, кроме как стандартизировать управление разработкой в масштабах всей компании. Это позволяет поддерживать и демонстрировать комплайнс, а также держать планку качества разрабатываемых приложений. С другой стороны, это не может не накладывать отпечаток на ежедневную рутину подготовки релизов: «все эти ваши процессы, апрувы, контролы — да кто их придумал, вообще?».

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

Большие проекты/команды
,
Управление изменениями, управление требованиями
,
Enterprise-системы
Доклад принят в программу конференции

Как техническими средствами решить проблему «все работает, а пользователь недоволен»

В докладе показывается эволюция съема мониторинговых данных от систем до e2e-сервисов.

В высоконагруженных системах с большим географическим распределением, которые обслуживает распределенная команда из 800+ человек, возникают проблемы, когда операционные системы, базы данных, сервера приложений работают, но в итоге сервис, основанный на нескольких системах, не оказывается, и пользователь недоволен итоговой доступностью системы. Команды, ответственные за системы, говорят: «У нас все хорошо и все работает», пользователь говорит: «Ничего не работает».

Мы покажем, как, начиная от мониторингов отдельно взятых систем, был пройден путь мониторинга серверов, приложений до мониторинга сервиса глазами пользователя. Как на эти показатели KQI начали ориентироваться все технические специалисты, заказчики от бизнеса и вендор, поставляющий решение. В качестве визуального средства мониторинга используется grafana, в ней же построена математическая модель с прогнозом по показателям с итоговым расчетом доступности, ориентируясь на SLO и SLI.

Логирование и мониторинг
,
Менеджмент в эксплуатации
,
Корпоративная культура и мотивация
,
Работа со внешним заказчиком/исполнителем
Доклад принят в программу конференции

Инфраструктура как код

Будущее infrastructure as code - это код на CDK

Многие наши заказчики уже адаптировали подход infrastructure as code. Но чтобы эффективно описать свою инфраструктуру, вам надо стать "YAML-гуру".

В своем докладе я расскажу о новом инструменте AWS Cloud Development Kit, который позволяет описывать инфраструктуру на знакомом языке (Python, TypeScript, JavaScript, Java). Я поделюсь советами, как начать использовать данный инструмент, создавать переиспользуемые компоненты для простого и удобного управления инфраструктурой.

Стандарты кодирования
,
Работа с Amazon
,
Критерии выбора технологий для проекта
,
Архитектуры / другое
,
Управление конфигурацией
,
Непрерывная интеграция
,
Devops / другое
Доклад принят в программу конференции

Паттерны в Terraform для борьбы с хаосом и ручной рутиной на крупных и долгих проектах

Казалось бы, разработчики Terraform предлагают достаточно удобные best practices для работы с AWS-инфраструктурой. Только есть нюанс.

Со временем количество окружений увеличивается, в каждом появляются особенности. Появляется почти копия стека приложений в соседнем регионе. И Terraform-код нужно аккуратно скопировать и отредактировать согласно новым требованиям или сделать снежинку.

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

Мой доклад — про паттерны размещения кода, нацеленные на упрощение автоматизации и дальнейшего развития. Расскажу, как работают такие паттерны и приведу примеры кода. Надеюсь, пригодится всем, кто работает или планирует работать с Terraform вдолгую.

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Devops / другое
Доклад принят в программу конференции

Зачем мы разработали Kubernetes-оператор и какие уроки из этого вынесли

Вы хотите сделать свой Kubernetes чуточку умнее? Научить его правильно восстанавливать сервисы после сбоя, производить масштабирование или редеплой сервисов на определенные события. Мы прошли долгий и сложный путь от разработки Kubernetes-оператора до его деплоя и применения, и мы хотим поделиться нашим опытом.

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

Devops / другое
,
GO
Доклад принят в программу конференции

Применение техник CI/CD для развёртывания и управления BareMetal-инфраструктурой

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

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

В этом докладе я хотел бы поделиться с вами этим опытом и рассказать, как организовать управление большим количеством серверов в нескольких BareMetal-окружениях с использованием Kubernetes, Ansible и Continuous Integration.

Где хранить и как применять конфигурацию, как нам в этом деле помогает Jsonnet. Пара слов о конфиденциальных данных: как правильно и зачем хранить пароли в GIT, почему это удобно. Как организовать структуру репозитория так, чтобы это было удобно как вам, так и для отслеживания изменений для непрерывной интеграции.

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Аппаратное обеспечение
,
Непрерывная интеграция
,
Devops / другое
Доклад принят в программу конференции

Безопасность, DevSecOps

Как (вы)жить без отдела безопасности

Основные темы, которые будут рассматриваться:
1) Основы безопасности. Что и от кого защищаем.
2) Оперативный мониторинг ИТ и ИБ: есть два стула. Основные подходы и параллели в построении мониторинга.
3) Рутинные процессы безопасности.
4) Пересекающиеся процессы ИТ и ИБ.
5) CIS CSC - что это такое и как это внедрять.
6) Регулярные проверки: как и зачем.
7) Enlarge your tools: ИТ-тулкит для безопасности (и наоборот).
8) Про KPI здорового человека. Какие показатели безопасности стоит включить в регулярную оценку?

Доклад принят в программу конференции

Заделываем дыры в кластере Kubernetes

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

Я расскажу о некоторых направлениях атаки на кластер Kubernetes и о способах защиты кластера от них. Расшифрую PSP, RBAC, Resource Quota и Limit Range. И покажу, чем грозит незнание этих терминов.

Технологии виртуализации и контейнеризации
Доклад принят в программу конференции

Могут ли контейнеры быть безопасными?

Как часто вы задумываетесь об изоляции, внедряя очередное решение на основе контейнеров в вашей инфраструктуре? Docker, LXC или rkt нельзя назвать изолированными песочницами — да, они быстры, эффективны, но разделяют общее "хостовое ядро". Атаки на такую инфраструктуру могут иметь катастрофические последствия, особенно если вы существуете в multi-tenancy-окружении.

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

Безопасность программного кода, SQL и прочие инъекции
,
Критерии выбора технологий для проекта
,
Технологии виртуализации и контейнеризации
,
Devops / другое
Доклад принят в программу конференции

Инфраструктурная платформа

Extending MPLS Domain into AWS

Развёртывание и поддержка сетевой инфраструктуры для энтерпрайз-компаний в AWS достаточна проста. Но что, если это телекоммуникационная компания, имеющая свою опорную IP/MPLS-сеть, точки присутствия в десятках стран и желающая идти в Публичные Облака? Я хочу поделиться с вами опытом построения такой инфраструктуры.

Архитектурные паттерны
,
Работа с Amazon
,
Сетевое администрирование
Доклад принят в программу конференции

Как правильно использовать доступный объем хранилища. Рецепт Playkey

* Что такое объем хранилища и эффективно ли вы его используете?
* Как дать нескольким сотням пользователей по 10 Тб доступного для изменения и модификации контента, используя всего 20 ТБ?
* Можно ли “на лету” синхронизировать эти данные между несколькими дата-центрами?
* Можно ли хранить данные пользователей со сжатием в 5 раз и предоставлять их в real-time?
* Как исключить любое влияние пользователей друг на друга при последовательном использовании одной и той же виртуальной машины?

Это те задачи, которые в Playkey уже решены и успешно интегрированы в продакшн, и я хотел бы подробнее рассказать о технологии, это позволившей, - ZFS для FreeBSD и ее свежем форке ZFS on Linux.

Доклад принят в программу конференции

Практический опыт переезда боевого проекта со 100 Гб базы данных из MySQL Percona в кластер на базе Vitess для горизонтального масштабирования

— Горизонтальное масштабирование — проблемы MySQL.
— Партиционирование, шардинг и почему это не всегда возможно.
— Варианты горизонтального масштабирования для MySQL.
— Vitess — запуск и первичная настройка.
— Типичные проблемы и пути их решения.
— Итоговая архитектура.
— Результаты нагрузочных тестов.

Доклад принят в программу конференции

Apache Kafka в Авито: история о трех реинкарнациях

Что общего у брокера сообщений, платформы для потоковой аналитики и QaaS в Авито – все они построены на Apache Kafka. Про эти три кейса использования Apache Kafka расскажу на докладе.

Микросервисы, SOA
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Архитектуры / другое
Доклад принят в программу конференции

Hashicorp Vault и как его готовить для разных команд

* Как правильно готовить Vault для разнообразных команд.
* Доклад будет интересен средним и крупным компаниям, которые хотят внедрить Vault и убрать секреты из общедоступных мест.
* Инженерам, желающим строить сервисы, а не управлять руками.

Доклад принят в программу конференции

Опять витаем в облаках: SSO, Vault, Service Mesh, OpenTracing

Более 3-х лет назад, упав под растущим трафиком, мы перевезли наши приложения в публичное OpenStack-облако. Так началась наша дружба с Terraform, Ansible, Docker, Consul, Nomad, Prometheus и прочими. Про опыт работы с этими инструментами мы стараемся периодически рассказывать.

В этом году мы внедрили Vault для управления секретами и токенами, централизованное логирование, Service Mesh, OpenTracing, тотальный SSO для всех внутренних приложений, а также переводим сервера на cloud-init.

Кроме конкретных решений, которые работают у нас сегодня, хочу рассказать про живой опыт из практики, как мы готовимся к развертыванию мира с нуля, строим мини-пайплайны для внутренних инструментов, разделяем ответственность с продуктовыми командами. Масштаб проблем: 12 площадок в 5 облаках, 300 серверов, 150 приложений (несколько независимых продуктов, адаптированных под разные страны), 6 человек в команде инфраструктуры.

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

Доклад принят в программу конференции

Сделаем микросервисы легковесными снова

Мы живём в сложное микросервисное время. Нельзя просто взять и написать код. От современного разработчика требуется понимание и использование инструментов, которые выходят за рамки кода, отвечающего за бизнес-функционал. Service discovery, centralized configuration, distributed tracing, circuit breaking, API gateway — все эти штуки из удела высшего общества давно превратились в обыденные механизмы, без которых не построить современное приложение. Одно хорошо — обо всём этом уже позаботились другие люди и приготовили для нас замечательные готовые решения. Казалось бы, добавил новую библиотечку в зависимости — и готово, однако всё не так просто — обрастая функциональностью, мы теряем легковесность. Всё это сопровождается постоянным усложнением систем и новыми функциональными хотелками.

В докладе расскажу про способ, как мы в Леруа Мерлен справляемся с ожирением наших микросервисов.

Микросервисы, SOA
Доклад принят в программу конференции