Классификация ПО: stateful vs stateless
Умение классифицировать ПО - важный хард скил профессионального программиста. Он позволяет быстрее разбираться с тем, как устроен незнакомый софт и чего можно ждать от его эксплуатации.
👋 Сегодня рассмотрим 2 больших класса ПО: stateful и stateless.
☁️ Stateless - ПО без хранения состояния. Если вашей программе не нужно ничего хранить на диске, то она stateless. Самый простой пример stateless приложения - калькулятор. С одними и теми же входными данными калькулятор всегда вернёт одинаковый результат. Ничего сохранять не нужно - всё можно быстро рассчитать заново.
🪨 Stateful - ПО c хранением состояния. Состояние - это те данные, которые мы хотим сохранить надолго. Они не должны потеряться при перезапуске программы или компьютера (такие “важные” данные называются персистентными, анг. persistent). Stateful приложения сохраняют данные на жёсткий диск. Самый простой пример stateful приложения - заметки. Пользователь открывает заметки исключительно ради сохранения данных, никаких сложных алгоритмов там нет.
🔗 Рассмотрим свойства этих классов ПО:
1️⃣ Stateless приложения проще масштабировать - можно просто поднять несколько копий приложения и балансировать нагрузку между ними. Со stateful так не получится: когда данных становится слишком много (настолько, что на жёсткий диск не влезает), придётся как-то разделять данные между копиями приложения. При чём каждая копия будет обслуживать свою уникальную (!) часть общих данных. Этот процесс называется шардирование.
2️⃣ Stateless приложения проще запустить в облаке. В облачном окружении копии приложения периодически завершаются и запускаются, при этом возможен автоматический переезд приложения с одного сервера на другой. Со stateful приложениями это так просто не прокатит - недостаточно запустить приложение на другом сервере, надо ещё все его данные перевезти. А это совсем непростая задача 😅
3️⃣ Для stateful приложений надо заботиться о сохранности данных. Резервное копирование, хранение нескольких копий в разных ЦОД, проверки целостности данных (например, с помощью контрольных сумм) - это всё огромный пласт работ, которые надо выполнить для нормального функционирования приложения.
4️⃣ Stateless приложениям проще эволюционировать. В реальных продуктах важно позаботиться о том, как вы будете поставлять новые версии приложения. И как откатывать багованные версии - тоже 😉 Это сама по себе непростая задача, а для stateful приложений она становится вдвойне сложнее. Как обновить формат хранимых данных? А как откатить обновление? А что, если какие-то данные перед откатом успели записаться в новом формате? На все эти вопросы придётся искать ответ 😐
🖼 Со стороны может показаться, что разделение stateful/stateless - это исключительно бэкендерская тема. Однако, в клиентской разработке оно тоже имеет место. Например, в мобильной разработке часто сохраняют на диск устройства какие-то кеши, пользовательские настройки или черновики. В современном web-фронтенде тоже куча stateful-апишек браузера есть: Cookies, Local Storage, Session Storage, Web SQL, File System Access API и наверняка много чего ещё.
🍋 К этому моменту читатель мог бы придти к выводу, что разработка stateful приложения - это какой-то ужас, надо отказаться от стейта и жизнь станет легче. В целом, это не самый плохой вывод. Если вы можете обеспечить классный пользовательский опыт без хранения данных, то так и делайте. Ваше приложение может работать без регистрации? Супер, в топку её!
🛢 Однако, не просто так говорят, что “данные - новая нефть”. К сожалению, чаще всего без данных обойтись не получается. Что делать в этом случае? Отделяйте слой хранения данных от вычислений (логики приложения). В этом вам помогут разного рода СУБД и файловые серверы (типа S3), они уже умеют решать многие проблемы.
Ставьте огонёк если классификация stateful/stateless для вас полезна 🔥А какое приложение вы сейчас разрабатываете? Напишите в комменты 👇
#theory #architecture
Умение классифицировать ПО - важный хард скил профессионального программиста. Он позволяет быстрее разбираться с тем, как устроен незнакомый софт и чего можно ждать от его эксплуатации.
👋 Сегодня рассмотрим 2 больших класса ПО: stateful и stateless.
☁️ Stateless - ПО без хранения состояния. Если вашей программе не нужно ничего хранить на диске, то она stateless. Самый простой пример stateless приложения - калькулятор. С одними и теми же входными данными калькулятор всегда вернёт одинаковый результат. Ничего сохранять не нужно - всё можно быстро рассчитать заново.
🪨 Stateful - ПО c хранением состояния. Состояние - это те данные, которые мы хотим сохранить надолго. Они не должны потеряться при перезапуске программы или компьютера (такие “важные” данные называются персистентными, анг. persistent). Stateful приложения сохраняют данные на жёсткий диск. Самый простой пример stateful приложения - заметки. Пользователь открывает заметки исключительно ради сохранения данных, никаких сложных алгоритмов там нет.
🔗 Рассмотрим свойства этих классов ПО:
1️⃣ Stateless приложения проще масштабировать - можно просто поднять несколько копий приложения и балансировать нагрузку между ними. Со stateful так не получится: когда данных становится слишком много (настолько, что на жёсткий диск не влезает), придётся как-то разделять данные между копиями приложения. При чём каждая копия будет обслуживать свою уникальную (!) часть общих данных. Этот процесс называется шардирование.
2️⃣ Stateless приложения проще запустить в облаке. В облачном окружении копии приложения периодически завершаются и запускаются, при этом возможен автоматический переезд приложения с одного сервера на другой. Со stateful приложениями это так просто не прокатит - недостаточно запустить приложение на другом сервере, надо ещё все его данные перевезти. А это совсем непростая задача 😅
3️⃣ Для stateful приложений надо заботиться о сохранности данных. Резервное копирование, хранение нескольких копий в разных ЦОД, проверки целостности данных (например, с помощью контрольных сумм) - это всё огромный пласт работ, которые надо выполнить для нормального функционирования приложения.
4️⃣ Stateless приложениям проще эволюционировать. В реальных продуктах важно позаботиться о том, как вы будете поставлять новые версии приложения. И как откатывать багованные версии - тоже 😉 Это сама по себе непростая задача, а для stateful приложений она становится вдвойне сложнее. Как обновить формат хранимых данных? А как откатить обновление? А что, если какие-то данные перед откатом успели записаться в новом формате? На все эти вопросы придётся искать ответ 😐
🖼 Со стороны может показаться, что разделение stateful/stateless - это исключительно бэкендерская тема. Однако, в клиентской разработке оно тоже имеет место. Например, в мобильной разработке часто сохраняют на диск устройства какие-то кеши, пользовательские настройки или черновики. В современном web-фронтенде тоже куча stateful-апишек браузера есть: Cookies, Local Storage, Session Storage, Web SQL, File System Access API и наверняка много чего ещё.
🍋 К этому моменту читатель мог бы придти к выводу, что разработка stateful приложения - это какой-то ужас, надо отказаться от стейта и жизнь станет легче. В целом, это не самый плохой вывод. Если вы можете обеспечить классный пользовательский опыт без хранения данных, то так и делайте. Ваше приложение может работать без регистрации? Супер, в топку её!
🛢 Однако, не просто так говорят, что “данные - новая нефть”. К сожалению, чаще всего без данных обойтись не получается. Что делать в этом случае? Отделяйте слой хранения данных от вычислений (логики приложения). В этом вам помогут разного рода СУБД и файловые серверы (типа S3), они уже умеют решать многие проблемы.
Ставьте огонёк если классификация stateful/stateless для вас полезна 🔥А какое приложение вы сейчас разрабатываете? Напишите в комменты 👇
#theory #architecture
🔥5👍1
Масштабирование: вертикальное vs горизонтальное
Если ваше приложение успешно, то с ростом количества пользователей вы рано или поздно упрётесь в потолок производительности, которую могут обеспечить ваши серверы. При приближении к этому потолку крайне остро встаёт вопрос масштабирования - увеличения доступных вычислительных мощностей.
📈 Есть 2 подхода к масштабированию бэкенда:
1️⃣ Вертикальное масштабирование - выкидваем старый сервер, покупаем сервер по-мощнее ему на замену. Это если грубо 😉 Но суть именно такая: при вертикальном масштабировании увеличивают количество вычислительных ресурсов, доступных на одной машине.
2️⃣ Горизонтальное масштабирование - оставляем старый сервер как есть, покупаем второй такой же. Поднимаем вторую копию приложения, распределяем нагрузку между ними.
🧐 В чём разница между двумя подходами?
↕️ Вертикальное масштабирование технически выполнить проще, поэтому долгое время компании предпочитали именно этот подход. Однако с ним есть одна большая проблема: стоимость такого масштабирования растёт нелинейно. В итоге, на определённом этапе вертикальное масштабирование становится неприемлемо дорогим.
↔️ Горизонтальное масштабирование, напротив, выполнить труднее - с ним куча маленьких проблем. Надо администрировать больше серверов, заботиться о балансировке нагрузки, больше компонентов аппаратного обеспечения закупать в конце концов. Однако, из-за того, что аппаратное обеспечение при горизонтальном масштабировании используется типовое, производящееся крупными партиями, экономика начинает сходиться лучше. При таком подходе рост стоимости эксплуатации практически линейный. Из-за лучших экономических характеристик, последние лет 10 горизонтальное масштабирование - де-факто стандарт индустрии.
💡 Какие отсюда можно сделать выводы? Позаботьтесь о масштабируемости системы на этапе проектирования. Задайте себе вопрос: сможете ли вы поднять вторую копию приложения, когда это станет необходимо? Что нужно сделать, чтобы это не составило больших проблем?
🔥 В отличие от серверных систем, этот канал масштабируется исключительно вертикально :) Делитесь контентом с друзьями и коллегами - посмотрим, какую нагрузку мы можем выдержать 😊
#theory #highload #architecture
Если ваше приложение успешно, то с ростом количества пользователей вы рано или поздно упрётесь в потолок производительности, которую могут обеспечить ваши серверы. При приближении к этому потолку крайне остро встаёт вопрос масштабирования - увеличения доступных вычислительных мощностей.
📈 Есть 2 подхода к масштабированию бэкенда:
1️⃣ Вертикальное масштабирование - выкидваем старый сервер, покупаем сервер по-мощнее ему на замену. Это если грубо 😉 Но суть именно такая: при вертикальном масштабировании увеличивают количество вычислительных ресурсов, доступных на одной машине.
2️⃣ Горизонтальное масштабирование - оставляем старый сервер как есть, покупаем второй такой же. Поднимаем вторую копию приложения, распределяем нагрузку между ними.
🧐 В чём разница между двумя подходами?
↕️ Вертикальное масштабирование технически выполнить проще, поэтому долгое время компании предпочитали именно этот подход. Однако с ним есть одна большая проблема: стоимость такого масштабирования растёт нелинейно. В итоге, на определённом этапе вертикальное масштабирование становится неприемлемо дорогим.
↔️ Горизонтальное масштабирование, напротив, выполнить труднее - с ним куча маленьких проблем. Надо администрировать больше серверов, заботиться о балансировке нагрузки, больше компонентов аппаратного обеспечения закупать в конце концов. Однако, из-за того, что аппаратное обеспечение при горизонтальном масштабировании используется типовое, производящееся крупными партиями, экономика начинает сходиться лучше. При таком подходе рост стоимости эксплуатации практически линейный. Из-за лучших экономических характеристик, последние лет 10 горизонтальное масштабирование - де-факто стандарт индустрии.
💡 Какие отсюда можно сделать выводы? Позаботьтесь о масштабируемости системы на этапе проектирования. Задайте себе вопрос: сможете ли вы поднять вторую копию приложения, когда это станет необходимо? Что нужно сделать, чтобы это не составило больших проблем?
🔥 В отличие от серверных систем, этот канал масштабируется исключительно вертикально :) Делитесь контентом с друзьями и коллегами - посмотрим, какую нагрузку мы можем выдержать 😊
#theory #highload #architecture
🔥6