Краткая история бессерверного режима (или как я научился перестать волноваться и полюбить облако)

1656644659 kratkaya istoriya besservernogo rezhima ili kak ya nauchilsya perestat volnovatsya

от Himanshu Pant

iv6nztZ-j6Pt09FLTskrszecQlJ3iXFYhQcv
Ой, я бы хотел, чтобы у нас была одна из тех машин конца света.

Однажды…

Начало

В старые добрые времена 1950-х годов, когда Элвис лидировал в чартах с такими хитами, как Jailhouse Rock, появилась компьютерная парадигма под названием мэйнфреймы под названием Big Iron (не связанная с Арнольдом Шварценеггером).

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

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

hIlXNmWrm2Y3-4jzYPsPsebNWS31AYHi3lz6
Автор: Арнольд Рейнхольд — Я сделал этот снимок артефакта, который есть у меня. Карточка была создана в конце 1960-х или в начале 1970-х и не имеет никакого сообщения об авторских правах., CC BY-SA 2.5

Оператор планирует и выполняет ранее представленные перфокарты.

ejAHUmCkHeo8jqEDJiA0VwlOlEXPq6Yo6bhS
© Корпорация MITRE

Смешной факт: на изображении выше показано ОГРОМНЫЕ 5 Мб данных на 62 500 перфокартах. Итак, представьте себе количество карточек, необходимых для захвата базы кода Win 10 или MacOS, если бы мы все еще использовали эту технологию!

После того, как исходные данные были сгенерированы/напечатаны, оператор физически собирал их и доставлял в кабинет или физический почтовый ящик господина Эпплсида. Онлайн-доступ был прежде всего зарезервирован для ресурсов, которым он был нужен, например, персонал на стойке бронирования авиакомпании.

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

Излишне говорить, что вышеуказанный процесс был не только медленным, но и очень дорогим. Настолько, что использование системы было измерено и взыскано за секунды на счет клиента.

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

aaamJ0aD5n5IBFkTU-j1S8oPh1mQz0efkHEL

Эра ПК

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

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

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

8zQD8lWjMRyuQhLZlnmqhQUe2dr0wPAVG8Dk

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

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

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

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

Облачная эра

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

Прежде чем углубиться в это, давайте обновим определение «облака», предоставленное Национальным институтом стандартов и технологий (NIST):

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

а) Самообслуживание по требованию

b) Широкий доступ к сети

c) Объединение ресурсов

г) Быстрая эластичность

e) Измерение услуги

Основные факторы этой парадигмы:

a) Быстрые глобальные сети

б) мощные товарные серверы

в) высокопроизводительная визуализация для товарного оборудования

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

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

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

Введите бессерверную архитектуру

2015 год (или некоторые говорят, 2012 год) был временем, когда эта вычислительная парадигма возникла. Было предложено несколько толкований этого термина (бессерверность) и его последствий.

Одна школа мнения приписывает это Backend в качестве услуги (BaaS). Например, услуги аутентификации, предлагаемые сторонними поставщиками, такими как Google или Facebook.

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

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

Краткая эволюция парадигмы облачных вычислений

xQz6jcgBCauebEeZx50IawzIFXFowoycDjey

По своей сути FaaS – это простая концепция, которая означает, что:

  • Команда разработчиков не должна беспокоиться о таких аспектах, как внутренний сервер, его обслуживание, приобретение или масштабирование (ну, в известной степени). Команда должна беспокоиться только о логике программы.
  • Обработка производится на вычислительных контейнерах без состояния. Другими словами, после одной логической единицы обработки система не сохраняет атрибуты обработки.
  • Вместо того чтобы иметь сервер с долго запущенными процессами, скажем cron, здесь обработка инициируется только после того, как квалификационный “событие» происходит и прекращается, когда обработка завершена или установленное время истекло (в зависимости от того, что произойдет раньше).

Это не значит, что по всей схеме вещей нет серверов. Все это означает, что серверы и их обслуживание теперь скрыты разработчиком.

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

Чем не является Serverless

«Что в имени? То, что мы называем розой любым другим именем, пахло бы так же сладко». — Джульетта, Ромео и Джульетта

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

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

Поэтому я пытаюсь объяснить, с чем обычно (или можно) путать бессерверный режим. Я тоже поделюсь своими двумя центами.

Это НЕ контейнер

«Образ контейнера – это легкий отдельный выполняемый пакет программного обеспечения, содержащий все необходимое для его запуска: код, время выполнения, системные инструменты, системные библиотеки, настройки. Контейнерное программное обеспечение, доступное как для приложений на основе Linux, так и для Windows, всегда будет работать одинаково, независимо от среды. Контейнеры изолируют программное обеспечение от его окружения, например, отличия между средами разработки и постановки, и помогают уменьшить конфликты между командами, использующими разное программное обеспечение в одной инфраструктуре». — Docker.com

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

Например, код может быть разработан в Java 8, но производство может быть на Java 9 – поэтому код, который нормально работал в разработчике, может начать выдавать странные ошибки в производстве.

Грубо говоря, контейнер – это бывшая ВМ (виртуальная машина) на стероидах. В нем нет никакой излишней слабости отдельных версий ОС. В отличие от виртуальных машин, где раньше существовала отдельная копия гостевой ОС (что усложняло ресурс виртуальной машины), контейнеры совместно используют базовое ядро ​​ОС. Это позволяет запускать несколько контейнеров на определенной машине в сравнении с виртуальными машинами.

Виртуальная машина против контейнера

xSxnL7Sna71oI-Z46fO8Tw8YVAhGKD8VH-2g
xdyMj0QBmyhp25QCxbiWNCiv2mEDij6cy-F5
Виртуальная машина против контейнера

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

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

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

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

Но учитывая темпы, с которыми все меняется, разногласия могут в значительной степени исчезнуть в течение короткого периода времени.

Это НЕ PaaS

«Платформа как услуга» (PaaS) – это модель облачных вычислений, в которой сторонний поставщик предоставляет аппаратные и программные инструменты – как правило, необходимые для разработки приложений – пользователям через Интернет. Поставщик PaaS размещает аппаратное и программное обеспечение в своей инфраструктуре. В результате, PaaS освобождает пользователей от необходимости устанавливать собственное аппаратное и программное обеспечение для разработки или запуска новой программы». — Techtarget

Как и контейнеры, PaaS также отличается в основном вектором зума. Несмотря на то, что поставщики PaaS не утверждают, что их предложение таково, оно все равно требует определенных усилий по обслуживанию администратора, в отличие от бессерверной системы.

С PaaS всегда есть минимальный рабочий след в системе, которая будет работать и нести расходы. Однако без сервера его можно свести к абсолютному нулю.

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

Добавить комментарий

Ваш адрес email не будет опубликован.