×Закрыть

Обзор конференции O’Reilly Velocity 2017

Всем привет, меня зовут Дмитрий и я поделюсь с Вами своими впечатлениями о конференции O’Reilly Velocity 2017. Организатор конференции — компания O’Reilly Media. Эта компания была основана в 1978 году в Кембридже, штат Массачусетс. Одним из основных направлений работы компании является выпуск книг. Характерной чертой книг, выпускаемых компанией, является наличие на обложке изображения животного. Одними из первых книг, которые выпустила O’Reilly, были мануалы по UNIX. Они были без каких-либо картинок на обложке и распространялись просто по почте.

Рынок рос, нужно было что-то делать, чтобы улучшить продукт, и одна из сотрудниц (Edie Freedman), которая сейчас работает в компании креативным директором, придумала иллюстрировать обложки книг с помощью изображений животных. У неё было очень туманное представление о UNIX, о терминах в UNIX среде и как-то ей попались на глаза гравюры странных животных, которые у нее вызвали ассоциацию со странными терминами UNIX. И Edie решила разместить изображение тонких лори на одной из первых обложек с животными:

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

Еще одним направлением работы O’Reilly Media является организация конференций. Это список наиболее популярных:

The O’Reilly Open Source Convention (OSCON) — ежегодная конференция посвященная бесплатному программному обеспечению с открытым исходным кодом
— конференция по Big Data
— конференция JavaScript, HTML, CSS

Названия этих конференций говорят сами за себя:

— конференция по Web Performance and Operations, проводится 4 раза в год в разных точках Земного шара

Я посетил конференцию O’Reilly Velocity 2017 в Нью-Йорке. Конференция состояла более чем из 70 сессий и собрала более 1000 участников. Данная конференция посвящена построению и поддержке комплексных распределенных систем. Кроме того, конференции предшествовали несколько дней тренингов для DevOps.

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

Среди основных тенденций, которые обсуждались участниками, можно выделить такие направления:

Internet performance и DNS:

Самыми крупными представителями в этой области на конференции были Google и Oracle, кстати Oracle попал в этот бизнес купив компанию Dyn несколько лет назад.

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

  • Высокую скорость DNS resolution (перевод доменного имени в IP-адрес). По их мнению, DNS resolution может занимать порядка 30% процентов времени на загрузку сайта. И соответственно, они делают всё, чтобы это время минимизировать, применяя кэширование и очень быстрое распространение DNS записей. Для ускорения загрузки сайтов, предлагают размещать клоны сайта в географически разных data-центрах и открывать пользователю ближайший к нему, используя геолокацию.
  • Смягчение последствий DDos атак, отслеживая и блокируя такие запросы до того, как они начнут оказывать влияние на работоспособность сайта их клиента. Ярким примером является невысокая цена «заказа» атаки на домен конкурента в период рождественских распродаж.
  • Мониторинг и логирование

Распределенные системы:

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

Контейнеры

В этом направлении мне запомнился доклад, на котором рассказывали о том, как правильно использовать пароли, сертификаты и другую конфиденциальную информацию в контейнерах. Подробности можно найти здесь. Там же упомянули и о манифесте 12-факторного приложения. Данный манифест был разработан компанией Heroku и содержит в себе набор правил для разработки приложений, которые в первую очередь готовы к развертыванию в облаке Heroku. Но постепенно эти правила начинают работать для многих облачных провайдеров и полезны для разработки web приложений, которые:

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

Микросервисы

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

Таким образом, классическое enterprise web приложение состоит из трех звеньев: базы данных, frontend и backend. Backend обрабатывает HTTP запросы, выполняет бизнес логику, извлекает и обновляет данные в базе данных и формирует представления для браузера. Это и есть монолитное приложение, грубо говоря один логический блок. Для того, чтобы такая система заработала, разработчик должен ее собрать и развернуть под сервером приложений.

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

По своему опыту скажу, что выбор архитектуры (Monolithic или Microservice) зависит от конкретного случая. И далеко не всегда Microservice является идеальным решением.

Serverless является неким следующим шагом за микросервисами. Суть подхода заключается в отсутствии аппаратного сервера и сервера приложений. На самом деле, всё это есть на стороне поставщика Serverless, но ни у разработчиков, ни у админов нет физического доступа, зато есть возможность собрать сервис и загрузить его поставщику Serverless, который в свою очередь запустит его в независимом контейнере. В результате разработчики занимаются написанием алгоритмов, а DevOps инженеры — инфраструктурой. К основным преимуществам можно отнести:

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

Из недостатков можно выделить:

— Определенную специфику работы сервиса, которая зависит от поставщика Serverless. Например, холодный старт и ограничения в лямбдах в случае с AWS.
— Сложность развертывании системы локально. Соответственно, код приходится загружать поставщику Serverless, чтобы протестировать изменения.
— Дополнительную сложность системы.

Подводя итоги, могу сказать, что, если Вы понимаете, что Linux shell и DevOps не Ваше, то есть смысл пробовать Serverless.

Моя деятельность в компании AMC Bridge связана с оказанием сервиса в области разработки программного обеспечения, а не Dev Ops, поэтому я ожидал от конференции немножко больше, но все равно впечатления положительные: и материал конференции, и организация были на высоком уровне.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Подписаться на комментарии