Что ждет бессерверные решения в будущем?

Serverless набирает все большую популярность. Что мы можем ожидать от него в будущем?

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

Это много теории. Но это захватывающе.

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

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

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

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

Давайте поговорим о некоторых разрушителях, которые вероятны в нашем будущем.

Глубокая инфраструктурная аналитика

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

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

Такие поставщики, как DataDog, Lumigo и Thundra, пытаются решить эту проблему — и довольно успешно. Но это должно быть лучше.

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

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

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

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

Инфраструктура из кода

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

Инструментарий продолжает улучшаться, чтобы сделать инфраструктуру как код проще. Такие инструменты, как AWS SAM и CDK, абстрагируются от некоторых сложностей CloudFormation, чтобы упростить соединение точек с вашими ресурсами. Такие инструменты, как Terraform и Serverless Framework, полностью абстрагируются от поставщика, позволяя вам развертывать свои рабочие нагрузки с одним и тем же IaC независимо от того, какого облачного провайдера вы используете.

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

Мы уже находимся в процессе смены парадигмы. Тот, который выводит нас на беспрецедентный уровень абстракции.

Ребята из Serverless Cloud абстрагируют инфраструктуру как код. Их задача состоит в том, чтобы сделать вывод о том, какая инфраструктура вам нужна, из бизнес-логики, которую вы пишете. Инфраструктура из кода — это фраза, придуманная Дугом Москропом и ставшая популярной благодаря Джереми Дейли, описывающая этот процесс.

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

Инфраструктура из кода — следующий серьезный прорыв в бессерверной среде.

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

Абстрагируясь от инфраструктурных решений, serverless переходит от Дикого Запада к стандартной практике разработки, усиленной де-факто шаблонами и стандартами, которые внедряются для нас автоматически.

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

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

Лучшее из обоих миров

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

Это наш потрясающий момент.

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

Приложение доводится до производства и работает около месяца. В течение этого месяца инфраструктурная аналитика определила шаблоны вашего трафика и успешно сопоставила все распределенные транзакции по вашим микросервисам.

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

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

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

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

Что не изменится

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

Но ждать. Зачем спрашивать?

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

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

Ситуация улучшается, но мы, возможно, никогда не дойдем до 100% готовности производства.

API-моделирование идет по тому же пути. Если вы разрабатываете REST API, вы создаете свои конечные точки для детализации объектов данных. Если нам нужно моделировать объекты данных вручную, то имеет смысл перенести это и на моделирование API.

Разработка API для разработчиков требует участия человека. Иногда то, что делает DevEx лучше, идет вразрез с основами. Создание конечной точки, которая нарушает рекомендации REST, но экономит разработчикам 5 шагов, — это компромисс, на который готовы пойти многие.

Заключение

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

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

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

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

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

Удачного кодирования!