Engine Yard: Fully-Managed Ruby & Rails Hosting and Deployment

What You Get

24 layers of technology, people, and business advantages.

Diagram #1 shows all 24 separate resources that form an Engine Yard slice^TM. About half the resources are physical things, and half are people/business things.

Your Rails application runs in the Application Servers layer (about 1/3 up from the bottom). That layer is your dedicated application server. It runs up to 4 Mongrels devoted to your application and only your application - no databases, no email sending, nothing else :-).

All of the other very useful resources are included in your slice price, but they are provided by completely separate systems devoted to their respective tasks.

For instance, a very important resource is database access: each slice includes access to MySQL or Postgres servers elsewhere in the cluster. These databases are replicated to avoid data loss, and the contents are backed up to Amazon S3. Additionally, we use acknowledged experts to keep our databases efficient and tuned specifically for Rails apps.

Each slice also includes access to SMTP email servers, SAN storage, SVN version control (with included offsite backups of SVN!), 15 email accounts etc.

All of the layers shown in purple and red are basically things you can touch - actual physical resources that you get with each Engine Yard slice. The other layers represent things that many customers also want to know about... things like good security, solid financials, respected data center, etc.

In the end, most of our customers find the human side of things even more important than technology. They know they've got some of the best Rails deployment people working to support their critical applications.

In designing Engine Yard, we designed a full stack of service and technology to serve our customers around the clock and for years to come.

Whether you deploy with two slices or two dedicated clusters, your business benefits from Engine Yard investments in:

Experience: we've been involved in internet infrastructure since 1998 and in Rails since 2004, with a strong focus on deployment.

Operations Staff: our staff is genuinely concerned about the performance of your Rails applications. Service and performance is our number one priority.

Cluster Technology: our cluster architecture provides high availability and long-term scalability. And the system is constantly being refined in areas that help your business, such as web server performance, database efficiency, and security.

Data Center: Tier 4, class A data center. 24/7 staff and robust infrastructure provide a solid foundation for Engine Yard.

Automated Tools: off-site backups, version control (Subversion), deployment (Capistrano), and database management (Migrations).

More People: access to great Rails people through our relationship with Quality Humans, Inc. QHI provides on-site Rails staff and employees.

Cluster Technology

Our Rails cluster computing platform was designed by our three top architects: Tom, Ezra, and Jayson. This team has over 30 years of practical experience in Internet-focused computer science, from the Linux kernel to networking to Rails deployment to large-scale web scaling.

Each cluster contains fully redundant hardware and software to provide reliability and scalability. Some resources are shared, while others are dedicated to each customer. For instance, everyone benefits from shared load balancers and SAN storage, but each customer has dedicated application servers (shown in Diagram #1 as the shaded cell).

Some customers need complete clusters dedicated to their business applications, or they may need several clusters serving different apps, different markets, etc. They may actually need the computing resources of dedicated clusters, or they may have regulatory requirements that demand dedicated resources for financial and health data.

However, a complete cluster is more than most customers need, especially in the early months or years of their application's life cycle.

Why pay for a whole cluster when 5% is all you need today? This is where slices are incredibly useful...

Cluster Slices

One of the technologies used in our cluster architecture allows us to "slice" the cluster into smaller units that are great for deploying most Rails applications.

Each slice includes a dedicated set of application servers that serve your Rails application. Email, databases, SVN, etc, are all served by other dedicated resources in the cluster. This is possible because each slice includes a segment of total cluster resources, from redundant mail servers to replicated database servers. Diagram #1 shows how this works.

Each slice is created with an average allocation of computing resources that works well for the majority of customers. Over time, we adjust resources as needed.

Here are the average resources allocated solely to the application-serving segment of a single slice (shown in Diagram #1 as the shaded cell):

• 100% utilization of 1 CPU core
• 4 Rails application servers (ie, Mongrels)
• 768 MB RAM

These other resources are allocated at the overall slice level:

• Up to 250 GB/month bandwidth
• Up to 45 GB storage
• Up to 15 email accounts

Slices can be added and removed as your needs change. As you add and remove, resources change linearly.

Minimum 2 Slices for Multi-Server Redundancy
The application server portion of each slice exists on 1 physical server, so at least 2 slices are required to achieve complete hardware redundancy for a given deployment environment.

More on environments below...

Environments

A good web deployment process usually has at least two environments:

• Staging
• Production

Website changes are tested in Staging, and if all goes well, changes are pushed to Production. Public users can see the Production website, but they cannot typically see the Staging website.

This process allows your development team to roll out application features and changes without disrupting live users on your website.

You can define any number of environments to suit your deployment process. You can name them anything you like and you can allocate one or more slices to each environment.

Most customers set up the following 3-slice configuration when they start a new project:

1 slice -> Staging
2 slices -> Production

This provides reasonable resources for their Staging website, and 2X resources plus multi-server redundancy for their public website.

Security

Engine Yard's data center is SAS 70 Type 1 compliant. Additionally, we take several extended security measures outside data center physical access requirements:

• All sysadmins use individually generated public/private key based authentication which are more secure than passwords
• Our network is structured in a way that each slice cannot capture traffic destined for other slices. This is a very substantial security benefit.
• We only allow traffic bound for ports required to run your application to reach your slices.
• Customers have full SSH access to their slices via a non-standard port number. Access is also from an alternate IP and subnet, rather than the site's public IPs.

What You Really Get

On top of the infrastructure, we add the layers that really matter: the people, tools, and flexibility to make enterprise-level Rails application deployment relatively easy.

People: experienced Rails and operations staff to help today, next month, and next year as your applications grow and change direction. We can even provide staff and employees to bolster your Rails team as your organization grows.

Tools: software and services that make deployment easier and more robust, such as hosted, replicated version control (Subversion) and automatic off-site backups of your database and Subversion repository every 24 hours.

Flexibility: customers overwhelmingly want MySQL, but maybe you need Postgres or Oracle. Or maybe you need to run a Java game server as part of your app. Our focus is Rails, but some customers need other technologies, too. We do our best to accommodate your needs.