Об облаках человеческим языком. Часть III

Долгожданное окончание заметки про облака.

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

Экскурс в историю программирования

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

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

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

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

Эволюция облаков

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

Потом появились первые публичные облачные провайдеры. Первое время их услуги были довольно простыми — они предлагали возможность взять в аренду виртуальные машины и хранилище на дисках. Это называлось Infrastructure as a Service (IaaS) — Инфраструктура как услуга. Название такое сложилось потому, что хранилище и виртуальные машины — это самые базовые и самые простые сервисы, на которых можно строить приложения.

Инфраструктура как услуга

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

Сервисы IaaS позволили очень быстро и просто перенести в облака существующие приложения, так как позволяли “в облаках” создать конфигурацию, симметричную тому, что использовали заказчики на своих собственных серверах. Родился даже термин для такого переноса приложений в облака “как есть”: lift and shift (то есть “поднять и перенести”).

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

Из-за этого, а также из-за того, что при переносе приложения не адаптировались под возможности облака (переносились “как есть”) польза и преимущества такого переноса были ограниченными. Многие тогда даже разочаровались в облаках, хоть и совершенно неоправданно.

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

Дальше — больше. Поскольку практически в любом приложении присутствует база данных, поставщики публичных облаков взяли на себя задачу развёртывания и управления серверами баз данных. А разработчикам оставалось лишь использовать готовую базу данных, не заботясь обо всём этом. Это уже был первый шаг к следующему уровню облачных технологий — Platform as a Service (PaaS), то есть “платформа как услуга”.

Платформа как услуга

Приложения состоят из большого количества готовых “кирпичиков”. Неслучайно по-английски программист и строитель — называются одним и тем же словом (developer). Да и вообще в программировании очень много терминов из строительства. Есть даже такая старая шутка:

— Если бы строители строили здания так же, как программисты пишут программы, то первый залетевший дятел разрушил бы половину цивилизации.

“Строительных блоков” в приложениях довольно много: это и базы данных, и системы доставки сообщений (очереди), и системы распределения нагрузки, управления пользователями и правами доступа, системы аналитики, построения отчётов, системы управления серверами, мобильными устройствами — список можно продолжать бесконечно.

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

Это позволило разработчикам сильно уменьшить затраты на разработку и администрирование своих приложений. Но не “бесплатно”, конечно. Во-первых, такие сервисы стоят денег (хотя зачастую это и выгоднее, чем делать такие “строительные блоки” самому), а во-вторых (и это чаще важнее) — иногда разработчикам не хватает гибкости в возможностях настройки и использования этих готовых компонентов, и они предпочитают сделать свои собственные.

Но, как программист в прошлом, скажу вам по секрету, что основная проблема часто другая: разработчики не очень любят разбираться в том, что сделали другие разработчики. Очень часто главным честным аргументом против использования какого-то готового компонента является “его написали не мы”. Поэтому очень часто программисты, вместо того, чтобы использовать готовый велосипед, предпочитают изобрести свой собственный, пусть и с квадратными колёсами.

Тем не менее преимущество у PaaS над IaaS достаточно много, чтобы постепенно все решения переходили на него.

Микросервисы

Ещё одним очень популярным направлением в архитектуре облачных систем являются микросервисы и “безсерверность” (если так можно перевести слово “serverless”).

Я уже писал, что все приложения внутри состоят из большого количества маленьких кубиков. Точнее — все хорошие приложения можно внутри представить в виде набора независимых кубиков, или компонентов. Это очень сильно упрощает разработку приложений (так как позволяет нескольким разработчикам параллельно писать разные куски приложения). И ещё больше это позволяет упростить и улучшить работу приложения.

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

Контейнер — это приложение и все необходимые ему вспомогательные компоненты и настройки. Контейнеры гораздо “легче” виртуальных машин (и на самом деле работают внутри виртуальных машин) и поэтому позволяют разместить на одном сервере много-много маленьких контейнеров (в несколько раз больше, чем “поместилось” бы виртуальных машин, что позволяет получить с одного сервера гораздо больше пользы. Помимо этого, контейнеры обладают ещё одной замечательной способностью — они одинаково работают во всех облаках (будь то Amazon, Microsoft или Goggle), и ещё они одинаково работают и в публичных облаках, и на частных серверах.

Сейчас практически все популярные компоненты приложений, а то и целые приложения распространяются в виде контейнеров, которые очень просто скачать и установить у себя на сервере, или в облаке. Например, когда Телеграм боролся с Роскомнадзором, они написали прокси-сервер, позволяющий обходить блокировку Телеграма. Любой мог скачать контейнер с этим прокси-сервером и установить у себя. Благодаря этому, таких прокси-серверов стало очень много и борьба с ними стала похожа на борьбу с ветряными мельницами (что, впрочем, понятно было с самого начала).

Контейнеры позволили повторить успех магазинов приложений на смартфонах на рынке корпоративных систем. Есть магазины контейнеров (marketplaces), в которых лежат на продажу готовые компоненты, которые можно очень просто взять, скачать, установить в своём облаке (частном, публичном или гибридном) и начать использовать, особенно не думая о том, как они устроены внутри.

Здесь будет уместно сделать маленькое отступление и пояснить, что такое публичные, частные и гибридные облака. Всё, о чём мы говорили выше — облачные технологии. Если эти облачные технологии предоставляются глобальными компаниями, такими, как Amazon, Microsoft или Google — это публичные облака. Если эти технологии используются на собственных серверах компании — это частные облака. А если используется и то, и то вместе — это гибридные облака.

Но вернёмся к контейнерам. Для управления всеми этими контейнерами используются так называемые оркестраторы, которые, как дирижёры в оркестре, помогают всем маленьким микросервисам внутри контейнеров играть в унисон. Самый популярный сейчас формат контейнеров — это Docker, а самый популярный сервис для управления контейнерами — это Kubernetes. Зная эти слова, ваша мама теперь сможет поразить знакомых программистов в компании своими познаниями.

Serverless

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

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

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

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

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

Это и есть “безсерверность”. Сервер — это от слова “to serve”, то есть обслуживать. Это же слово используется в английском языке и для официанта, который стоит, внимательно смотрит и ждёт, когда его позовёт гость, чтобы исполнить его просьбу. Во многих ресторанах сейчас на столах ставят кнопочку вызова официанта. Удобнее и посетителям (не нужно махать руками, привлекая к себе внимание), и официантам (не нужно стоять, наблюдать и ждать). Это и есть “безсерверность”.

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

Выводы

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

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

— Бог создал людей, а кольт сделал их равными.

Облака сделало если не совсем равными, то гораздо “равнее” компании разных размеров. Благодаря этому очень маленькие компании очень быстро становятся очень успешными и создают конкуренцию очень крупным игрокам, что ещё вчера было невозможно.

Правда, это вывело конкуренцию между компаниями на новый уровень. Если раньше у большой компании были вычислительные мощности (серверы), которые не могла себе позволить маленькая компания, то теперь, когда любая компания может получить любую вычислительную мощность, конкуренция перешла на уровень данных. Большие компании владеют данными, которых нет у маленьких компаний. Facebook, Google, Яндекс знают о нас всё. И могут эти знания использовать. Как сейчас принято говорить:

— Данные — это новая нефть.

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

Благодаря тому, что в облаках вы платите только за то, что используете, этом маленькому стартапу не нужны огромные инвестиции наперёд, чтобы построить инфраструктуру, способную выдержать такую нагрузку. И наконец облака по определению более эффективны. Так как там все используют только то, что им нужно, а не строят мощности “про запас”.

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

Значит ли это, что исчезли генераторы? Конечно нет! Я не сомневаюсь, что сейчас генераторов продаётся в тысячи раз больше, чем 100 лет назад. Но, тем не менее, большая часть электричества производится на больших электростанциях. Потому, что так выгоднее.

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

Дописываю заметку из самолёта, наблюдая за облаками за окном. Когда-нибудь, подозреваю, термин “облака” будет в первую очередь относиться к компьютерам и уже во вторую — к водяному пару, сконденсировавшемуся в атмосфере. Как это уже произошло со словом “мышка”. Наверное, это не очень романтично. Но точно очень интересно. И своей затянувшейся заметкой я, надеюсь, убедил вас (и вашу маму) в том, что это совсем несложно. Если цикл заметок понравился — пишите, мне много ещё чего есть рассказать про облака.

Оригинал заметки.