Поскольку есть много разработчиков на стороне клиента, которые знают JavaScript и привыкли к тому, как работает этот язык, им очень легко подойти к Node.js и начать создавать свои собственные серверные ВМ. В Serverless есть похожие вещи. К бессерверному режиму очень легко подойти, начать создавать облачный сервис и запустить его. Вам не нужно беспокоиться о настройке и управлении виртуальными машинами, антивирусным программным обеспечением, брандмауэрами и т. Д. - все это делается за вас с помощью управляемой службы.
Теперь вы можете использовать бессерверные фреймворки для масштабного развертывания систем не только для внешних HTTP-приложений, но и для серверных систем, которые могли быть даже дальше от области их компетенции. Это очень доступная вещь, чтобы подняться до
Влияние Serverless на экосистему Node.js
Поскольку node.js является звездой бессерверного языка, мы увидим бессерверный язык, поскольку он становится все более популярным и привлекает еще больше людей в экосистему node.js. Однако есть несколько подводных камней, с которыми приходится сталкиваться новым людям, которые приходят в экосистему node.js. В последнее время Node.js начал игнорировать некоторые уроки, которые мы извлекли из веб-пространства. Мы стали слишком довольны тем фактом, что, поскольку эти вещи будут долго работать на серверах, не имеет значения, огромны ли наши пакеты, и мы загружаем все в мире и сглаживаем этот процесс.
Кроме того, мы склонны думать, что до тех пор, пока приложение не будет занимать огромные объемы памяти событий, кого волнуют крошечные файлы, которые у нас есть, и тому подобное. Node.js хорош тем, что в простых случаях возникает очень быстро. В тех случаях, когда вы решаете продолжить и импортировать Lodash и каждую отдельную гигантскую структуру, которую вы можете придумать, в память, потребуется время, чтобы даже прочитать эти вещи с диска. Таким образом, объем памяти означает, что люди, которые используют эти библиотеки внутри функций, должны платить больше, потому что они должны платить за то, чтобы этот объем памяти действительно существовал.
Если вы загружаете в память гигантские библиотеки чаще, чем когда-либо, вам не нужно за это платить. Если я могу выбрать библиотеку, которая составляет один мегабайт, по сравнению с библиотекой, которая составляет 30 мегабайт, это может означать большую разницу для моего счета в конце месяца в случае бессерверной версии.
Действительно стоит подумать о том, как мы можем двигаться дальше и сокращать то, что на самом деле загружается. В этом могут помочь многие вещи.
Классический пример влияния Node.js
Пакет функций Azure объединяет ваш код в веб-пакеты. Это не обязательно так сильно, чтобы уменьшить объем памяти. Для этого вам нужно запустить Uglify поверх результатов вывода веб-пакета. Однако это сокращает время загрузки.
Кто-то из Microsoft Azure протестировал пакет с четырьмя крупнейшими модулями узлов, которые смог найти. Он пытался понять влияние бессерверного режима на Node.js. Он поместил их в функцию и измерил ее на i7 с SSD. Это была невероятно быстрая система, но для того, чтобы эта функция сработала впервые, потребовалось около двух секунд.
Затем мы заставили Node.js считывать все это в память. Когда он запаковал его через Интернет, это заняло около ста миллисекунд - огромное улучшение.
Когда вы работаете без сервера, загрузка этих модулей в память займет еще больше времени. Многие поставщики продаж фактически имеют ограничения на количество контента, который вы можете разместить там. Когда мы пишем эти пакеты, важно думать, особенно если мы хотим, чтобы эти пакеты работали без сервера, нам нужно подумать, что они будут делать.
Прочтите документацию перед написанием кода
В одном случае приложение socket.io в ведущей компании, занимающейся базами данных, начало использовать слишком много сокетов. Разработчики Node.js, работающие над приложением, поняли, что написанная ими функция поступает туда, постоянно ее использует, открывая сокеты, но не закрывая их. Конечно, они злоупотребляли библиотекой. Они неправильно прочитали документацию. Они использовали функцию не так, как предписано, но использовали ее так, как казалось естественным, - внутри своей функции.
Быстрый обходной путь при написании пакета, который может быть вредным для использования в бессерверной среде, разработчики должны написать предупреждение. Инструкции о том, как создать одноэлементный экземпляр этого объекта вне функции, чтобы он оставался в их памяти. Если мы говорим о примере socket.io выше, инструкция о том, как написать код для закрытия сокета до завершения функций, была бы очень полезной.
Эти предупреждения и инструкции могут во многом помочь убедиться, что любой, кто кодирует Node.js на бессерверной основе, не почувствует себя отчужденным. Будет окупаться, если люди добьются успеха таким образом.
Node.js и serverless действительно продвинулись очень далеко и хорошо себя зарекомендовали из-за сильной природы вещей с открытым исходным кодом и того, насколько легко получить доступ к частям запущенной системы.
Возможные риски
Поскольку реализация услуг сегодня очень зависит от поставщика, здесь есть некоторые риски. Так что об этом стоит помнить. Есть люди, которые думают о способах решения некоторых из этих проблем.
Несмотря на то, что поставщики создают конкретную реализацию, которая в основном предназначена для работы на их облачной платформе, они могут сделать ее с открытым исходным кодом. Они должны попытаться построить ее так, чтобы она была немного более портативной. Они должны убедиться, что вы не чувствуете себя заблокированным, даже если он создан для хорошей работы на их облачной платформе.
Усилия должны быть в том направлении, в котором поставщики стараются убедиться, что они, по крайней мере, создают его с открытым исходным кодом и в конечном итоге работают над тем, чтобы это было даже открытой платформой.
Будущее уже наступило!
Когда вы думаете о развертывании сервисов в облаке, подумайте о бессерверном пути, независимо от того, какой поставщик вам подходит. Все дело в попытках повысить гибкость, с которой вы можете развертывать и создавать сервисы, которые, как вы можете быть уверены, будут хорошо работать в масштабе. Node.js может создавать больше без серверов, и вы уже в хорошей форме. Если вы знаете предпочтительный язык для этой платформы - Node.js, то вы уже впереди всех. Serverless воспользовался тем фактом, что у Node.js и JavaScript уже было это большое, большое открытое сообщество.
Как вы думаете?
