Простые правила, которые помогут не прохрюкать прибыль проекта из-за неоптимизированной разработки

Ничто так не поднимает настроение команде разработчиков, как наблюдение за тем, как приложение становится вирусным. Это прекрасное чувство — по крайней мере, до тех пор, пока не приходит ежемесячный счет за облачные вычисления.

Некоторые разработчики считают, что управление стоимостью вычислений — это обязанность команды devops. Кодеры пишут программное обеспечение, бросают его через стену, и пусть кто-то другой беспокоится об оплате за него. Нет ничего более далекого от правды.

Умные разработчики знают, что их кодовые решения имеют большое значение для итоговой прибыли компании. Объемный код работает медленнее и требует больше облачных ресурсов для запуска. Выбор лучших алгоритмов и написание более компактного кода — это больше, чем просто скорость. Хорошо написанный код стоит меньше для запуска.

Разработчики не всегда видят связь. Легко писать код на собственной машине, где ОЗУ и дополнительное дисковое пространство были оплачены при покупке машины. Если у вас есть два терабайта дискового пространства, вы можете не заметить, сколько его занимает ваш код. Если новый алгоритм выполняется в два раза дольше, ваш рабочий стол может даже не моргнуть — и, кроме того, кто заметит несколько дополнительных миллисекунд? Но почти наверняка удвоение вычислений приведет к увеличению счета за облако.

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

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

Пишите более быстрый код

Большинство разработчиков не тратят много времени на оптимизацию своего кода. Если он запускается за доли секунды на их ноутбуке, они не замечают, что со временем он работает на 20%, 30% или даже на 300% медленнее. Программа по-прежнему отвечает за доли секунды. Но эти различия складываются, когда они встречаются на сервере миллионы раз. Тщательное профилирование может пометить медленные части. Их переписывание может уменьшить количество экземпляров, необходимых вашему приложению.

Уменьшите объем оперативной памяти

Объем используемой оперативной памяти является важным параметром для ценообразования облачных экземпляров. Во многих случаях удвоение оперативной памяти также удваивает стоимость. Программисты могут уменьшить объем оперативной памяти, избегая хранения данных в памяти. Некоторые алгоритмы потоковой передачи, такие как классы Stream в Java, предназначены для работы с большими файлами данных, не загружая их все в память. Проект Apache DataSketches генерирует приблизительные ответы для сложной статистики больших данных, не занимая при этом всю память.

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

Используйте изображения и видео с более низким разрешением

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

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

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

Сбросить ненужные данные

Многие разработчики — цифровые крысы, которые хранят информацию на тот случай, если она им когда-нибудь понадобится. Они заполняют таблицы бесконечными столбцами, а затем никогда не удаляют строки. Дополнительные данные ничего не стоят, если у вас есть оборудование и на диске достаточно места. Но облако берет деньги за все. Будут ли вам действительно нужны все эти ценности в будущем? Нужно ли пользователю так много деталей? Удаление некоторых из этих старых данных сэкономит вам деньги на их хранении и краже.

Ограничить дисковое пространство

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

Очистите свои журналы

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

Перейти без сервера

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

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

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

Архивировать старые данные

Чем старше данные, тем реже к ним обращаются. Вы можете предвидеть это, настроив приложение для переноса старых данных в более дешевое место. Некоторые облака взимают гораздо меньшую плату за так называемое «холодное хранение», когда доставка битов может занять минуты или даже часы. Другие облака, такие как Wasabi или Backblaze, специализируются на архивном хранении объектов Amazon S3 и взимают значительно меньшую плату, чем основные облака. В некоторых случаях они даже не берут плату за кражу данных. Выгрузка данных, как только они больше не пользуются большим спросом, может быть чрезвычайно рентабельной.

Упростите макеты CSS

Если вы видели теги HTML, сгенерированные некоторыми фреймворками, то знаете, насколько нелепыми могут быть макеты. Это просто теги DIV, полностью вложенные в теги DIV, что стоит денег для создания и доставки. Веб-дизайнер, которого я знаю, хвастается тем, что сократил свои счета за пропускную способность на 30%, просто создав более простой макет с более разумным использованием CSS.

Создавайте статические сайты

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

Различные фреймворки поддерживают эту статическую философию. Jekyll, Hugo, Gridsome и Pelican — это всего лишь несколько инструментов, которые упакуют весь ваш контент в набор компактных неизменяемых файлов. Вы по-прежнему можете встраивать персонализацию на страницы с помощью вызовов AJAX, но большая часть сайта создает небольшую нагрузку на серверы.

Экстернализация вычислений и хранения

По мере того, как браузеры становятся все более мощными, некоторые фреймворки упрощают перенос большего объема вычислений непосредственно на клиент. Хороший код jаvascript или WebAssembly может переложить большую часть нагрузки на компьютер пользователя, а не на ваши облачные серверы. Некоторые разработчики сокращают свой облачный уровень до просто базы данных с небольшой бизнес-логикой для аутентификации. Один друг запускает все со статическим HTML и серверной версией PostgreSQL со встроенными процедурами, выводящими JSON.

Браузеры также имеют более сложные варианты локального хранения информации, такие как стандарт веб-хранилища HTML и API индексированной базы данных W3C. Это уже не просто короткие строки и файлы cookie. Эти данные доступны быстрее, потому что они не передаются через Интернет, и пользователям удобно знать, что их данные не хранятся в централизованной базе данных, которую можно взломать. Зачем платить за хранение и эксфильтрацию данных, если они могут жить на компьютере пользователя бесплатно?

Назначить инженера по затратам

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