Ранее на этой неделе я записался на курс Райана Крооненбурга по Удеми о том, как сдать экзамен AWS Certified Developer Associate (CDA). Пока что мне действительно нравится материал, и меня восхищают многие функции, которые предлагает AWS. Сам Крооненбург является одновременно разработчиком и страстным сторонником многих продуктов в экосистеме AWS, и нетрудно понять, почему. Как объясняет Крооненбург, одна из причин революционности AWS заключается в том, что она предоставляет компаниям инфраструктуру как услугу (IaaS) по разумным ценам.

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

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

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

  • сколько одновременных запросов получает приложение в секунду
  • сколько времени требуется серверу для обработки каждого запроса
  • сколько записей можно получить из базы данных приложения за заданный промежуток времени.

Для решения проблемы масштабируемости в этих трех случаях потребуются разные подходы. В первом случае возможным решением может быть выделение дополнительных серверов с помощью AWS, чтобы приложение могло обрабатывать большие объемы пользовательского трафика. Во втором случае решение может включать рефакторинг самого кода, чтобы минимизировать пространственно-временную сложность алгоритмов, содержащихся в коде, для повышения производительности. В третьем случае потенциальным решением может быть оптимизация SQL-запросов по скорости или изменение способа хранения записей. (Подробнее о написании быстрых SQL-запросов вы можете узнать здесь).

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