«Безсерверный», как и многие вещи в нашем пространстве, становится перегруженным термином ... но обычно он означает «функционально, наша архитектура не зависит от предоставления или текущего обслуживания сервера»
Первое, что приходит на ум, - это одностраничное приложение javascript, которое использует локальное хранилище и хранится на чем-то вроде Amazon S # или Github Pages (или на любом статическом сайте - это всего лишь распространенные примеры). Представьте себе что-то наподобие приложения в стиле «todo» или «все готово», которое полностью работает в вашем браузере. Ваш браузер запускает службу, такую как S3, для загрузки кода, и все элементы, которые вы храните, хранятся в локальном хранилище вашего браузера. Для этого нет сервера, который вы поддерживаете.
Второй экземпляр, немного более сложный (а также тот, который популяризировал термин «безсерверный»), использует сервис типа AWS Lambda. Позвольте мне объяснить это, представив решаемую проблему:
Много раз за свою карьеру я решал бизнес-проблему для клиента с помощью небольшого количества кода ruby, который выполнял периодическое извлечение, преобразование и загрузку (обычно написанную как задача rake). После этого я обычно автоматизирую это с помощью cron. Тогда возникает проблема: «Где мне разместить эту вещь, которая запускается раз в час?» Для некоторых клиентов мы создали бы сервер в их существующей инфраструктуре. Для других мы бы создали экземпляр EC2, даже если он простаивал в 99% случаев. В любом из этих случаев существует сервер, который требует инициализации, исправления, мониторинга, обновления и т. Д.
С помощью Amazon Lambda я могу взять эту задачу с граблями и запустить ее в своем сервисе как чистую «функцию». Я даже могу запланировать это. Этот клиент больше не будет нуждаться в части инфраструктуры для такой простой разовой работы.
В случае «без сервера» сервер все еще остается, как в «облаке» - компьютер. Помимо этого, существует уровень абстракции, который берет на себя некоторые экологические обязанности за вас.