Такие технологические стеки, как LAMP, MEAN и MERN, способствовали повышению производительности разработчиков. Всего четыре компонента дают вам все необходимое для быстрой и простой разработки веб-приложений. И хотя эти стеки обеспечивают надежную основу из коробки, они не лишены сложности и не всегда предназначены для масштабирования. В результате организации часто сталкиваются с необходимостью перехода от приложения V1, построенного на стеке из четырех частей, к более простой конфигурации. Снижение сложности — это отличный способ повысить стабильность, что, в свою очередь, является отличным способом снизить затраты.
В HarperDB мы называем этот процесс упрощения «свертыванием стека». Меньше движущихся частей означает, что меньше может пойти не так, в конце концов. В этой статье мы рассмотрим проблемы, связанные с четырехкомпонентным стеком, и предложим некоторые альтернативы, которые помогут сэкономить деньги, уменьшить сложность и решить некоторые проблемы производительности в масштабе.
Основные сведения о четырехкомпонентных стеках
Ниже приведены некоторые популярные четырехкомпонентные стеки и их (4) компоненты:
MERN
- MongoDB
- Express
- React
- NodeJS
MEAN
- MongoDB
- Express
- Angular
- NodeJS
LAMP (отредактировано, потому что прошло много времени, и Хавьер Лопес прав в комментариях)
- Linux
- Apache
- MySQL
- PHP
В каждом из этих стеков есть база данных (Mongo или MySQL), фреймворк на стороне клиента (Angular или React), фреймворк на стороне сервера (Express или Laravel) и среда выполнения основного языка (NodeJS или PHP). С помощью этих четырех частей вы можете быстро создать пользовательский интерфейс, API и уровни персистентности вашего приложения.
Но подождите, есть еще кое-что, что нужно рассмотреть! Многое!
Как я уже говорил во введении, эти решения просты для понимания, и их легко развернуть. Но есть и некоторые недостатки, которые следует учитывать при планировании на будущее.
Исполнительные приложения, проще говоря, должны делать две вещи: реагировать достаточно быстро, чтобы пользователи были довольны, и быть в состоянии обрабатывать всех пользователей, которых они только что сделали такими счастливыми. Четырехкомпонентные стеки включают в себя два звена, которые могут помешать способности вашего приложения достичь этих двух целей: вызов API к вашей базе данных и база данных, которая может поддерживать только ограниченное количество пользователей с предоставленными ресурсами.
Эффективные API, счастливые пользователи
Во-первых, давайте рассмотрим вызов API к базе данных и посмотрим, как можно упростить этот процесс и сделать его более производительным.
В старые времена мы использовали такие вещи, как хранимые процедуры и определяемые пользователем функции, чтобы поместить бизнес-логику в сервер базы данных. Большинство людей (кроме DBA) считали это очень плохой идеей. В HarperDB мы добились этого, интегрировав API-сервер в саму базу данных — эту функцию мы назвали Custom Functions. Используя JavaScript на стороне сервера и основные методы, которые устраняют второй прыжок от API к базе данных, вы уменьшаете задержки и делаете пользователей счастливее, не полагаясь на отдельный серверный фреймворк, такой как Express или Laravel. По сути, мы интегрировали предварительно настроенный сервер Fastify в HarperDB и позволили вам определить свои маршруты и обработчики — больше никаких зависимостей, конфигураций или настроек командной строки. Кроме того, счастливые пользователи, ощущающие меньшую задержку, всегда в выигрыше.
Обеспечение удовлетворенности пользователей в масштабе
Далее давайте рассмотрим поддержку всех ваших счастливых пользователей. Масштабирование — это вызов для приложений во многих отношениях, но самым большим препятствием является стоимость всего этого успеха. Распределение нагрузки — сложная перспектива, но для ее решения появилось множество инструментов, таких как AWS lambdas и другие «бессерверные функции». Но когда речь заходит о традиционных четырехкомпонентных стеках, вам приходится дублировать множество движущихся частей, чтобы обслуживать дополнительных пользователей. Это кажется не очень веселым, и это не так.
Главное препятствие заключается в том, что распределять данные НАМНОГО сложнее, чем распределять приложения. И если вы не спланируете это заранее, вы, скорее всего, обнаружите, что отправляете всех своих пользователей в кластер баз данных, для которых вам постоянно приходится увеличивать ресурсы, что мы называем вертикальным масштабированием. Вертикальное масштабирование происходит по экспоненциальной кривой затрат — причудливый способ сказать, что 2 ГБ оперативной памяти стоят более чем в два раза больше, чем 1 ГБ оперативной памяти… не намного больше, но как только вам начнет требоваться несколько VCPU, несколько ядер и 128 ГБ оперативной памяти для поддержки ваших счастливых пользователей, ваш финансовый директор будет… менее счастлив. Думаю, мы все согласны с тем, что несчастные финансовые директора — это невесело на вечеринках или где-либо еще.
По-настоящему распределенные приложения масштабируются горизонтально. Иными словами, если один узел приложения стоит 10 долларов и поддерживает 1000 счастливых пользователей, то вы просто продолжаете добавлять узлы на каждую тысячу пользователей, которых нужно поддерживать счастливыми. Проблема стека из четырех частей заключается в том, что ни одна из обычных баз данных не предназначена для такого масштабирования. Мы создали HarperDB, чтобы решить именно эту проблему. Счастливые пользователи не остаются счастливыми очень долго, если вы заставляете их ждать, и очень неприятно, когда эта проблема проявляется только тогда, когда вы действительно начинаете видеть большое количество пользователей.
Стек HAN: Счастлив, как вуки дома на Рождество
Разработка приложений — это не только забота о том, чтобы пользователи были довольны. Речь также идет о том, чтобы разработчики, DevOps и финансовые директора были довольны. А сохранение производительности по мере роста без необходимости менять базу данных или API-фреймворк — одно из самых простых решений, которое можно принять сейчас, чтобы оставаться успешным в будущем.
В связи с этим мы называем наши усилия, направленные на то, чтобы сделать весь этот процесс менее напряженным, стеком HAN.
Возможно, вы уже догадались, что HAN-стек означает HarperDB, Angular и Node.js. Angular — это очевидный выбор для создания корпоративных приложений благодаря широким встроенным функциям и поддержке сообщества. Node.js — это невероятно универсальная и удобная среда выполнения JavaScript. А HarperDB консолидирует API и базу данных, обладая при этом на порядки большей производительностью.
Когда приложения и данные развернуты как единое целое, вы можете больше сосредоточиться на логике приложения и меньше — на архитектуре. Мы по-прежнему являемся большими поклонниками стеков HarperDB старой школы, таких как стек HERN. Но с появлением Custom Functions вам больше не нужно обременять себя стеком из четырех частей по мере роста.
Как это стало возможным?
С помощью Custom Functions вы можете определять собственные конечные точки API в HarperDB. Ваши пользовательские конечные точки будут напрямую взаимодействовать с основными операциями, такими как «insert», «search_by_hash», «update» и другими. Это устраняет второе соединение от вашего API к базе данных в пользу прямого соединения с уровнем данных, что обычно снижает задержки API примерно на 50%. Представьте, сколько у вас будет довольных пользователей! Кроме того, вы можете разместить скомпилированный пользовательский интерфейс Angular UI в качестве статического ресурса прямо внутри Custom Functions, так что вы можете фактически создать все свое приложение в одном месте. Это бесспорный выигрыш.
В более традиционных технологических стеках прошлого поколения вам пришлось бы развертывать и размещать код бэкенд API на дополнительных серверах, а затем обращаться к уровню базы данных для решения задач, связанных с базой данных. Как отметил в своей статье Джейк Коэн, директор по ИТ и операциям в HarperDB, «HarperDB сворачивает стек на один сервер, что устраняет практически все сетевые задержки. Это освобождает пространство для достижения более высокой пропускной способности одного сервера». Используя и без того мощную горизонтальную масштабируемость HarperDB, это означает, что теперь вы можете распространять как ваши API, так и вашу базу данных на периферию».
Простой мир, простая жизнь
Существует множество преимуществ упрощенного технологического стека, как для разработчика, так и для организации в целом. Такой стек, как стек HAN, облегчает жизнь разработчикам, создавая возможность использовать современные технологии и сокращая количество языков программирования и фреймворков, с которыми им приходится работать. Это также улучшает сотрудничество, позволяя большему количеству разработчиков с разным опытом работать вместе над одним проектом.
Для организации, чем короче стек, тем легче адаптироваться к кризису и развиваться, когда это необходимо. Большинство современных инфраструктур переходят к модели «разрушения стека», и это позволяет организации быть гибкой, одновременно снижая затраты и задержки. Чем компактнее ваш стек критически важных систем, тем ниже риск. При наличии правильных технологий вы получите преимущества как с точки зрения затрат, так и с точки зрения функциональности. Простота — это ключ к успеху, и именно поэтому девиз HarperDB с самого начала звучит как «Простота без жертв».
Нажмите здесь, чтобы бесплатно запустить экземпляр.