ИТ-инфраструктура в ритейле – поиск компромиссов или фундамент для роста?

Сергей Зинкевич,
Директор по развитию бизнеса
КРОК Облачные сервисы

Максим Морарь,
Менеджер по развитию бизнеса
КРОК Облачные сервисы

Дмитрий Кузеванов,
технический директор, «Азбука вкуса»

Сергей Зинкевич. Как «Азбука вкуса» пережила 2022 год и с чем вошла в 2023? Похожа ли ваша ситуация на ситуацию других заказчиков?

Дмитрий Кузеванов. Не лучше и не хуже, чем другие. Были сложности, которые мы все вместе преодолевали. Мы прошли год  без остановки процессов, торговли и инфраструктуры. 

Сергей Зинкевич. Насколько сложно было обеспечить бесперебойную работу в течение года? Было ли это сложнее, чем в 2020 и 2021?

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

Максим Морарь. Насколько «Азбуке вкуса» актуален переход с зарубежных систем? Например, компании из госсектора не могут остаться на импортном ПО и должны переходить на российские решения в определенные сроки. Есть ли у «Азбуки вкуса» – коммерческой компании, ориентированной на развитие бизнеса и технологий, возможность использовать ключевые решения зарубежных вендоров?

Дмитрий Кузеванов. Нам повезло. К  коммерческим компаниям нет таких жестких требований в отношении инфраструктуры или программного обеспечения, как к компаниям в ключевой инфраструктуре, банковской сфере или госсекторе. У нас есть выбор и мы можем мигрировать на любой облачный сервис, который удовлетворяет требованиям бизнеса. Законодательные и регламентирующие документы, которые обязывают иметь российскую операционную систему или ПО, лицензированное ФСТЭК, к нам не применяются. 

Сергей Зинкевич. Мы часто спрашиваем наших гостей о связке ИТ и бизнеса. ИТ в «Азбуке вкуса» – драйвер роста или сервисная функция?

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

Например, когда вы приходите к нам за любимым продуктом, наша задача сделать так, чтобы этот продукт оказался на полке. Его необходимо закупить, доставить, учесть и продать. На каждом этапе используется определенная система –  TMS, WMS, ERP. Кроме того, у нас работают люди, поэтому есть система управления зарплатами и кадрами. Есть кассы, на которых вы оплачиваете товар картой, есть банковские терминалы, кассовое ПО, которое обслуживает эти операции, фискализация и т. д. 

Весь бизнес пронизан ИТ, и отделить одно от другого не получится. Это синергия — ИТ для бизнеса и бизнес для ИТ.

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

Сергей Зинкевич. Сейчас очень популярна  методология DevOps – перехода от монолитных приложений к микросервисным архитектурам. Как «Азбука вкуса» относится к этому тренду? Актуально ли это для ритейлера?

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

Сергей Зинкевич. Где «Азбука вкуса» переходит на микросервисную архитектуру и почему?

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

Максим Морарь. Вы ощутили сокращение time to market при переходе с монолита на сервисную архитектуру, с учетом того, что в «Азбуке вкуса» развита  DevOps-культура, CI/CD-подходы и практики и т. д.? 

Дмитрий Кузеванов. Ощутили, хотя столкнулись и с негативными факторами. Для того чтобы перейти с монолита на микросервис, монолит необходимо «распилить». Соответственно, time to market зависит того, чем вы пользовались до создания микросервисной архитектуры, поскольку «распиливание» монолита занимает огромное количество времени, которое, по сути, является отложенным техническим долгом. 

Сергей Зинкевич. Вы подходите к задаче оценки целесообразности как к оценке TCO, то есть, выделяете, например, год на переход и результатов ожидаете после него? Как принимается решение о переходе?

Дмитрий Кузеванов. Есть стратегия и потребности бизнеса в формировании тех или иных продуктов, а также несколько направлений. В стратегии могут появиться несколько витрин, например, консьерж-сервис, торты на заказ, нутрициология, B2B-продажи, которые представляют собой такие же интернет-витрины, как и основной интернет-магазин. Если не предусмотреть модульную (сервисную) архитектуру, в каждом направлении будет свой небольшой монолит со своей авторизацией, оплатой, фискализацией, каталогом и т. д. Для них путь от идеи до адекватного вывода займет полгода-год. При этом модули с определенной логикой работы, определенной функцией и алгоритмом взаимодействия можно использовать для создания витрин намного быстрее.

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

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

Сергей Зинкевич. Поменялся ли ИТ-штат в связи с появлением других задач при переходе на микросервисы? 

Дмитрий Кузеванов. Сформировалось несколько продуктовых команд по разным направлениям, которые состоят из специалистов с необходимыми компетенциями. В продуктовую команду входит бизнес-аналитик, системный аналитик, разработчики, тестировщики и (иногда) технический писатель. Такая команда может развивать один из сервисов, например, платежный шлюз. 

В 2015-16 годах наш монолит был на определенном стеке, большинство специалистов специализировались на нем и могли работать только с монолитом. С тех пор многое изменилось и появилось много других направлений, в том числе Java-разработка, PHP-разработка, мобильная разработка для iOS и Android.

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

Сергей Зинкевич. Переход на микросервисы и в целом DevOps-культура меняют требования к инфраструктуре? Вам все также удобно пользоваться серверами или надо перемещаться в облака? Как вы делаете этот выбор?

Дмитрий Кузеванов. С переходом в облака мы получили полностью автоматизированные развертывание всех компонентов и накатку программного обеспечения.

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

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

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

Дмитрий Кузеванов. Оплата за фактически потребляемые ресурсы очень удобна для бизнеса. При использовании собственной инфраструктуры оплачивается и ее эксплуатация в будущем. Если необходимо докупить сервер или стойку серверов, нет возможности сегодня увеличить мощность на 10%, а завтра ее убрать. При использовании облака мы в любой момент можем увеличивать или уменьшать объем инфраструктуры.

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

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

Максим Морарь. Учитывая тот факт, что в «Азбуке вкуса» достаточно развито управления затратами, вы рассчитывали стоимость использования облака в течение 3-5 лет? 

Дмитрий Кузеванов. Если рассматривать период в 5 лет, то есть средний срок эксплуатации оборудования, то в результате перехода в облако мы получаем снижение затрат на инфраструктуру на 19,4%. Эта сумма рассчитана с учетом всего оборудования, которое нам пришлось бы закупить, поддерживать и сопровождать. Кроме того, мы учитывали ЗИП, замену оборудования, работу сотрудников и т. д. 

Максим Морарь. И за эти пять лет вы можете дополнительно сэкономить, если будете менять уровень потребления. Таким образом, выгода ощутима даже при прямом сравнении без учета пользовательского опыта, автоматизации, биллинга, портала самообслуживания и т. д.

Дмитрий Кузеванов. По нашим расчетам, переход в облако влияет еще на три фактора. 

Во-первых, производительность. В среднем производительность нашей инфраструктуры на 25% меньше того, что мы получаем в облаках. Например, облачные процессоры работают быстрее.

Второе - отказоустойчивость. У нас отказоустойчивость была 97,5%.  В облаках мы получаем 99,5%. Дополнительные 2% — это очень много, например, если оценивать работу интернет-магазина. 

И третий фактор – time to market. Команда получает инфраструктуру не за 3-5 дней, а через несколько часов после описания требований. 

Сергей Зинкевич. Наш заказчик при переходе в облако получил дополнительный результат, который не мог предсказать «на берегу». Затраты переложили на продуктовых менеджеров. Таким образом, каждый продуктовый менеджер стал решать, сколько ресурсов ему необходимо в облаке. Это позволило оценить, сколько стоит инфраструктура, поскольку разносить затраты по собственному оборудованию сложно и не всегда объективно. 

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

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

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

Сергей Зинкевич. Потребление у нашего заказчика, о котором я рассказал, росло в облаке 16 месяцев подряд. После того как технический директор оценил затраты на по каждому продукту, в течение 4 месяцев потребление не менялось, потому что все продуктовые менеджеры приняли решение более тщательно контролировать затраты на инфраструктуру. Такая прозрачность делает затраты на инфраструктуру не просто цифрой в конце отчетного периода, а рычагом управления. 

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

Сергей Зинкевич. Более того, если у корпоративного заказчика, который имеет хотя бы 5 стоек с оборудованием, поделить все процессоры на всех, утилизация будет очень низкой — 3,5-4%. 

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

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

Дмитрий Кузеванов. Кроме того, можно вспомнить про autoscaling в Kubernetes, который сделает все за вас, и платить придется только за использованную инфраструктуру.

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

«Азбука вкуса» — это ритейлер, задача которого сделать покупателям хорошо в магазине: предоставить ассортимент продуктов, эмоции, другие сервисы. Поэтому нам необходимо сконцентрироваться именно на этом,  не возиться с серверами, не заниматься поиском замены вендорам, которые ушли, запасных частей и т. д.

На рынке много игроков, для которых профильный бизнес – инфраструктура, они лучше знают, где быстрее и надежнее приобрести оборудование,  и предоставляют услуги высокого уровня. Если вы хотите купить пакет молока, вам не придет в голову открыть собственный магазин или заняться импортом. За молоком вы пойдете в магазин. Это справедливо и в отношении серверов. Чтобы получить рабочую инфраструктуру, не обязательно заниматься импортом оборудования.

Сергей Зинкевич. Аутсорсинг все чаще становится рабочей моделью. Очень много команд начинают применять именно такой подход и передавать инфраструктуру на аутсорс, чтобы сосредоточиться на основных ценностях своих компаний и конкурировать именно на этом поле. 

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

Вопрос. Есть мнение, что покупка сервера равна  одному году аренды. Так ли это?

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

Вопрос. Провайдеры готовы компенсировать стоимость простоя в случае заключения контракта SLA? 

Сергей Зинкевич. Разумеется, ни один провайдер не компенсирует потенциально упущенную выгоду. Компенсация — это бизнес страховых компаний, а не облачных провайдеров. Чтобы убрать зависимость от любой третьей стороны, необходимо страховать бизнес или его часть. Это относится к облачным сервисам и любым другим услугам. В SLA прописана наша ответственность за инциденты, и в случае нарушений мы несем финансовую ответственность. Упущенная выгода покрывается страховкой. И если потенциальная выгода огромна, страховаться необходимо.

Вопрос. Какие недостатки облачной инфраструктуры вы видите?

Дмитрий Кузеванов. В облаке не всегда доступна функциональность, которую можно реализовать в собственной инфраструктуре. 

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

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

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

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

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

Вопрос. Как в «Азбуке вкуса»  принимается решение, где разместить новый сервис или проект — в облаке или на собственной инфраструктуре?

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

Вопрос. Как в облаке обеспечивается конфиденциальность? Как организован доступ и защита персональных данных? Как в целом организована безопасность?

Сергей Зинкевич. Облачный провайдер – всегда у всех на виду. Поэтому мы в своей работе опираемся на множество стандартов и практик безопасности, в том числе PCI DSS. Помимо внутренних правил, которые необходимо соблюдать, мы дважды в год проходим тест на проникновение от внешней компании. Мы в любой момент имеем результаты пентеста не старше полугода, что гарантирует безопасность. Как часто инфраструктура обычных компаний проходит такой тест на проникновение? 

Наш ответ на вопрос о безопасности персональных данных — аттестат соответствия защищенности информационных систем в облаке федеральному закону 152-ФЗ. В Облаке КРОК можно размещать данные до УЗ-1. Разумеется, когда вы переносите свою информационную систему в облако, вы должны ее также аттестовать и описать свою модель угроз, однако в части инфраструктуры можно положиться на нас. И мы поможем вам обеспечить соответствие требованиям закона об обработке персональных данных благодаря накопленному опыту таких проектов.

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

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

Сергей Зинкевич. Шифрование будет вам стоить плюс 20% к вычислительным ресурсам. 

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

Дмитрий Кузеванов. У сервиса есть несколько окружений: продуктивное, UAT (User Acceptance Testing), TEST, DEV. TEST и DEV не должны содержать реальные данные. Но очень часто берут копию базы с прода, заливают на DEV, где разработчик ее использует, но забывает маскировать.  К DEV имеет доступ практически любой пользователь в домене, как правило, по стандартному паролю. Либо разработчик пытается развернуть все локально, и данные «утекают» с его компьютера. 

Сергей Зинкевич. Вопрос защиты очень важный и мы им занимаемся. При этом вопрос конфиденциальности в облаках решен очень качественно.

Вопрос. Есть ли на данный момент у «Азбуки вкуса» потребность в ИТ-специалистах? Какие требуются роли — разработчики, DevOps и т. д.?

Дмитрий Кузеванов. Потребность есть всегда, особенно в квалифицированных специалистах. Все наши вакансии публикуются на HeadHunter.

Сергей Зинкевич. Мы в КРОК испытываем кадровый голод. Я не помню ни одного года, когда мы бы его не чувствовали. 

Максим Морарь. При этом мы испытываем кадровый голод по множеству направлений. Например, последние 3-5 лет нам не хватает DevOps-специалистов. Мы постоянно принимаем на работу специалистов по Linux, Windows-инженеров, сетевиков, специалистов по защите ИТ-инфраструктуры и т. д. Не хватает всех.

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

Максим Морарь. Если рассматривать финансовую сторону с точки зрения бухгалтерского учета, мы можем предложить расходы на инфраструктуру в качестве как операционных, так и капитальных расходов в зависимости от того, что выгодно заказчику. Но переход в облако затрагивает cash flow, поскольку вне зависимости от учета таких расходов в качестве OPEX или CAPEX, платить придется только за то, что было использовано. 

Вопрос. От каких облачных сервисов, которые ушли из России, было сложнее всего отказываться?

Дмитрий Кузеванов. От пользовательских сервисов, таких как Zoom, почта. Но сегодня на российском рынке есть много достойных продуктов, которые активно развиваются с учетом повышенного спроса. 

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

Дмитрий Кузеванов. Для меня откровением стал Телемост, о котором никто не знал до определенного момента, а сейчас решение активно развивается. 

Сергей Зинкевич. Для ВКС мы используем IVA и TrueConf. 

Максим Морарь. Сейчас это самые популярные решения в корпоративном сегменте, где в компаниях тысячи пользователей. Они используют решение и из облака, и on premise.

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

Сергей Зинкевич. Мы сами пользуемся российскими сервисами. Многие команды очень быстро реагируют на обратную связь от пользователей.  Сейчас довольно легко встроится в roadmap практически любого производителя, предложив недостающую функциональность. В результате мы не ждем новые функции 6 лет, а получаем их в проде уже через 2-3 месяца.

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

Вопрос. Какой фокус развития вашего облака на 2023 год? Какие новые сервисы можно ожидать?

Сергей Зинкевич. В прошлом году мы выпустили множество новых платформенных сервисов (PaaS), развитие которых будет продолжаться в течение 2023 года. Мы будем запускать еще больше PaaS, связанных с базами данных, сервисами кэширования, мониторинга, логирования и т.д. 

Следите за новостями и подписывайтесь на наш Telegram-канал CROC Cloud Live.

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

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