Phenquestions
Физические компьютеры
Мы прошли долгий путь от огромных серверов эпохи доткомов. В те времена серверная инфраструктура была в основном локальной. Компания запускала свои решения на физическом сервере. Люди использовали целые отдельные серверы для разных целей (резервные копии, почтовый сервер, веб-сервер и т. Д.). Когда определенный сервер не справлялся с растущими потребностями компании, его заменяли более новым, более быстрым сервером. Вы увеличили масштаб за счет улучшения оборудования. Вы масштабировали по вертикали.
Гипервизоры
Затем пришла эра гипервизоров. Он набрал обороты с появлением VMWare, и люди поняли, что они могут получить одну стойку, чтобы управлять ими всеми. Одна стойка для запуска всех различных сценариев использования и выделения каждому из них отдельной виртуальной машины. Это также привело к появлению облачных вычислений, и компании перестали напрямую инвестировать в серверное оборудование и вместо этого решили «арендовать» виртуальные серверы.
Огромные и дорогие дата-центры управлялись облачными провайдерами по всему миру. Компании воспользовались этим, предоставив свои услуги по всему миру, используя максимально широкий спектр центров обработки данных. Это было сделано в основном для уменьшения задержек, улучшения качества обслуживания клиентов и нацеливания на более крупный рынок.
Это также заставило авторов программного обеспечения задуматься о распределенных системах. Они написали программное обеспечение для работы не на одном гигантском компьютере, а на многих посредственных компьютерах последовательным и надежным способом. Вы масштабировали по горизонтали.
Вы все еще можете масштабировать по вертикали. Фактически, благодаря виртуализации стало проще выделять больше ресурсов. Вы выключили виртуальную машину, настроили ее ресурсы и немного доплатили своему облачному провайдеру. Кусок пирога.
Основные физические серверы не исчезли. Облачные провайдеры теперь несут ответственность за управление сложностями сетевых интерфейсов, совместимостью ОС и другими ужасающими патологиями.
Контейнеры
Затем пришли контейнеры. Контейнеры были этой удивительной легкой абстракцией. Виртуальная среда с операционной системой, которая позволяла упаковывать и развертывать программное обеспечение как единое целое. Как и виртуальные машины, каждый контейнер не знал о других контейнерах, но они использовали одно и то же ядро операционной системы.
Это позволило людям развертывать программное обеспечение на серверах (физических или виртуальных, неважно) на еще более высоком уровне абстракции. Вам было наплевать на производственную операционную систему. Пока он поддерживает вашу технологию контейнеризации, он будет запускать ваше программное обеспечение. Кроме того, контейнеры легче разворачивать, что сделало сервисы более масштабируемыми, чем когда-либо.
Это еще больше повысило гибкость распределенных систем. С такими технологиями, как Kubernetes, у вас могут быть легионы контейнеров, запускающих сложный набор служб. Распределенные системы предлагают множество преимуществ: высокая доступность, надежность и способность восстанавливаться после сбоя узла.
В то же время, поскольку они настолько сложны, их сложнее проектировать, развертывать, поддерживать, отслеживать и отлаживать. Это противоречит исходной тенденции абстрагироваться от сложности вашего программного обеспечения и делегировать эту ответственность вашему облачному провайдеру. Здесь на помощь приходит бессерверная архитектура.
Бессерверная версия или функция как услуга (FaaS)
Идея бессерверной архитектуры получила распространение в основном благодаря AWS Lambda, и здесь я буду использовать ее в качестве модели, чтобы поговорить о бессерверной системе. Принципы, на которых основан FaaS:
- Вы платите за то, что используете
- Вам не нужно заботиться о масштабировании
- Вы сосредотачиваетесь на своем коде, оставляя управление инфраструктурой AWS
Когда никто не пользуется вашими услугами, они неактивны. Этого не было в традиционных решениях для хостинга, где вы платите за VPS, который всегда включен и работает, даже если он простаивает, не делая ничего более полезного, чем прослушивание нового запроса.
В бессерверной архитектуре ваша служба не работает, если кто-то действительно не хочет ее использовать. Когда поступает запрос, на лету создается служба для его обработки.
Как это работает?
Ваша функция (например, программа Python, Go или Java) находится в виде файла на AWS Lambda. С помощью этой функции вы связываете определенные триггерные события, такие как шлюз API или новый объект, поступающий в вашу корзину S3. И определенные ресурсы, такие как база данных, другое хранилище объектов или экземпляр EC2.
В ответ на любое из связанных триггерных событий AWS Lambda создает контейнер с вашей функцией внутри него. Функция выполняется и выдает ответ. Например, если новое изображение поступает в вашу корзину S3, тогда AWS Lambda может иметь внутри себя код машинного обучения, который будет анализировать это изображение и записывать его выходные данные в DynamoDB (один из сервисов хранилища данных AWS).
Вам нужно платить не за весь сервер, а только за объем памяти, который вы выделили для своей функции, количество получаемых вами запросов и продолжительность работы вашей функции.
Более того, вам не нужно беспокоиться о масштабировании контейнеров в ответ на большую входящую рабочую нагрузку. Если одновременно происходит много триггерных событий, AWS позаботится о развертывании новых контейнеров и планировании рабочих нагрузок между ними, а также обо всех других сложностях.
Не полное решение
Когда появились виртуальные машины, физические серверы не прекратили свое существование. Когда прибыли контейнеры, мы по-прежнему использовали виртуальные машины. FaaS - это абстракция более высокого уровня, и она действительно хорошо сочетается с современным дизайном RESTful API, службами без сохранения состояния и облегченными языками, такими как Node.js или Python.
Тем не менее, он по-прежнему работает на физическом сервере (например, под управлением AWS), он по-прежнему прослушивает входящие запросы (вы просто не платите за это напрямую), и вам все равно нужно хранить данные в постоянном режиме, поэтому он имеет интеграции для S3, EC2 и других сервисов. Тем не менее, это полезная абстракция.
