WEBVTT

00:00:00.000 --> 00:00:03.300
Тема сегодняшнего выпуска — то, о чём слышали почти всё, но почти никто не может объяснить.

00:00:03.460 --> 00:00:06.160
Серверлесос или бессерверные вычисления? Что же это такое на самом деле?

00:00:06.300 --> 00:00:08.800
Это действительно код, работающий в никуда или нечто гораздо более масштабное?

00:00:08.940 --> 00:00:12.420
Давайте сразу проясним один момент. Серверлесос не означает отсутствие серверов.

00:00:12.520 --> 00:00:16.320
Это значит, что вам не нужно о них думать, и это различие кардинально меняет подход к разработке.

00:00:16.440 --> 00:00:21.720
К концу этого выпуска вы поймёте, что такое Azure Functions, как устроена их тарификация и когда их стоит использовать.

00:00:21.900 --> 00:00:24.940
Мы разберём всё по кирпичикам, начав с самого главного мифа.

00:00:25.060 --> 00:00:27.080
Что же на самом деле означает серверлесос?

00:00:27.080 --> 00:00:28.960
Давайте сразу развеем несколько мифов.

00:00:28.960 --> 00:00:32.400
Название — бессерверный, худший маркетинговый термин, который когда-либо придумывала Microsoft.

00:00:32.640 --> 00:00:35.080
Он заставляет людей думать, что серверов вообще не существует.

00:00:35.200 --> 00:00:39.100
Это не так. Серверы есть, и их очень много. Просто вам никогда не приходится их касаться.

00:00:39.280 --> 00:00:42.900
20 лет назад, чтобы запустить код в интернете, нужно было проделать огромную работу.

00:00:43.080 --> 00:00:47.640
Вы арендовали виртуальную машину, устанавливали ОС, настраивали веб-сервер и разворачивали приложение.

00:00:47.780 --> 00:00:52.580
А потом проводили каждые выходные, устанавливая патчи безопасности и следя, чтобы всё не упало в 3 часа ночи.

00:00:52.660 --> 00:00:56.160
И вот в чём штука. Вы платили за сервер, даже если ваш код не работал.

00:00:56.160 --> 00:00:59.140
Он гудел себе в стойке, сжигая ваши деньги, пока вы спали.

00:00:59.280 --> 00:01:01.700
Сервер Лесос переворачивает эту модель с ног на голову.

00:01:01.800 --> 00:01:05.080
Вы пишете код, загружаете его, а платформа берёт на себя всё остальное.

00:01:05.320 --> 00:01:08.720
Операционную систему, обновление безопасности, масштабирование и доступность.

00:01:08.920 --> 00:01:11.460
Ваша задача — писать только ту логику, которая важна.

00:01:11.580 --> 00:01:15.340
Представьте это как разницу между работой ресторанной кухни и торговым автоматом.

00:01:15.480 --> 00:01:19.300
Ресторанной кухне нужен штат сотрудников, постоянные поставки продуктов и обслуживания.

00:01:19.500 --> 00:01:22.760
Она требует денег каждый день, даже если туда не зашёл ни один клиент.

00:01:22.760 --> 00:01:26.900
Торговый автомат стоит в углу и ничего не делает, пока кто-то не нажмёт на кнопку.

00:01:27.100 --> 00:01:29.760
Затем он оживает, выполняет свою работу и снова засыпает.

00:01:29.880 --> 00:01:32.220
Вы платите за электричество только тогда, когда он действительно работает.

00:01:32.360 --> 00:01:33.980
Это и есть суть сервер Лесос в двух словах.

00:01:34.100 --> 00:01:36.160
Azure Functions — это версия такого подхода от Microsoft.

00:01:36.380 --> 00:01:38.820
Она запускает небольшие фрагменты кода в ответ на события.

00:01:38.820 --> 00:01:40.780
Ваш код спит, пока что-то его не разбудит.

00:01:40.980 --> 00:01:43.460
Затем он отрабатывает, завершается и снова засыпает.

00:01:43.540 --> 00:01:44.940
Так как же выглядит этот код?

00:01:45.080 --> 00:01:46.380
Что такое Azure Functions?

00:01:46.580 --> 00:01:49.960
Функция — это отдельный фрагмент кода, выполняющий одну конкретную задачу.

00:01:49.960 --> 00:01:54.220
Вот и всё. Это не целое приложение со страницей входа, базой данных и 20-ю экранами.

00:01:54.360 --> 00:01:56.280
Это одна узкоспециализированная задача.

00:01:56.380 --> 00:02:01.300
Представьте это как выключатель света в доме, либо выключен, либо включён для выполнения задачи, а затем снова выключен.

00:02:01.500 --> 00:02:03.600
Традиционный веб-сервер — это полная противоположность.

00:02:03.600 --> 00:02:08.180
Всё равно, что оставлять свет включённым 24 часа в сутки, 7 дней в неделю, даже когда дома никого нет.

00:02:08.300 --> 00:02:11.320
Azure Functions поддерживают множество различных языков программирования.

00:02:11.480 --> 00:02:15.480
Вы можете использовать то, что вам удобно, JavaScript, Python, C-решётка, Java, PowerShell.

00:02:15.620 --> 00:02:17.100
Здесь нет единственно верного ответа.

00:02:17.240 --> 00:02:18.740
Выбирайте язык, который вы уже знаете.

00:02:18.740 --> 00:02:20.720
А теперь давайте устраним распространённую путаницу.

00:02:20.840 --> 00:02:23.240
Приложение-функция, Function App — это не то же самое, что сама функция.

00:02:23.420 --> 00:02:24.940
Приложение-функция — это контейнер.

00:02:25.060 --> 00:02:26.740
Представьте его как ящик для инструментов.

00:02:26.780 --> 00:02:30.060
Вы создаёте одно приложение-функцию, а внутри этого ящика размещаете множество функций.

00:02:30.220 --> 00:02:32.960
Каждая функция — это отдельный инструмент, который выполняет свою работу.

00:02:33.120 --> 00:02:35.260
У вас может быть одна функция для регистрации пользователей,

00:02:35.460 --> 00:02:38.560
другая — для обработки загруженных изображений и третья — для рассылки ночных отчётов.

00:02:38.680 --> 00:02:41.380
Все они живут в одном ящике, но работают независимо друг от друга.

00:02:41.540 --> 00:02:42.700
И ещё кое-что о функциях.

00:02:42.760 --> 00:02:44.500
Они намеренно сделаны без сохранения состояния.

00:02:48.740 --> 00:02:52.820
Это всё. При следующем запуске она начинает с чистого листа, не помня о предыдущем разе.

00:02:52.960 --> 00:02:56.200
Звучит как ограничение, но именно эта особенность делает их такими мощными.

00:02:56.340 --> 00:02:58.540
Поскольку функции не хранят память или состояние,

00:02:58.680 --> 00:03:01.600
Azure может мгновенно запустить 100 копий вашей функции при скачке трафика

00:03:01.600 --> 00:03:03.740
и также быстро отключить их, когда нагрузка падает.

00:03:03.900 --> 00:03:07.160
Именно так вы получаете масштабируемость, не платя за простаивающие серверы.

00:03:07.300 --> 00:03:11.900
Возникает вопрос. Если функция просто бездействует, пока её что-то не разбудит, то что же её будет?

00:03:12.040 --> 00:03:13.620
Вот здесь на помощь приходят триггеры.

00:03:13.780 --> 00:03:15.300
Триггеры — это условие, когда.

00:03:15.300 --> 00:03:18.300
У каждой функции должен быть ровно один триггер. Это обязательное требование.

00:03:18.480 --> 00:03:21.000
Триггер — это событие, которое пробуждает вашу функцию.

00:03:21.180 --> 00:03:23.320
Без него ваш код просто будет висеть в бездействии.

00:03:23.480 --> 00:03:25.160
Представьте триггеры как дверной звонок.

00:03:25.360 --> 00:03:27.280
Ваша функция находится внутри дома и ждёт.

00:03:27.440 --> 00:03:28.440
Она может ждать вечно.

00:03:28.660 --> 00:03:30.900
Ничего не произойдёт, пока кто-то не нажмёт на звонок.

00:03:31.020 --> 00:03:34.880
Тогда функция включается в работу, открывает дверь, делает своё дело и возвращается в режим ожидания.

00:03:35.060 --> 00:03:37.740
Есть четыре триггера, с которыми новички сталкиваются чаще всего.

00:03:37.920 --> 00:03:40.700
HTTP-триггер — самая распространённая отправная точка.

00:03:40.700 --> 00:03:44.340
Кто-то переходит по ссылке или делает вызов API, и ваша функция запускается.

00:03:44.340 --> 00:03:47.960
Так можно создавать легковесные API, не настраивая полноценный веб-сервер.

00:03:48.060 --> 00:03:51.100
И есть ещё триггер по таймеру, который запускается по расписанию.

00:03:51.280 --> 00:03:55.460
Вы задаёте крон-выражение, например, запуск каждый час или в полночь каждую ночь,

00:03:55.660 --> 00:03:57.780
и ваша функция срабатывает в это точное время.

00:03:58.000 --> 00:04:01.880
Идеально подходит для задачи обслуживания, очистки или создания ночных отчётов.

00:04:02.000 --> 00:04:05.140
Триггер биелоби-объектов срабатывает при загрузке файла в хранилище Azure.

00:04:05.340 --> 00:04:07.920
Допустим, кто-то загружает PDF-файл в определённую папку.

00:04:08.040 --> 00:04:11.380
Триггер биелоби-объектов обнаруживает эту загрузку и автоматически запускает вашу функцию.

00:04:11.380 --> 00:04:15.060
Это очень полезно для обработки изображений, преобразования документов и проверки файлов.

00:04:15.160 --> 00:04:17.960
А триггер очереди срабатывает, когда в очереди появляется сообщение.

00:04:18.100 --> 00:04:20.920
Очереди — это способ разделения различных частей вашей системы.

00:04:21.040 --> 00:04:25.360
Один сервис помещает сообщение в очередь, а ваша функция забирает и обрабатывает его, когда будет готово.

00:04:25.440 --> 00:04:28.680
Это предотвращает ситуацию, когда один медленный сервис блокирует всё остальное.

00:04:28.860 --> 00:04:29.760
Вот ключевой момент.

00:04:29.960 --> 00:04:33.400
Когда триггер срабатывает, он автоматически передаёт данные в вашу функцию.

00:04:33.580 --> 00:04:36.260
Вам не нужно опрашивать систему или проверять, произошло ли что-то.

00:04:36.380 --> 00:04:39.620
Триггер предоставляет вам всё необходимое, а ваша функция просто это обрабатывает.

00:04:39.620 --> 00:04:42.560
Функция без триггера – это просто код, который ничего не делает.

00:04:42.700 --> 00:04:44.200
Именно триггер придает ей смысл.

00:04:44.380 --> 00:04:46.800
Итак, триггер говорит вашей функции, когда нужно запускаться.

00:04:46.940 --> 00:04:48.800
Но откуда берутся данные и куда они уходят?

00:04:48.940 --> 00:04:51.000
Вот здесь на помощь приходят привязки Bendinges.

00:04:51.140 --> 00:04:53.220
Привязки – это ввод данных и вывод данных.

00:04:53.360 --> 00:04:58.520
Привязки позволяют указать функции, какие данные считывать и куда отправлять результаты, без написания лишнего кода.

00:04:58.700 --> 00:05:00.660
Звучит сложно, поэтому позвольте упростить.

00:05:00.840 --> 00:05:01.800
Существует два типа.

00:05:01.960 --> 00:05:04.120
Входные привязки доставляют данные в вашу функцию.

00:05:04.320 --> 00:05:06.340
Выходные привязки отправляют данные наружу.

00:05:06.340 --> 00:05:11.780
Без привязок вам пришлось бы писать код SDK каждый раз, когда нужно обратиться к хранилищу, базе данных или очереди.

00:05:11.920 --> 00:05:16.740
Вам пришлось бы обрабатывать строки подключения, управлять повторными попытками, сериализовать данные и десериализовать ответы.

00:05:16.820 --> 00:05:19.120
Это слишком много шаблонного кода только для чтения файла.

00:05:19.220 --> 00:05:21.140
С привязками вы просто объявляете, что вам нужно.

00:05:21.300 --> 00:05:23.600
Вы говорите, я хочу читать данные из этого биологи контейнера.

00:05:23.700 --> 00:05:25.520
Или, я хочу записать данные в эту очередь.

00:05:25.680 --> 00:05:27.300
Среда выполнения берет остальное на себя.

00:05:27.500 --> 00:05:31.200
Она открывает соединение, считывает данные и передает их в вашу функцию в качестве параметра.

00:05:31.200 --> 00:05:35.620
Когда функция завершается, она берет возвращаемое значение и записывает его туда, где вы указали.

00:05:35.820 --> 00:05:37.140
Представьте привязки как трубы.

00:05:37.320 --> 00:05:40.680
Вы подключаете свою функцию к хранилищу, базе данных или очереди.

00:05:40.860 --> 00:05:42.860
Данные автоматически текут через эти трубы.

00:05:43.080 --> 00:05:45.320
Вашей функции не нужно знать, как работают эти трубы.

00:05:45.480 --> 00:05:48.340
Она просто получает то, что проходит через них, и отправляет то, что должно выйти.

00:05:48.480 --> 00:05:49.380
Вот конкретный пример.

00:05:49.560 --> 00:05:51.700
Допустим, у вас есть входная привязка для биологи объекта.

00:05:51.800 --> 00:05:55.840
Когда ваша функция запускается, она автоматически считывает файл из хранилища биологи объектов и передает его вам в качестве параметра.

00:05:55.980 --> 00:05:57.820
Вам не нужно писать код SDK для хранилища.

00:05:57.820 --> 00:05:59.780
Вы просто получаете данные и обрабатываете их.

00:05:59.920 --> 00:06:01.760
Другой пример – выходная привязка к очереди.

00:06:01.960 --> 00:06:04.760
Ваша функция что-то обрабатывает, а в конце вы возвращаете значение.

00:06:04.940 --> 00:06:08.120
Среда выполнения берет это значение, сериализует его и помещает в очередь.

00:06:08.280 --> 00:06:09.700
Вам не нужно писать код для очереди.

00:06:09.840 --> 00:06:11.180
Вы просто возвращаете значение.

00:06:11.340 --> 00:06:12.500
Привязки не обязательны.

00:06:12.660 --> 00:06:14.380
Их может быть ноль, одна или много.

00:06:14.620 --> 00:06:17.440
Некоторым функциям нужен только триггер, вообще без привязок.

00:06:17.580 --> 00:06:20.560
Другие могут иметь три или четыре привязки к разным службам.

00:06:20.740 --> 00:06:24.140
Сочетание триггеров и привязок делает Azure Functions такими мощными.

00:06:24.140 --> 00:06:27.320
Вы пишете бизнес-логику – основной код принятия решений.

00:06:27.320 --> 00:06:29.460
Платформа берет на себя всю интеграцию.

00:06:29.700 --> 00:06:33.120
Ваша функция остается небольшой, целенаправленной и понятной.

00:06:33.440 --> 00:06:34.660
Вопрос ценообразования.

00:06:34.860 --> 00:06:37.160
Цены – это то, что больше всего удивляет новичков.

00:06:37.300 --> 00:06:39.760
Для большинства людей план потребления – consumption – выбор по умолчанию.

00:06:39.940 --> 00:06:41.860
И в 90% случаев стоит начинать именно с него.

00:06:42.060 --> 00:06:42.860
Вот как это работает.

00:06:43.060 --> 00:06:45.540
Вы платите только тогда, когда ваша функция действительно выполняется.

00:06:45.680 --> 00:06:47.580
Когда она простаивает, вы ничего не платите.

00:06:47.740 --> 00:06:48.760
Ноль, ни копейки.

00:06:48.940 --> 00:06:50.540
Счет состоит из двух компонентов.

00:06:50.540 --> 00:06:54.120
Во-первых, количество выполнений, то есть сколько раз срабатывает ваша функция.

00:06:54.120 --> 00:06:57.780
Во-вторых, время выполнения, измеряемое в так называемых GB секундах.

00:06:57.840 --> 00:07:01.300
Это, по сути, время работы функции, умноженное на объем использованной памяти.

00:07:01.540 --> 00:07:02.980
Бесплатная квота очень щедрая.

00:07:03.120 --> 00:07:07.340
Вы получаете 1 миллион выполнений в месяц и 400 тысяч гигабайтов в секунду совершенно бесплатно.

00:07:07.480 --> 00:07:11.600
Для большинства небольших проектов, любительских приложений и прототипов вы никогда не заплатите ни цента.

00:07:11.680 --> 00:07:15.220
Вообще, если вы выйдете за рамки бесплатной квоты, тарифы все равно останутся невероятно низкими.

00:07:15.380 --> 00:07:16.900
20 центов за миллион выполнений.

00:07:17.000 --> 00:07:17.780
Это не опечатка.

00:07:17.960 --> 00:07:19.460
20 центов за миллион запусков.

00:07:19.460 --> 00:07:22.580
Представьте это как оплату за электричество только тогда, когда вы включаете выключатель.

00:07:22.720 --> 00:07:25.300
Нет никакой ежемесячной абонентской платы за проводку в ваших стенах.

00:07:25.440 --> 00:07:27.640
Вы платите только за ту энергию, которую реально потребили.

00:07:27.740 --> 00:07:29.140
Конечно, есть и другие планы.

00:07:29.300 --> 00:07:32.000
Flex Consumption – более новый план, предоставляющий поддержку виртуальных сетей.

00:07:32.120 --> 00:07:35.260
Премиум держит ваши функции всегда разогретыми, чтобы не было задержек при холодном старте.

00:07:35.400 --> 00:07:38.560
Dedicated предоставляет фиксированную емкость в рамках традиционного плана App Service.

00:07:38.720 --> 00:07:41.500
Но для начала работы Consumption почти всегда является правильным выбором.

00:07:41.580 --> 00:07:42.920
Однако есть одно предостаряжение.

00:07:42.920 --> 00:07:46.400
Бесплатная квота распределяется между всеми вашими приложениями-функциями в рамках одной подписки.

00:07:46.520 --> 00:07:49.980
Если у вас 10 приложений-функций, все они используют тот же 1 миллион бесплатных выполнений.

00:07:50.100 --> 00:07:53.040
Так что следите за этим, если начнете создавать больше нескольких приложений.

00:07:53.380 --> 00:07:54.460
Ценообразование отличное.

00:07:54.620 --> 00:07:56.620
Но давайте разберем это на реальном примере.

00:07:56.760 --> 00:07:57.600
Сценарии из жизни.

00:07:57.780 --> 00:08:01.060
Представьте, что вы управляете сайтом, где пользователи загружают фотографии профиля.

00:08:01.200 --> 00:08:04.000
Эти изображения огромные, например, по 10 мегабайтам каждая.

00:08:04.100 --> 00:08:06.020
И это создает несколько серьезных проблем.

00:08:06.260 --> 00:08:07.700
Большие файлы дороже хранить.

00:08:07.700 --> 00:08:12.860
Они замедляют сайт при каждой загрузке страницы и раздражают пользователей, вынужденных ждать фото.

00:08:12.980 --> 00:08:16.020
Поэтому вам нужно автоматически уменьшать эти изображения.

00:08:16.220 --> 00:08:19.540
Без Azure Functions вам пришлось бы создавать фоновый процесс с нуля.

00:08:19.700 --> 00:08:25.780
Это значит арендовать отдельный сервер, настраивать очередь для управления нагрузкой и писать код для координации всех элементов.

00:08:25.900 --> 00:08:29.620
Это куча ненужной сложности для такой простой задачи, как сжатие изображения.

00:08:29.820 --> 00:08:33.000
С Azure Functions вам нужны только один блок, триггер и одна функция.

00:08:33.140 --> 00:08:34.700
И никаких серверов, о которых нужно беспокоиться.

00:08:35.400 --> 00:08:37.080
Позвольте мне показать, как это работает.

00:08:37.080 --> 00:08:40.840
Пользователь загружает фото на ваш сайт, и файл попадает в Azure Blob Storage.

00:08:41.000 --> 00:08:43.760
Как только он появляется, автоматически срабатывает Blob Trigger.

00:08:43.920 --> 00:08:48.340
Ваша функция просыпается, выполняет код сжатия и сохраняет уменьшенную версию обратно в хранилище.

00:08:48.500 --> 00:08:50.300
Все это происходит за считанные секунды.

00:08:50.460 --> 00:08:54.660
Пользователь даже не ждет, ведь весь процесс идет в фоновом режиме, совершенно незаметно.

00:08:54.820 --> 00:08:59.060
Вот еще один повседневный пример – отправка приветственного письма при регистрации в вашем сервисе.

00:08:59.160 --> 00:09:02.240
HTTP Trigger перехватывает запрос на регистрацию с вашего сайта.

00:09:02.240 --> 00:09:06.360
Ваша функция запускается, получает email пользователя, отправляет приветствие через SendGrid.

00:09:06.360 --> 00:09:07.040
И на этом все.

00:09:07.180 --> 00:09:09.180
Пользователь получает письмо почти мгновенно.

00:09:09.380 --> 00:09:13.980
Не нужно настраивать почтовый сервер или очередь отправки, всего одна функция, одна задача и готово.

00:09:14.080 --> 00:09:16.440
Именно для таких задач и были созданы Azure Functions.

00:09:16.640 --> 00:09:19.420
Небольшие, узкоспециализированные, событийно-ориентированные задачи.

00:09:19.540 --> 00:09:24.640
Немасштабные приложения и сложные рабочие процессы, а одно хорошо выполненное дело, запущенное событием извне.

00:09:24.740 --> 00:09:26.480
Когда использовать Azure Functions?

00:09:26.700 --> 00:09:29.920
Итак, когда стоит использовать функции, а когда что-то другое?

00:09:29.920 --> 00:09:31.680
Вот быстрый способ принять решение.

00:09:31.860 --> 00:09:35.980
Спросите себя, является ли задача короткой, событийно-ориентированной и не имеющей состояния.

00:09:36.100 --> 00:09:39.920
Если вы ответили «да» на все три вопроса, то Azure Functions – подходящий инструмент.

00:09:40.160 --> 00:09:42.000
Начнем с хороших вариантов использования.

00:09:42.200 --> 00:09:43.980
API и WebHooki подходят идеально.

00:09:44.200 --> 00:09:49.120
Вам нужен легкий in-point, который отвечает на HTTP запрос, выполняет одно действие и возвращает результат.

00:09:49.360 --> 00:09:51.700
Это как раз-то для чего созданы HTTP-треггеры.

00:09:51.880 --> 00:09:54.520
Обработка файлов и изображений – еще один отличный пример.

00:09:54.520 --> 00:09:59.680
Файл попадает в хранилище, ваша функция срабатывает, преобразует его и сохраняет результат без всякого сервера.

00:09:59.760 --> 00:10:04.560
Плановые задачи, такие как ночная очистка или создание отчетов, отлично работают с триггерами по таймеру.

00:10:04.660 --> 00:10:08.060
Преобразование данных для ETL-конвейеров также является распространенной задачей.

00:10:08.220 --> 00:10:13.260
Функции идеально подходят в качестве «клея» для интеграции, связывая сервисы, которые не взаимодействуют напрямую.

00:10:13.400 --> 00:10:15.780
Теперь поговорим о том, когда функции не подходят.

00:10:15.960 --> 00:10:21.360
Длительные процессы – это проблема, так как в плане потребления у функций по умолчанию есть ограничение по времени в 5 минут,

00:10:21.520 --> 00:10:23.460
которое можно увеличить до 10 при настройке.

00:10:23.460 --> 00:10:26.300
Если ваша задача выполняется дольше, вам нужно другое решение.

00:10:26.440 --> 00:10:29.040
Приложение с сохранением состояния – еще один неподходящий вариант.

00:10:29.220 --> 00:10:31.240
Функция «Ничего не помнят» между запусками.

00:10:31.420 --> 00:10:35.760
Если вам нужно поддерживать состояние сеанса или отслеживать прогресс между этапами, это противоречит их архитектуре.

00:10:35.860 --> 00:10:37.980
Тяжелые вычислительные нагрузки также не подходят.

00:10:38.160 --> 00:10:42.840
Если вам требуется постоянная нагрузка на процессор в течение минут или часов, лучше выбрать виртуальную машину или контейнер.

00:10:42.900 --> 00:10:48.400
А сложные рабочие процессы, где одна задача зависит от другой, лучше обрабатывать с помощью Durable Functions или Logic Apps.

00:10:48.400 --> 00:10:50.020
Вот краткий обзор альтернатив.

00:10:50.020 --> 00:10:53.560
Azure Logic Apps – это вариант без написания кода для связывания сервисов.

00:10:53.700 --> 00:10:57.500
Если вам не нужно писать собственный код, Logic Apps справится с задачей с помощью визуального конструктора.

00:10:57.680 --> 00:11:01.100
Azure App Service предназначен для полноценных веб-приложений, работающих круглосуточно.

00:11:01.300 --> 00:11:04.760
Если вам нужен полноценный веб-сайт или API, которые всегда доступны, это ваш инструмент.

00:11:04.980 --> 00:11:08.940
Azure Container Apps предоставляет контейнеризированные микросервисы с расширенным контролем над средой выполнения.

00:11:09.080 --> 00:11:12.980
А Azure Virtual Machines дает вам полный контроль над операционной системой, если это необходимо.

00:11:12.980 --> 00:11:14.200
Вот простое правило.

00:11:14.400 --> 00:11:19.120
Если вы можете описать задачу одним предложением, она, скорее всего, отлично подходит для функции.

00:11:19.280 --> 00:11:21.060
Сжимать изображение при их загрузке.

00:11:21.200 --> 00:11:23.740
Отправлять приветвенное письмо при регистрации пользователя.

00:11:23.940 --> 00:11:25.960
Запускать задачу очистки каждую полночь.

00:11:26.060 --> 00:11:28.280
Одно предложение, одна задача, одна функция.

00:11:28.480 --> 00:11:30.800
Распространенные ошибки новичков, которых следует избегать.

00:11:30.920 --> 00:11:33.080
Теперь поговорим о том, на что стоит обратить внимание.

00:11:33.280 --> 00:11:36.020
Это ошибки, на которых спотыкаются почти все начинающие.

00:11:36.180 --> 00:11:39.440
Типичная ошибка новичка – думать, что функции всегда бесплатны.

00:11:39.440 --> 00:11:47.460
Бесплатный лимит щедр и миллион выполнений кажется огромным числом, но если ваша функция станет виральной или ее атакует бот, выполнение закончится быстро.

00:11:47.600 --> 00:11:52.440
Поэтому следите за использованием, настройте бюджетные оповещения в Azure и не получите неожиданный счет в конце месяца.

00:11:52.600 --> 00:11:55.080
Еще одна ошибка – игнорирование холодных запусков.

00:11:55.180 --> 00:11:57.860
Первый запуск функции после простоя занимает больше времени.

00:11:58.080 --> 00:12:00.340
В плане потребления это может занять несколько секунд.

00:12:00.500 --> 00:12:02.260
Для большинства случаев это приемлемо.

00:12:02.340 --> 00:12:08.720
Но если вы создаете API, чувствительный к задержкам, где важна каждая милля секунда, рассмотрите тарифный план премиум или включите всегда готовые экземпляры.

00:12:08.720 --> 00:12:11.620
И, наконец, создание функций, которые работают слишком долго.

00:12:11.760 --> 00:12:15.640
У плана потребления есть время ожидания – 5 минут по умолчанию, максимум 10 минут.

00:12:15.820 --> 00:12:20.020
Если вашей функции нужно 15 минут на обработку файла, она будет прервана на полпути.

00:12:20.220 --> 00:12:23.460
Разбейте задачу на части поменьше или используйте другой план размещения.

00:12:23.620 --> 00:12:27.060
Еще одна частая ошибка – не использовать развертывание Run from Package.

00:12:27.180 --> 00:12:31.700
Это простое изменение конфигурации улучшает холодный старт и повышает надежность развертывания.

00:12:31.880 --> 00:12:34.900
Вместо копирования отдельных файлов вы развертываете цип архив.

00:12:34.900 --> 00:12:37.360
Это одна галочка на портале. Просто поставьте ее.

00:12:37.520 --> 00:12:40.780
Открытие HTTP-инпоинтов без аутентификации – еще одна ловушка.

00:12:40.980 --> 00:12:44.680
Легко оставить функцию в анонимном режиме во время тестирования и забыть ограничить к ней доступ.

00:12:44.880 --> 00:12:46.860
Устанавливайте правильный уровень авторизации сразу.

00:12:47.060 --> 00:12:48.820
Используйте ключи функции или администратора.

00:12:48.960 --> 00:12:50.060
Не оставляйте дверь открытой.

00:12:50.220 --> 00:12:53.280
Использование одной учетной записи хранения для нескольких функций также является проблемой.

00:12:53.360 --> 00:12:54.680
При разработке это допустимо.

00:12:54.820 --> 00:12:57.920
В продакшене у каждой функции должна быть своя учетная запись хранения.

00:12:58.100 --> 00:13:01.940
Иначе возникнет проблема шумного соседа, когда трафик одной функции замедляет другую.

00:13:01.940 --> 00:13:04.200
И, наконец, отсутствие Application Insights.

00:13:04.460 --> 00:13:05.780
Без него вы работаете вслепую.

00:13:05.940 --> 00:13:08.420
Вы не увидите сбоев, ошибок или проблем с производительностью.

00:13:08.560 --> 00:13:11.560
Вы не узнаете, работает ли функция слишком долго или тихо завершается с ошибкой.

00:13:11.700 --> 00:13:13.120
Включите его с самого первого дня.

00:13:13.280 --> 00:13:15.560
Это займет 30 секунд и сэкономит часы отладки.

00:13:15.740 --> 00:13:19.660
Золотое правило – функции должны быть маленькими, узкоспециализированными и без сохранения состояния.

00:13:19.800 --> 00:13:21.600
Одна задача на одну функцию, не более.

00:13:21.800 --> 00:13:23.200
Итак, это и есть вся система.

00:13:23.380 --> 00:13:27.120
Azure Functions – это бессерверные вычисления, запускающие фрагменты кода в ответ на события.

00:13:27.240 --> 00:13:29.420
Вы платите только тогда, когда ваш код выполняется.

00:13:29.420 --> 00:13:32.780
Триггеры активируют функцию, привязки соединяют ее с нужными данными,

00:13:32.980 --> 00:13:35.920
а план потребления делает ее почти бесплатной для небольших проектов.

00:13:36.080 --> 00:13:40.780
Лучшее, что можно сделать прямо сейчас – создать простую функцию с HTTP-триггером на портале Azure.

00:13:40.940 --> 00:13:42.860
Это займет 5 минут и ничего не стоит.

00:13:43.080 --> 00:13:46.140
Подписывайтесь на Microsoft Knowledge на Getas для простых разборов

00:13:46.140 --> 00:13:49.300
и делитесь видео с теми, кто спрашивает, что такое сервер Лесос.

00:13:49.300 --> 00:13:49.860
Фрау

00:13:49.860 --> 00:13:50.000
Фрау