Облачные сервисы сегодня и завтра: коллекция полезных хабрастатей

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

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

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

Во-вторых, законодательное регулирование хранения персональных данных. Многие знают про 152‑ФЗ. В своё время из-за этого закона многие сервисы мигрировали на отечественную инфраструктуру. Хранить данные нужно в России, а если базы всё равно у российского провайдера, то и остальную инфраструктуру логично перевести туда же. Зарубежных компаний это тоже касается. Если они хранят данные клиентов из России, хочешь не хочешь — обратишься к российскому провайдеру.

Главным изменением стало утверждение ФСТЭК России «Методики оценки угроз безопасности информации», которая облегчит жизнь и клиентов, и провайдеров IT-инфраструктуры. Предшествующий документ долго не обновлялся и не учитывал современные технологии и подходы: облака, платформенные сервисы, разделение ответственности между провайдером и клиентом. Новая методика внесла ясность: введены сущности центра обработки данных и облачной инфраструктуры, описаны зоны ответственности при использовании различных IaaS-, PaaS-, SaaS-услуг. Изменения коснулись и оценки угроз — угрозы для системы клиента определяются с учётом угроз для инфраструктуры провайдера.

Сейчас готовится приказ ФСТЭК России, который вносит изменения в порядок работ по аттестации. Документ учитывает подходы новой методики для проведения оценки эффективности в форме аттестации.

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

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

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

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

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

Нет проектов, где не обойтись без Kubernetes. Но есть проекты, где этот инструмент в разы облегчит разработку. При условии, что у вас есть необходимые специалисты либо, например, managed-решение для Kubernetes, где часть работы по управлению инфраструктурой берёт на себя облачный провайдер.

Концепция Serverless актуальна для больших проектов со сложной инфраструктурой. Допустим, у вас ряд физических серверов, пул виртуальных машин, облачное хранилище и базы данных. Вам понадобилось добавить новый функционал или дополнительную связку элементов в инфраструктуру. И тут перед вами встаёт выбор: добавить ещё одну виртуалку под задачу или же использовать инструмент, который буквально заточен под неё. Таким инструментом как раз являются бессерверные вычисления. Это идеальная отвёртка, единственная задача которой — закрутить нужные гайки вашей инфраструктуры. Причём стоить такая отвёртка будет в разы меньше, чем тот же виртуальный сервер.

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

В полную силу развернутся PaaS-решения. Со временем они эволюционируют в некие serverless — абстрактные сервисы для вычислений и хранения данных: вы работаете только с кодом и данными (структурированными и нет). А привычные всем серверы, сети, диски станут чем-то вроде транзисторов в процессорах: да, они существуют, но мы их не видим и не думаем о том, как они работают.