Прошлый месяц ознаменован началом новой вехи для рубистов — релиз Ruby 2.0.0. Вместе с ним обновлённый RubyGems и новые зависимости, включая OpenSSL. Ранее RVM почти ничего не предпринимала для разрешения зависимостей, устанавливая вместо этого LibYAML, так как он был нужен для функционирования RubyGemsк. Ситуация изменилась с появлением OpenSSL, так как это является бОльшей зависимостью. Раньше для Ruby 2.0.0-rc RVM устанавливал OpenSSL. Однако компилирование OpenSSL не лёгкая задача, используя LibYAML.

С восходом социальных приложений, таких, как Facebook, Instagram, YouTube и многих других, управление сгенерированным пользователями контентом стало проблемой, а проблемы нужно решать. Amazon AWS S3, Google Storage, Rackspace Cloud Files и другие похожие сервисы стали появляться, как грибы после дождя, чтобы помочь разработчикам приложений решить актуальную проблему – управление масштабируемым хранилищем активов. И конечно же все они используют “Облако”!

Проблема

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

• 72 часа видео загружаются на YouTube пользователями каждую минуту. (источник)
• 20 миллионов фотографий загружаются в SnapChat каждый день. (источник)
• Pinterest сохранил 8 миллиардов объектов и 410 терабайт данных со времени своего запуска в 2009. (источник)
• Twitter генерирует приблизительно 12 терабайт данных в день. (источник)

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

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

Краткий обзор

Недавно Engine Yard провела исследование рынка PaaS («платформа как услуга») с целью выявления факторов, влияющих на использование компаниями технологии PaaS. Особое внимание было уделено тому, как это облачное решение используется разработчиками программного обеспечения. По итогам исследования было сделано три вывода, касающихся внедрения PaaS.

• Приложения, разворачиваемые на PaaS, инновационны и ориентированы на заказчика. В облаке компании чаще разворачивают «программное обеспечение как услуга» (SaaS), мобильные, торговые и социальные приложения, нежели традиционные ERP- и CRM-системы и приложения для управления цепочкой поставок.
• PaaS широко применяется: почти 60% респондентов заявили, что уже используют PaaS либо планируют внедрить её в течение следующего года.

Факторы, влияющие на решение о внедрении PaaS, можно разделить на три категории:

• Первого порядка: улучшение функциональных показателей
• Второго порядка: улучшение приложений
• Третьего порядка: снижение издержек

Классический сценарий

Вы работаете над проектом, где транзакционные данные хранятся в базе данных. Затем вы развёртываете приложение в рабочей среде, и производительность великолепна! Запросы проходят шустро, и задержка при их вводе практически незаметна. Через несколько дней/недель/месяцев база данных становится всё больше и больше, и скорость запросов замедляется.

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

Администратор базы данных (DBA) посмотрит и проследит, чтобы база данных была оптимально настроена. Он предложит добавить определённые индексы, убрать логирование на отдельную партицию, подправить параметры движка базы данных и убедиться, что база данных здорова. Можно также добавить выделенных IOPS (Input/Output Operations Per second) на EBS диске, чтобы увеличить скорость дисковых партиций. Это даст вам выиграть время и даст возможность решить главную проблему.

Рано или поздно вы поймёте, что данные в вашей базе данных являются узким местом (botleneck).
В базах данных многих приложений важность информации уменьшается со временем. Если вы сможете придумать способ избавиться от этой информации, ваши запросы будут проходить быстрее, время создания бэкапов уменьшится, и вы сэкономите кучу места. Вы можете удалить эту информацию, однако тогда она пропадёт безвозвратно. Вы можете послать множество DELETE запросов, вызвав создание тонн логов, и использовать кучу ресурсов движка базы данных. Так как же мы избавимся от старой информации эффективно, но не потеряв её навсегда?
В примерах мы будем использовать PostgreSQL 9.2 на Engine Yard. Вам также нужен git для установки plsh.

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

• Вы сможете выбрать себе необходимую инфраструктуру. Не нравится Aмазоновский AWS — сможете выбрать другой или даже объединить несколько инфраструктур в одном кластере!
• Сейчас в облаке есть RoR, NodeJS и PHP, но будут добавляться другие.
• PaaS в частном или гибридном облаке!

Четвёртая версия фреймворка Ruby on Rails уже не за горами. Хотя официальной даты релиза еще нет, многие ожидают release candidate уже в начале этого года.
Эта версия фреймворка разрабатывается уже год и представляет из себя множество изменений во внутренней архитектуре. Фреймворк эволюционировал и прибрёл более модульный формат, большинство из нововведений раскидано по отдельным джэмам, для того, чтобы основной код оставался чистым. Таким образом, устаревший функционал можно официально не поддерживать, но использовать, если такая необходимость возникнет.

Во время написания этих строк Engine Yard пока что официально не поддерживает Rails 4 в наших облачных продуктах. Однако, если вы хотите таки их опробовать, вы, конечно, же сможете. Однако будьте внимательны — некоторые возможности, особенно live streaming, скорее всего не будут работать.

Если вы столкнётесь со сложностями при попытке развёртывания приложений на Rails 4, то их нужно регистрировать как feature requests, а не как баг, так как мы ещё не закончили интегрирование Rails 4 в наши продукты.