Мультиоблако: новый подход к построению инфраструктуры ИТ
Неизвестно, насколько или когда инфраструктура российских компаний станет мультиоблачной. Однако технологии и подходы, лежащие в основе этой концепции, значительно изменят ИТ-ландшафт уже в ближайшие пару лет.
Как и многие технологические тренды, термин "мультиоблако" пришел к нам с Запада. Так называют подход к созданию интегрированной инфраструктуры на базе нескольких облачных провайдеров. Мультиоблако обеспечивает высочайшие уровни доступности и масштабируемости, возможность разместить системы как можно ближе к пользователю, а также устранить технологическую зависимость от одного провайдера. Один из нашумевших примеров – Netflix, использующий одновременно AWS и GCP.
В отечественных реалиях мы чаще сталкиваемся с гибридным облаком как одним из подходов к созданию мультиоблака. Крупнейшие компании в России, которым важны высокие показатели отказоустойчивости и ручной доступ к "железу", сейчас предпочитают строить собственную облачную инфраструктуру. И если частное облако – это переход от "крафтовых" ИТ к конвейеру сервисов для бизнеса, то мультиоблако – это роботизированная фабрика, предоставляющая автоматический доступ к бизнес-приложениям.
Создание мультиоблака – сложный технический процесс. В мире еще не сложилась стандартная практика создания подобных ИТ-решений. Чтобы заставить гиперскейлеров работать вместе и использовать их как единое целое, нужно решить ряд задач. Среди них ключевые – адаптация приложений, обеспечение сетевой связности, доступности данных, повторяемости и единого управления.
В идеальной ситуации на новую мультиоблачную инфраструктуру переносятся cloud native-приложения, соответствующие 12 критериям, сформулированным командой Heroku, а лучше – 15 критериям, описанным Кевином Хоффманом. При разработке таких приложений необходимо фокусироваться на возможностях облачных вычислений и особенностях виртуальной инфраструктуры.
Приложения, построенные в соответствии с устаревшими подходами, переносить в мультиоблако сложно и зачастую нецелесообразно. Но так как мы живем не в идеальном мире, приходится сталкиваться и с такими задачами.
Если абстрагироваться от вопросов разработки и сфокусироваться только на средах исполнения, необходимо обеспечить возможность развертывания всего приложения на основе декларативного описания конфигурации и исключить ручные операции (мы же говорим про роботизированную фабрику).
Одна из сложнейших задач – добиться сетевой связности и доступности приложений как на внутренних площадках, так и между публичными облаками. Не многие крупные компании на российском рынке могут похвастаться сетью без пересечения адресных пространств. Чаще всего они сталкиваются с проблемой динамического выделения непересекающихся диапазонов внутренних адресов для неизвестного заранее количества подсетей.
В мультиоблачной архитектуре необходимо обеспечить доступность приложения как для внутренних, так и для внешних пользователей (если мы говорим о продуктивной среде) и партнеров (если мы говорим о большом количестве сред) вне зависимости от того, где приложение будет развернуто в следующий раз. А еще нужно обеспечить защиту, хотя бы на сетевом уровне – и все в автоматическом режиме. Выбор технологии реализации программно определяемой сети передачи данных зависит от множества факторов и заслуживает отдельной статьи.