Enterprise Rails

Chapter 1. The Big Picture

What Is Enterprise?

You may have heard that big Internet sites like Amazon, eBay, or Google have thousands—sometimes tens of thousands, or more—of servers powering their websites. If you’re reading this book, you’ve probably already built at least one web application of your own, and it probably had only a handful of machines behind it, perhaps even just one application server and one database. In fact, maybe you had shared hosting and only had a fraction of a full server at your disposal.

If you had a great idea for an online business and were given 1,000 servers, what would you do with them? How would you make the most of them? What operational goals would you define for reliability and speed, and how would you leverage all of that hardware to achieve those goals?

Before diving into the pieces of an enterprise system, or discussing how to build one, a good starting point is to simply define enterprise.

Unfortunately, that is not an easy task. There is no particular set of tools that, if used, will make your architecture qualify as enterprise, even if the word “enterprise” is in the product names of the tools you use. The big companies mentioned earlier have built many of their own tools to support their software stack, but they are definitely still “enterprise.” Similarly, there is no single configuration of pieces that together spell enterprise. If you looked at the configuration of Google’s servers and compared their it to Amazon’s, the two would look quite different. But they are both enterprises nonetheless—it just happens that the two enterprises have different goals, and therefore need different architectures to reach those goals.

In some sense, a site is enterprise when it feels like it is. All of the Internet behemoths once started out with a single application server and single database, just like you. It’s anyone’s best guess when they crossed the blurry line into “enterprise.”

That said, there are certainly some criteria that, when satisfied, do make a site feel like it’s enterprise. These criteria are topics of this book, and will be referred to again and again:

• It’s fast. You can define a service level agreement (SLA) for how long it takes each component to do its job, which in turn allows you to define an SLA for end-to-end load times of any given web page.

• It’s always available. You can define an SLA for your minimum uptimes for all critical components and aim for “four nines”—99.99% uptime.

• It scales linearly. You can scale to hundreds of thousands or even millions of users by adding additional hardware.

• It’s fault-tolerant. If noncritical components go down, the majority of functionality stays intact, and your users don’t know the difference.

There are other criteria that make your site feel like it’s enterprise, too, although they are mainly operational concerns, and aren’t covered in depth this book:

• All source code is in a source control repository.

• All new code goes through a QA cycle before it is deployed.

• There is a deployment procedure, and failed deployments can be rolled back.

• Errors are logged in a central location, and the appropriate personnel are notified in real-time.

• Logfiles and databases are backed up in a central location.

• Statistics about the website’s operation can be collected and analyzed to determine which areas need attention.

Implicit in the preceding list is a number of job functions and departments other than software development. Reading between the lines, you find:

• A database administrator (DBA) who sets up failover databases and ensures backups are available. A DBA can also tune database configuration parameters and control the physical mapping of data to disks to improve performance. Many also consult on schema design to ensure optimal performance and data integrity.

• A quality assurance engineer (QA) who tests release candidates before they are put into production and tracks issues to be fixed by developers.

• An operations or release engineer who manages the releases, creates deployment plans, and rolls out your new software in the wee hours of the night.

• An information technology engineer (IT) who maintains internal machines that house backups, logfiles, etc.

Having these people in your organization will push your systems architecture toward “enterprise.” Similarly, designing your system to be enterprise creates the need for all of these individuals. In some sense, when your company itself feels like an enterprise, your software is probably getting to be enterprise, too. When the two are out of step, you will know it because either half of the engineers will have nothing to do or everyone will be stepping on each other’s toes.