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

— Облака — это по определению распределенная среда. Одна из ее основных характеристик — способность справляться с резким увеличением нагрузки и противостоять отдельным сбоям без потери работоспособности сервиса в целом.

Для повышения производительности облаков широко используются виртуализация и распараллеливание вычислительных потоков. Как известно, в среднем по рынку уровень утилизации серверов в корпоративных ЦОД 5–10%, а в облачных этот показатель, например, у Google и Amazon достигает 50%. То есть можно не только снизить затраты на электроэнергию и охлаждение оборудования, но и выполнить больше вычислений на меньшем количестве «железа». Это что касается виртуализации серверов.

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

— О чем должна болеть голова в этих условиях у программистов?

— Облачный программист ментально отличается от классического своим подходом к реагированию на сбои оборудования и ошибки ПО. Типичный софт, рассчитанный на один сервер или десктоп, ведет себя предсказуемо, например появляется системное сообщение в виде окошка, в котором написан тот или иной текст («Ошибка записи на диск» и пр.). Пользователь может, скажем, позвонить в службу техподдержки.

В распределенной системе пользователь со сбоями в облаке уже ничего поделать не сможет. Сервис либо доступен, либо нет; корпоративный он или общедоступный — это все равно. Поэтому программист должен понимать, что клиентам того же Facebook и Ebay нет никакого дела до того, что по статистике из ста тысяч серверов в каждую минуту примерно пять сломаны. Как нет дела и до того, что где-то на стройке экскаватор повредил кабель связи.

Облачный программист должен принять парадигму: ошибки — это нормально. Написанная им программа в случае отказа одного сервера должна «идти» на другой, если и он недоступен — искать следующий и т.д. То же самое и со служебными сервисами: недоступен один — искать другой. Самое важное для программистов — научиться работать с отказами. Сталкиваться с ними приходится в любом случае.

— А в чем сложность работы с многопоточными вычислениями?

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

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

— Но параллельная картина мира — не единственное, что ломает мозг облачного программиста?

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

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

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

— Динамическая инфраструктура позволяет же и сэкономить, не правда ли?

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

— Получается, что, например, банку, решившему развивать свое частное облако, придется столкнуться со сложностями?

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

— Подводя итоги, какой совет вы дали бы IT-службам?

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

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

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