В технической среде микросервисы сейчас хайповая тема, все туда бегут, несмотря на то, что не всем это подходит, не всем это нужно. Эксперты на пресс-конференции Positive Technologies и RBK.money «Плюсы и минусы современных технологий кредитно-финансового сектора», прошедшей в рамках киберполигона The Standoff, обсудили этот вопрос и рассказали о своём видении данного тренда.
«Могу сказать, что она даёт нам, потому что у нас именно такая архитектура. У нас очень большое количество маленьких приложений, которые делают каждую часть своей работы. Они построены в сложно зависимые друг от друга конвейеры, которые потоки платежей. Это хорошо тем, чем меньше у вас приложения, чем меньше у вас кусочки, из которых вы строите систему, тем быстрее вы отдаёте фичи на продакшн. То есть показываете клиентам изменение какой-то функциональности», — рассказал технический директор RBK.money Антон Куранда.
Он также отметил, что если у вас есть одно большое монолитное внутри приложение, оно всегда будет точкой столкновения, условно, разработчиков, которые будут выстраиваться в очередь, чтобы доделать какие-то фичи.
По его словам, с точки зрения микросервисного подхода, вы очень хорошо можете параллелить разработку, и таким образом сделать несколько магическую вещь, «когда, условно, девять женщин родят ребёнка за один месяц». Кроме того это возможность перейти с супер дорого железа на более дешёвое.
«И возможность правильного микросервисного подхода — перейти на работу на большом количестве дешёвого железа, она дорогого стоит. Это немножко ломает парадигму в головах технарей: типо как же так я куплю китайский ноу-нейм сервер, поставлю его в стойку, он у меня сломается, лучше я возьму что-нибудь такое дорогущее, но надёжное. Вот этот подход полностью нивелируется тем, что микросервисы умеют работать в кластерах. Это большое количество маленьких приложений и отказ какой-то железки для них штатная ситуация скорее, чем какой-то аварийный кейс», — пояснил эксперт.
Но и вопросы безопасности не стоит оставлять в стороне. При работе с микросервисами потребуются более зрелые и сильные ИТшники. Потому что тут придётся ставить не две базы данных, например, а придётся ставить кластер. И так как железо дешёвое, его придётся тоже ставить больше. И опять же чем больше в системе компонентов, тем она более уязвима.
«Это самый большой риск в безопасности, который я вижу. Потому что уследить, условно, за одной базой данных, в которой у вас всё крутится, полегче, а уследить за сотней микросервисов (а это среднее количество для больших систем) намного труднее», — отметил Антон Куранда.
Директор по методологии и стандартизации Positive Technologies Дмитрий Кузнецов согласился со своим коллегой по поводу правильного использования микросервисов. По его словам, когда у вас монолитное приложение и релиз раз в квартал, раз в квартал можно выделить дополнительную неделю на оттестирование релиза, прогнание его через анализаторы кода, то есть по максимуму найти уязвимости, которые неизбежно возникают в процессе разработки. Но когда мы говорим про микросервисную архитектуру, разработчик может сказать, что у него тысячи релизов и он не может остановить процесс.
«И вот этот тезис «у меня тысячи релизов в день» позиционируется как карт бланш «я не буду следить за качеством кода, потому что у меня лапки, это невозможно». На самом деле это лукавство, потому что да, у вас тысяча релизов в день, но разработка каждого микросервиса — это, условно, неделя, код маленький. Потратьте к этой неделе ещё 5 часов на дополнительное тестирование конкретно этого фрагмента кода этого микросервиса и после тестирования анализа уязвимостей выпускайте его в релиз. У вас разработка удлиниться ну на день, с учётом устранения уязвимостей. Но тем не менее следить за качеством кода вы по-прежнему сможете. Вот это вот позиционирование «У меня тысяча релизов, я не буду заниматься качеством кода» прям с точки зрения безопасности это беда», — высказал своё мнение Дмитрий Кузнецов.
«Маленькая ремарка. Я полностью согласен, что невозможно, что это преступление сейчас в наше время, игнорировать эти риски инфобезопасности у себя в архитектуре. Поэтому такой переход в том числе налагает на вас создание так называемого DevSecOps, когда вы максимально автоматизируете ваш конвейер выкатки микросервисов, встраиваете туда анализаторы кода, встраиваете вплоть до пентеста автоматизированного, который смотрит на всю систему. И только после этого выкатываете фичу на продакшн. То есть здесь я считаю преступлением говорить, что мы очень быстрые и нам плевать на безопасность. Вы не должны так делать», — добавил Антон Куранда.
BIS Journal — стратегический медиапартнёр The Standoff.
(4).jpg)
(3).jpg)
