Независимо от того, выполняете ли вы рабочие нагрузки в публичном облаке или нет, соблазн разработки в современном нативно-облачном духе неоспоримо силен. В конце концов, преимущества запуска контейнерных микросервисов в бессерверном стиле хорошо известны и многочисленны: улучшенная переносимость, более высокая масштабируемость, более быстрое развертывание, лучшая гибкость и превосходная сопровождаемость. Однако пара новых отчетов предлагает добавить еще один атрибут перехода на облачные технологии — более высокие затраты, сообщает портал Datanami.
Когда речь заходит о причинах перехода в публичное облако, «экономия денег» уже давно заменена на «повышение гибкости». Ведущие облачные провайдеры, как и поставщики систем, которых они вытесняют, придумали, как максимизировать расходы своих клиентов на инфраструктуру с небольшой (на самом деле, с большой) помощью гравитации данных.
По прогнозам Gartner и IDC,
90-95% приложений станут нативно-облачными в течение нескольких лет.
Согласно паре новых отчетов, независимо от того, где выполняются рабочие нагрузки, обещания экономии от внедрения нативных облачных технологий и методов, похоже, не оправдаются, по крайней мере, в краткосрочной перспективе.
В рамках второго ежегодного исследования «State of Kubernetes» компания Pepperdata опросила 800 лиц, принимающих решения по облачным вычислениям, и ИТ-специалистов о состоянии их контейнерных сред. Было установлено, что пользователи Kubernetes используют в среднем от 6 до 10 кластеров каждый и что наиболее популярными приложениями для их кластеров Kubernetes являются рабочие нагрузки по вводу, очистке и аналитике данных (их использует 61% респондентов), за которыми следуют базы данных (59%), веб-сервисы (58%), а также рабочие нагрузки искусственного интеллекта и машинного обучения (54%).
В отчете говорится, что 57% респондентов назвали «значительные или непредвиденные расходы на вычисления, хранение данных, сетевую инфраструктуру или облачную IaaS» своей самой насущной проблемой Kubernetes. Далее следуют крутая кривая обучения сотрудников для освоения Kubernetes в плане разработки, эксплуатации и безопасности (56%), ограниченная поддержка приложений с сохранением состояния (52%) и отсутствие прозрачности расходов на Kubernetes, что приводит к перерасходу средств (50%).
Компании пытаются сократить расходы на облако, используя методы FinOps. Однако на данный момент эти начинания не являются зрелыми: 43% респондентов заявили, что они находятся на стадии «пешего шага» («walk») на своем FinOps-пути (по определению и оценке FinOps Foundation). По данным исследования, 32% респондентов находятся на стадии «ползания» («crawl»), и только 17% — на стадии «бега» («run»).
«Опрос подтверждает, что Kubernetes стала предпочтительным выбором для развертывания рабочих нагрузок для гибких предприятий, — отмечает генеральный директор Pepperdata Аш Мунши. — Однако скорость и простота развертывания могут привести к неожиданному превышению расходов на инфраструктуру. Респонденты все чаще обращаются к FinOps и инструментам оптимизации облачных затрат, чтобы компенсировать облачные затраты и оптимизировать свои кластеры Kubernetes».
Высокая стоимость разработки нативных облачных решений была рассмотрена в другом новом отчете, подготовленном компанией OutSystems, которая предоставляет готовую нативную облачную платформу, подключенную к среде разработки low-code.
В отчете под названием «Cloud-Native Development Report: The High Cost of Ownership» прослеживается путь гипотетической компании по переходу к нативным облачным вычислениям. Некая страховая компания имеет доход в 3 млрд. долл. и ИТ-бюджет в 190 млн. долл. Она также ставит перед собой цель использовать технологии и методы нативных облачных вычислений для создания и запуска веб-портала и мобильного приложения, которые соединяют клиентов с внутренними системами ERP и CRM (которые не модернизируются).
Хотя многие технологии, лежащие в основе подхода cloud-native, такие как Kubernetes, являются бесплатными и с открытым исходным кодом, они требуют значительных затрат, в основном на инфраструктуру и персонал. В частности, затраты на поиск ИТ-специалистов с опытом использования и развертывания нативных облачных технологий оказались одним из самых больших препятствий, выявленных в отчете.
«Kubernetes... чрезвычайно сложна, а опытные специалисты — дефицитный ресурс, — говорится в отчете. — Организации, которые внедряют эту систему, обнаруживают, что им приходится выделять значительные ресурсы на ее настройку и правильную работу».
Но, согласно OutSystems, K8s — это только начало проблем. Потенциальные внедренцы нативных облачных решений должны также переобучить своих существующих разработчиков архитектуре микросервисов, учесть потребности в области сетевых решений и безопасности, а также перестроить все процессы DevOps. «Все эти задачи в совокупности экспоненциально увеличивают сложность, — говорится в отчете. — И неизбежным побочным продуктом всех этих накладывающихся друг на друга слоев сложности является стоимость».
В примере сор страховой компанией стоимость создания портала и веб-приложений составляет 5,6 млн. долл., и на это требуется 18 месяцев. Инфраструктура стоит 2,7 млн. долл., а затраты на персонал по разработке приложений составляют 2,9 млн. долл. Отчет не говорит об этом прямо, но у читателя создается впечатление, что затраты и сроки разработки были бы значительно меньше при использовании традиционных технологий и технических средств.
Несмотря на такие преимущества перехода на cloud-native, как высокая доступность, гибкость, масштабируемость, эластичность и простота географического распределения, затраты и сложность не являются тривиальными, и именно по этой причине «сегодня лишь немногие компании полностью перешли на нативное облако», — пишут исследователи.
«Нативные облачные приложения имеют явное преимущество перед унаследованным ПО. Никто не спорит, что они быстрее реагируют на изменения рынка, обеспечивают лучший пользовательский опыт и превосходную масштабируемость и отказоустойчивость, — отмечает технический директор OutSystems Патрик Жан. — Но этот переход также представляет собой перестройку традиционного процесса разработки ПО, к которой большинство компаний не готовы».
