We often talk to clients about the differences between tuning an application or platform and scaling it.  Often the clients intuitively see them as different things, but oddly still refer to them similarly as in “We scaled the database last year by tuning the top SQL queries and getting 20% better performance”.

Tuning is something that you absolutely must do, but we stress that it’s more of an operational endeavor than an architectural endeavor.  In the ideal world, as a typical part of your operation, you would focus some time monthly or quarterly on identifying the slowest portions of your product or the most costly in terms of hardware, engineering time or clock cycles.  These would then be prioritized based on cost to fix and expected return with changes being made to them as engineering allocations allow.  This process is just good housecleaning; throwing out old clothes, and books or getting rid of the motorcycle and lawn mower that no longer work to make room in a garage bay for other “stuff”.

And that’s just what you’re doing with tuning – throwing out old stuff to make room for new stuff.  Just as with the house analogy, you aren’t really making your house “bigger”, you are making the current house capable of holding different and ideally more valuable “stuff”.   If the occupants of your house aren’t growing (i.e. your business isn’t growing quickly), as with a new addition to a family or several new roommates, then this disposition of old less valuable stuff (old code that is seldom executed but costly, often executed code that is very costly) for newer more valuable stuff (new functionality or more efficient code) may be all you ever need to do.

Scaling, however, is an architectural effort that implies significant modifications to your current structure.  In the house analogy, it might mean adding a second floor or expanding the house.  Structurally the house is different and is capable of holding more “stuff” because the total floor space has increased, as compared to the tuning example where you just freed up existing floor space.  Scaling involves architectural effort in redesign of the underlying fundamentals of your system such as adding replicated read databases or splitting databases along data boundaries while tuning is just “spring cleaning” of your platform.

If you are experiencing rapid or hyper growth, you need to both tune your system for the sake of efficiency and performance and scale it for future growth.  Scaling is what allows you to achieve orders of magnitude of improvement (10x, 100x, etc), while tuning should afford linear growth and more efficient operation over time.

In the event that you are reading this via RSS, we updated our site last night with a new look. A couple things are worth mentioning. First is the “All Posts” page. One thing that annoys me about most blogs is the lack of a way to see all the posts on one page. We now have a drop down menu  as well as a link on the right sidebar of the blog for “All Posts”. This page list by topic all of our blog posts. It is a very simple way to find an article or post that you might be interested in.

The second thing is the “Best of Posts” page. I wanted a way for our readers to be able to select what posts they liked the best, as ranked by the number of views, comments, pingbacks (links to the post), etc. The “Best of Posts” page on the right sidebar of the blog is a dynamically generated list of posts that through our readers interaction has ranked them the most popular. If you self-host a WordPress blog and like this idea of a reader selected “best of” list, you can get the plugin here.

As none of us are very good graphic artists we outsourced the design of our new logo. We used 99designs.com to host an auction and thought it was a great experience. You get to establish the price you are willing to pay, provide requirements, and give feedback to designers who submit entries. Our auction ran for 1 week and generated over 200 entries.

If you have any questions or comments about the site feel free to let us know.

If you are like me you probably read hundreds of articles and posts each week. I often come across an interesting article related to scalabiltiy and share it on Twitter. For those of our blog readers who don’t follow us on Twitter I thought I’d share some linksthat I’ve recently posted:

• Project Voldemort Blog: Building a terabyte-scale data cycle at LinkedIn
• Latency is Everywhere and it Costs You Sales – How to Crush it
• Improving performance and scalability with DDD
• Large-scale Graph Computing at Google
• PlentyOfFish Architecture
• InfoQ – Scalability Principles
• Graph Databases and the Future of Large-Scale Knowledge Management
• Google Wave Architecture
• HotPads Shows the True Cost of Hosting on Amazon

If you have any favorite articles you’ve read in the last month share them with us in the comments.

You probably have heard of continuous integration that is the practice of checking code into the source code repository early and often.  The goal of which is to ease the often very painful process of integrating multiple developer’s code after weeks of independent work. If you have never had the pleasure of experiencing this pain, let me give you another example that we have experienced recently. In the process of writing The Art of Scalability, we have seven editors including an acquisition editor, a development editor, and five technical editors who all provide feedback on each chapter. Our job is to take all of this separate input and merge it back into a single document, which at times can be challenging when editors have different opinions for the direction of certain parts of the chapter. The upside of this process is that it does make the manuscript much better for having gone through the process. Luckily software engineering has developed the process of continuous integration designed to reduce wasted engineering effort. In order to make this process the most effective the automation of builds and smoke tests are highly recommended. For more information on continuous integration there are a lot of resources such as books and articles.

The topic of this post is taking continuous integration to an extreme and performing continuous deployment. And it is exactly what it sounds like, all code that is written for an application is immediately deployed into production. If you haven’t heard of this before you’re first thought is probably that this is the ultimate in Cowboy Coding but it is in use by some household technology names like Flickr and IMVU. If you don’t believe this check out code.flickr.com and look at the bottom of the page, last time I checked it said:

Flickr was last deployed 20 hours ago, including 1 change by 1 person.

In the last week there were 34 deploys of 385 changes by 17 people.

Eric Ries, co-founder and former CTO of IMVU, is a huge proponent of continuous deployment as a method of improving software quality due to the  discipline, automation, and rigorous standards that are required in order to accomplish continuous deployment. Other folks at IMVU also seem to be fans of the continuous deployment methodology as well from the post by Timothy Fitz. Eric suggest a 5 step approach for moving to a continuous deployment environment.

1. Continuous Integration – Obviously before moving beyond integration into full deployment, this is a prerequisite that must be in place.
2. Source Code Commit Checks – This feature which is available in almost all modern source code control systems,  allows the process of checking in code to halt if one of the tests fail.
3. Simple Deployment Script – Deployment must be automated and have the ability to rollback, which we wholeheartedly agree with here and here.
4. Real-time altering – Bugs will slip through so you must be monitoring for problems and have the processes in place to react quickly
5. Root Cause Analysis – Eric recommends the Five Why’s approach to find root cause, whatever the approach, finding and fixing the root cause of problems is critical to stop repeating them.

Admittedly, this concept of developers pushing code straight to production scares me quite a bit, since I’ve seen the types of horrific bugs that can make their way into pre-production environments. However, I think Eric and the other continuous deployment proponents are onto something that perhaps the reason so many bugs are found by weeks of testing is a self-fulfilling prophecy. If engineers know their code is moving straight into production upon check in they might be a lot more vigilant about their code, I know I would be. How about you, what do you think about this development model?

Chapters 1 through 10 of The Art of Scalability have been published online at Safari Books Online. The folks at Pearson Publishing (Addison-Wesley and Prentice-Hall) are working on getting chapters 11 through 20 online soon. We just completed editing through chapter 24 of 32 chapters.

We will have one more round of editing before the January, 2010 launch of the book, so it’s not too late for you to sign up for Safari Books Online, review our book and give us your valuable insights!