{"id":13597,"url":"\/distributions\/13597\/click?bit=1&hash=ce14b8b4846314ce80a009b52128dfe4276b036f8de856a8737e7c40a3353b88","title":"\u0410\u0432\u0442\u043e\u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0431\u0430\u0437\u044b \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u0438 \u043a\u043e\u043d\u0432\u0435\u0440\u0441\u0438\u044f \u0432\u044b\u0448\u0435 \u043d\u0430 30% \u2014 \u0445\u043e\u0442\u0438\u0442\u0435?","buttonText":"\u0425\u043e\u0447\u0443","imageUuid":"97137c64-f668-5e69-98d1-d58d5d17653d","isPaidAndBannersEnabled":false}
Сервисы
VK Cloud

Зачем крупным компаниям микросервисы, контейнеры и Kubernetes: как эти три технологии выводят IT на новый уровень

И в чем российские компании пока отстают от мировых трендов: смотрим на реальных кейсах.

Выпуская цифровые сервисы, даже крупный бизнес вынужден использовать стартап-подход. Ведь разрабатывать и выводить новые продукты на рынок нужно быстро, одновременно не забывая о качестве обслуживания клиентов, — только так можно выжить в высококонкурентной среде. Кроме того, компаниям важно сразу получать дополнительные IT-ресурсы, когда нагрузки на сервисы растут, и не переплачивать за них во время спадов активности пользователей.

В этом помогают такие технологии как микросервисы и контейнеризация, а для управления ими используют Kubernetes — этот инструмент уже стал стандартом разработки и позволяет IT-отделам создавать продвинутые архитектуры для достижения бизнес-целей компании.

Расскажем, что это за технологии, как они работают и когда стоит подумать об их внедрении.

Краткая справка: что такое микросервисы, контейнеры и Kubernetes

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

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

Упрощенно можно сказать, что в случае монолита все компоненты приложения находятся в одном блоке, а в случае микросервиса — части приложения раскиданы по разным блокам, при этом, как правило, в одном блоке находится одна функция или компонент приложения.

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

Слева — монолит, а справа приложение разбито на микросервисы

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

Микросервисы упакованы в контейнеры, чтобы исключить сюрпризы при развертывании кода

Естественно, что большие приложения — это много контейнеров с микросервисами внутри. Чем больше приложение, тем больше у него составных частей. Всем этим добром: и контейнерами, и серверами, на которых они запущены, — надо управлять. Для этого и придумали Kubernetes. С его помощью можно одной кнопкой обновить нужную часть приложения, откатить обновление назад, выделить ресурсы там, где их не хватает, и сократить мощности там, где их много.

Kubernetes управляет контейнерами, внутри которых находятся микросервисы с частями приложения

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

Такие технологии, конечно, дают целый ряд преимуществ — и разработчикам, и бизнес-подразделениям. Посмотрим, как и для чего используют Kubernetes известные компании.

Какие бизнес-возможности можно получить, внедрив Kubernetes

Kubernetes — сложная технология, которая находится под капотом многих цифровых сервисов известных компаний. Посмотрим, кто использует Kubernetes на практике и какие преимущества он позволяет получить.

Быстрый вывод продуктов на рынок за счет эффективности разработки

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

Кроме того, он позволяет разработчикам использовать множество готовых решений и стандартизировать процессы, что также ускоряет Time-to-Market, то есть время вывода сервисов на рынок.

DevOps-инженеры и разработчики могут применять множество инструментов, совместимых с Kubernetes: для мониторинга и анализа, управления приложениями, построения CI/CD и других задач. IT-отделу удобно работать, а компания получает все преимущества новых технологий.

Вот несколько примеров.

Airbnb перешли от монолитной архитектуры к микросервисам. Целью было масштабировать процесс непрерывной разработки и доставки приложений так, чтобы около 1 000 инженеров компании могли одновременно настраивать и развертывать более 250 критических сервисов. В результате IT-команда Airbnb может выполнять в среднем более 500 развертываний в день. А значит, вовремя обновлять свои сервисы и поддерживать конкурентоспособность.

The New York Times — сегодня на Kubernetes работает большинство клиентских приложений компании. Решающее значение при выборе сыграло увеличение скорости развертывания и производительности. Ранее развертывания занимали до 45 минут, а теперь выполняются всего за несколько минут. Разработчики могут самостоятельно отправлять обновления тогда, когда это нужно, а не запрашивать заранее ресурсы и не ждать еженедельного развертывания по расписанию, как это было раньше.

J.P.Morgan — крупнейший американский банк перенес на Kubernetes более 3 000 приложений на .NET и Java. Это позволило улучшить среднее время вывода продуктов на рынок, на 700% повысить производительность, сократить утилизацию инфраструктуры на 300% и на 45% уменьшить расходы.

Adidas — перенесли весь интернет-магазин на Kubernetes за полгода. Время загрузки сайта сократилось вдвое. Обновления стали развертывать 3-4 раза в день вместо раза в 4-6 недель. Быстрый, надежный и удобный интернет-магазин компания называет своим конкурентным преимуществом.

Автоматическое распределение ресурсов, чтобы без проблем пережить рост трафика и пользователей

Когда нагрузка на IT-сервисы меняется, например, растет трафик во время распродажи, систему нужно масштабировать — добавлять к ней дополнительные ресурсы, чтобы справиться с новой нагрузкой.

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

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

Компания не переплачивает за мощности, когда они ей не нужны, то есть оптимизирует затраты на IT, в том числе за счет улучшения утилизации в 2-3 раза, и не рискует потерять клиентов из-за того, что приложение зависло во время роста обращений.

Вот несколько реальных примеров.

Tinder. Из-за большого объема трафика инженерная команда Tinder столкнулась с проблемами увеличения мощностей и стабильности работы. Kubernetes стал выходом из ситуации: на него перенесли 200 сервисов — это 48 000 работающих контейнеров. Перенос помог обеспечить бесперебойную работу бизнеса. В устаревшей инфраструктуре при росте трафика приходилось несколько минут ждать подключения новых ресурсов. С Kubernetes это происходит за несколько секунд.

Spotify — аудиоплатформа с миллионами пользователей, которая одной из первых начала использовать Kubernetes. И теперь извлекает немалую выгоду из автоматического масштабирования, оптимизируя затраты на IT. Кроме того, Kubernetes позволяет за секунды и минуты запускать новые сервисы — ранее этот процесс занимал более часа.

Pokemon Go быстро вырос до 500 миллионов загрузок и более 20 миллионов активных пользователей в день. Инженеры компании никогда не думали, что их пользовательская база увеличится в геометрической прогрессии за такое короткое время, серверы не справлялись с трафиком. Ресурсов не хватало из-за активности миллионов пользователей по всему миру в режиме реального времени. Kubernetes помог обеспечить бесперебойную работу приложений, а разработчики смогли сконцентрироваться на новых функциях игры.

Возможность быстро внедрять новые технологии: облачные сервисы, машинное обучение, большие данные, AI

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

Технологии, с которыми сочетается Kubernetes

Облачные сервисы, работа с облачными приложениями и гибридными облаками. С Kubernetes проще перенести приложения в облако, можно управлять ими как on premises, так и в облачной среде. Это особенно актуально, если компания использует гибридную инфраструктуру, например, тестовые среды в облаке, а основная разработка на своих серверах.

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

Kubernetes поддерживает специальный механизм, который называют федерация кластеров (один кластер — группа серверов в составе Kubernetes). Он позволяет синхронизировать работу кластеров, находящихся в разных облаках, и управлять ими. Например, сейчас такой механизм позволяет совместно использовать кластеры (и находящиеся на них приложения) в облаке Mail.ru Cloud Solutions и AWS.

Машинное обучение и искусственный интеллект. Для построения и обучения нейросетей необходимы большие вычислительные мощности. С помощью Kubernetes можно эффективно использовать ресурсы и проводить все вычисления внутри кластера. Исследователю данных или инженеру ML нужно только очистить данные и написать код. Остальное сделает Kubernetes.

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

Большие данные. Kubernetes разработан специально для высоких нагрузок, поэтому идеально подходит для Data Science и работы с большими данными, он легко интегрируется с облачными Big Data-решениями. Аналитикам компании будет проще выстраивать пайплайны для работы с большими данными и извлекать из них нужную информацию.

Вот, что скрывается под капотом эффективной системы BI-аналитики

Как развернуть Kubernetes: почему в облаке

Переход на Kubernetes не так прост: чтобы использовать его возможности на 100%, надо поработать над архитектурой, нужна помощь узкоспециализированных экспертов, процесс развертывания из коробки может занять несколько недель.

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

Облачная модель также позволяет экономить на расходах за счет оплаты только за используемые ресурсы и сокращения издержек на тестовые среды в 2-3 раза.

Например, Wunderman Thompson — старейшее диджитал-агентство России, перенесли инфраструктуру на Kubernetes в облако Mail.ru Cloud Solutions, чтобы не заниматься инфраструктурой кластера, концентрироваться на разработке и платить только за используемые ресурсы.

А в «УРУС» попробовали Kubernetes в разных видах: самостоятельный деплоймент на Bare Metal, в Google Cloud, а затем перенесли свою платформу в Mail.ru Cloud Solutions. Благодаря автоматизации процессов разработки и CI/CD Kubernetes в компании занимается всего один специалист, удалось минимизировать затраты и быстро получать нужные ресурсы и сервисы.

Что еще почитать по теме:

0
25 комментариев
Написать комментарий...
yesYouStp

“Одно из преимуществ микросервисной архитектуры в том, что части приложения можно разрабатывать и обновлять независимо — например, обновить только один блок, а остальные не менять.” - а в монолитном приложении нельзя обновить только один блок? То есть если я делаю авторизацию, то мне обязательно нужно весь код потеребить остальной, только потому что я пишу монолитное приложение? Лепят абстракцию над абстракцией лишь бы бабок заработать. 
 
Даю новую идею, создать сервис, который бы управлял кубернетесом, не иметь один кубернетес - а сеть кубернетесов. А над ним еще один. И еще сверху сервис, чтобы управлять всем этим. Сверху еще одну абстракцию. О, вот теперь экономно! Но конкуренты делают новый сервис, где каждая переменная это микросервис, вот это поворот! Теперь у сайта с посещаемостью 3000 чел в день 600 000 микросервисов, вау... У этого лендинга штат из 6 девопсов и корпоративные контракты с майл.ру.Облаком.  Наконец-то можно обновить картинку на сайте без головной боли, как мы раньше жили!

Ответить
Развернуть ветку
Иван Крючков

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

Ответить
Развернуть ветку
Сева Nort

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

Ответить
Развернуть ветку
Иван Крючков

Очень хороший совет. Давайте попробуем спроектировать систему, чтобы при отказе модуля авторизации новые пользователи могли логинится. Можно сделать так, что юзеры, кому токены уже выдали, продолжат работать, но те, кто хочет залогинится, для них система находится в нерабочем состоянии, их не греет, то что все остальное работает. Или допустим сервис по приему платежей вышел из строя, все остальное нормально работает, но юзеры не могут оплачивать, а у это например Озон, где оплата, как и логин - критические части бизнесс процесса.
Технически сервисы независимы, но вы же не оставите оплату или авторизацию сломанными до момента пока фикс будет? Все нормальные люди сделают роллбек. Так и для монолита можно сделать роллбек, в чем конкертное преимущество микросервисов? Небольшйо плюс в том, что у нас может быть некритичный сервис, например по отправке чеков в виде ПДФ, и если он сдохнет, то без него жить можно, и плохо если он потянет все за собой.
У микросервисной архитектуры много плюсов, но независимость это весьма спорный плюс. Технически у получается, что нет SPOF, но фактически без одного сервиса не работает весь бизнес процесс и деньги теряются. 

Ответить
Развернуть ветку
Andrey Pshenichnov

Да, можно было бы рассказать про автомасштабирование, и про decoupling. Спасибо за дискуссию, добавили в текст линк на статью, которая специально про особенности cloud native архитектуры и микросервисов.

Ответить
Развернуть ветку
yesYouStp

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

Ответить
Развернуть ветку
Сева Nort

Вы удивитесь но управление кластерами кубернетиса уже есть - Federation зовется. Статья конечно ни о чем и классический высер МРГ, но вы тоже не очень правы))

Ответить
Развернуть ветку
Roman Kuvaldin

Как правило, в монолитах довольно сложно рестартнуть только кусок процесса

Ответить
Развернуть ветку
Владимир Войтенко
 Но конкуренты делают новый сервис, где каждая переменная это микросервис

О, а это описание aws lambda 

Ответить
Развернуть ветку
Алексей Кузьмин

Что за маркетинговый булшит?

Ответить
Развернуть ветку
Mihael Isaev

Мне так никто и не смог рассказать как я должен сложные запросы в БД делать с кучей джоинов если данные надо раскидать в отдельные БД (по независимой БД на микросервис). Предложили создать ещё один микросервис который будет делать хуиллиард запросов по микросервисам и соединять данные, и это вместо одного комплексного запроса в одну БД. Я когда об этом думаю сразу желаю всего вам самого хорошего с вашими микросервисами, хорошего настроения главное, держитесь там! А я на монолите спокойно поживу.

Ответить
Развернуть ветку
Andrey Pshenichnov

Микросервисная архитектура не требует заводить для каждого микросервиса отдельную СУБД, СУБД можно держать от микросервисов. Если всё это находится в облаке, то это может быть тот же DBaaS

Ответить
Развернуть ветку
Mihael Isaev

По бэст практикам микросервисов они все должны быть самостоятельными, то есть независимыми, и один микросервис не может жить в БД другого и делать там что-либо. Это означает, что максимум, что допустимо, это дать разным микросервисам жить внутри одной БД, но в разных ее схемах, чтобы не нарушать суверенитет каждого микросервиса. Конечно в случае одной БД и разных схем можно чуть менее болезненно сделать микросервис который бы доставал композитные данные из нескольких не делая таааакой большой оверхед, но все равно это жопа, а не подход. А просвета я тут не вижу и рассказать никто не может. Максимум, что я слышу, в ответ на мои аргументированные вопросы, это обвинения в том, что я ничего не понимаю в микросервисах и что я даже данные просто храню не правильно, что мне стоит пересмотреть все на свете, чтобы вообще не иметь композитных данных.

Ответить
Развернуть ветку
Илитный Иксперт

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

Все эти срачи монолит vs микросервисы давно превратились в разборки телок изза цвета сумочки и понтовости бренда.

Иди попробуй клубной чикуле объяснить различия между трансмиссией мерседеса и киа, ей похуй, все что она знает что "мерс это пиздато, а киа для лохов".

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

А ты им вопросы по архитектуре БД задаешь, лол

Ответить
Развернуть ветку
Neo Guru

Привет с пикабу!

Ответить
Развернуть ветку
Andrey Pshenichnov

"один микросервис не может жить в БД другого и делать там что-либо."

В одной СУБД но в разных базах/таблицах вполне может.
Опять же, есть случаи когда БД используется для синхронизации и интерконнекта сервисов. Тут уже дело вкуса и наработанного инстрементария - делать ли такие вещи через очереди или через СУБД.

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

Здесь рекомендации по построению отказоустойчивых приложений в нашем облаке https://mcs.mail.ru/help/infra/fault-tolerant-guidelines

Здесь хороший общий обзор https://tanzu.vmware.com/cloud-native

Ответить
Развернуть ветку
Egor Mikhailov

Тут вариантов не особо много.
Либо делать микромонолиты, у которых единая БД.
Либо делать, как вы сказали, полноценный DAL микросевис, куда бы ходили все другие микросевисы, что опять же микромонолит.

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

Ответить
Развернуть ветку
Сева Nort

Вы даёте сферического коня в вакууме и просите дать конкретный ответ:) что за композитные данные? Почему вашему софту нужны микросервисы? Какую задачу вы решаете?

Ответить
Развернуть ветку
Айрат Хусаенов

Ага, а ещё каждый инстанс должен с собой ещё и отдельный кеширующий Redis и эластик таскать? Где вы такие бест-практисы берете?

Ответить
Развернуть ветку
Иван Хорев

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

Ответить
Развернуть ветку
Dmitrii Ivanov

У вас даже s3 нельзя сделать публичным на GET запросы 

Ответить
Развернуть ветку
Andrey Pshenichnov

Отчего ж нельзя, можно :) Вешаете на файл ACL = public-read, и он становится публичным.
https://mcs.mail.ru/help/storage-api/acl?kb_language=ru_RU

Ответить
Развернуть ветку
Igor Tarasov

Много воды, мало конкретики. Смысл пересказывать общие вещи? 

Ответить
Развернуть ветку
Илитный Иксперт

Да низачем.

Просто очередной тимлид-дурачок узнал модное слово и стал внедрять, а тк в ойти доля шарящих людей давно уже снизилась до 20%, то остальной отдел тупо за ним повторяет.

Тимлид говорит "микросервис!", а весь отдел отвечает "докер, кубернетес, мы крутые программисты!" 

Ответить
Развернуть ветку
Илитный Иксперт

А маркетологи потом пишут тупо рерайт очередной статьи с медиума

Ответить
Развернуть ветку
Читать все 25 комментариев
null