Posts Tagged ‘Scalability Blogs and Reviews’

Book Number 2: Scalability Rules

Sunday, August 15th, 2010

Thanks to everyone who has supported The Art of Scalability with purchases, reviews, tweets, posts, and more. Because of the interest shown in this topic of scalability we’ve put our heads together with our publisher, Addison-Wesley, and have come up with an idea that we think is pretty exciting. Fish and I have just signed a contract for our second book with the working title of Scalability Rules. We are looking forward to working with the talented team of editors and reviewers that our publisher has put together.  The book will be a short, technically focused book offering the most common principles we use with our clients to help them scale their hyper growth technology platforms.

We expect the book to come in at about 200 pages and sell for considerably less than The Art of Scalability.  Our intent is to make it useful both as a primer on scalability as well as a reference manual for technical organizations.

We’ll keep you posted on our progress and we’d love to hear your ideas on topics that should be covered. Scalability Rules should be available mid to late 2011.  Now – back to writing our new book!

Scalability Warning Signs

Monday, June 7th, 2010

Unless you’re one of the incredibly lucky sites where the traffic spikes 100x overnight, scalability problems don’t sneak up on you. They give you warning signs that if you are able to recognize and react to appropriately, allow you to stay ahead of the issues. However, we’re often so head down getting the next release out the door that we don’t take the time to realize we’re experiencing warning signs until they become huge problems staring us in the face.  Here are a few of the warnings that we’ve heard teams talk about in the past couple of months that were clearly signs of problems on the horizon.

Not wanting to make changes – If you find yourself denying request for changes to certain parts of your system, this might be a warning sign that you have scalability issues with that component. A completely scalable system has components that can fail without catastrophic impact to customers. If you’re avoiding changes to a component because of the risk of problems this is a warning sign that you need to re-architect to eliminate or at least mitigate the risk.

Performance creep – If after each release you need to add hardware to a subsystem or you accept a performance degradation in a service you could have a scaling issue approaching quickly. Consistently increasing consumption of CPU or memory resources in a service with each release will lead you into an unsustainable situation. If today you’re comfortably sitting at 40% CPU utilization and you allow a modest 10% degradation in each release you have less than nine releases before you are well above 100% but the reality is you won’t get close to that without significant issues.

Investigating larger hardware – If you’ve started asking your vendors or VAR about bigger hardware you’re heading down the path of scalability problems. The scale of more computational resources per dollar is not linear, it’s closer to cubic or even exponential scales. Purchasing more expensive hardware might seem like the economical way out when you compare the cost of the first hardware upgrade versus developer time but run the calculation out several iterations. When you get to a Sun Fire™ E25K Server with Oracle Database 10g at a $6M price tag you might feel differently about the decision.

Asking vendors for advanced features – When you start exploring advanced options of your vendor’s software you’re likely heading down the path of increased complexity and this is a clear warning sign of scalability problems in your future. Besides potentially locking you into a vendor which lowers your negotiating power it puts the fate of your company in someone else’s hands, which wouldn’t make me sleep very well at night. See our post on using vendor features to scale for more information.

Watch out for these or similar warning signs that scalability problems are looming on the horizon. Dealing with the problems today while you have time to plan properly might not get you an award for being a firefighter but you’ll more likely deliver a quality product without costly interruption.

How Do You Use The Art of Scalability?

Friday, May 14th, 2010

We’ve heard some very nice comments about how people have used The Art of Scalability such as to convince their teams on the proper approach to scale their system and to share leadership and management ideas with managers. No one has admitted to using it as a door stop…yet at least. We did have someone tell us that they read a page each night before falling to sleep but they didn’t explain whether that was causal or just correlated.

We thought we’d also share a picture of a well used version of the book.

Tagged copy of The Art of Scalability
One of my favorite comments was from an individual to whom we sent a copy. He responded that he now had two copies on his bookshelf, one active and the other a hot fail over.  We love the comments, please keep them coming.

Using Vendor Features to Scale

Tuesday, December 29th, 2009

If you’ve had the opportunity to participate in an engagement with us you know that we tend to utilize the Socratic method of asking questions. And, it’s not uncommon for us to hear a company explain how they plan to utilizing a particular vendor’s feature to scale. For databases this is often clustering. We believe relying on a vendor to scale violates several of our architectural and scalability principles. Let us explain a couple of our more significant concerns with this practice of relying on a vendor.

First and foremost you should want the fate of your company, your team, and your career in your own hands. Do not look for vendors to relieve you of this burden. As a CTO if the vendor you vetted and selected fails, causing downtime for your business, your are just as responsible as if you had written every line of code. And if it is significant or frequent enough you should expect to be relieved of your position. All code has bugs, even vendor provided code, and personally I would rather have the source code to fix it rather than have to rely on a vendor to find the problem and provide me with a patch. This statement should not be taken to imply that you should do everything yourself such as writing your own database. Use vendors for things that they can do better than you and that are not part of your core competency. See our post on build vs buy for the four question to answer when making this decision.

With scalability, as with many other things in life, simple is better. The more complex you make your system to provide scalability the more you are likely to suffer from availability issues. More complex systems are more difficult and more costly to maintain. Clustering technologies are much more complex than straightforward log shipping for creating read replicas.

One of our beliefs, and should be one of yours also, is that it is most cost effective to be vendor neutral. Locking yourself into a single vendor, whether hardware or software, gives them the upper hand in negotiations. If you don’t think the sales rep knows this, ask yourself why they are willing to throw in some of these features at such an initially steep discount. The reason is that they can make up for it next year when you have to renegotiate.

If these concerns resonate with you, check out our database scalability cube post for ideas on how to design a scaling strategy that you can own, is relatively simple, and is vendor agnostic.

An Offer You Can’t Refuse

Monday, December 14th, 2009

Are you a maven? What’s that you ask? The term maven comes from the Yiddish and Hebrew words that mean someone who has knowledge about something and seeks to pass it along. The term was popularized originally, according to Wikipedia, by a series of television commericals in the 1960′s for Vita Herring. It has resurfaced in popularity due to its use in the book Tipping Point by Malcolm Gladwell, published in 2000. However in the intervening years it has continued to appear in academic research such as Feick and Price’s 1987 article The Market Maven.

The reason we’re asking if you are a maven is that while most book publishers continue to hold onto outdated opinions of influencers we know that you, the technologist, the leader, the influencer, are the one who really matters. Whether you influence people through your blog, twitter account, or position in a company, we want to enlist your help.

Book Cover Final

We wrote The Art of Scalability because we want people to have this information. We spend a lot of time on the road with companies helping them learn how to scale their people, processes, and technology but we obviously can’t be everywhere. We are self-described scalability evangelists and zealots. We want tech teams everywhere to debate architectural principles and all leaders to consider scalability when designing organizations.

Your mission, should you choose to accept it… is to use your network to get the word out about The Art of Scalability, specifically about the concepts covered in the book. In order to help with this we’d like to make an offer. The first 10 people that email me, michael@akfpartners.com,  requesting a copy of the book and committing to spread the word about the book using whatever social network technology you are most comfortable with, we will send you a free copy. Yes, that’s right, a free copy, all for just helping us spread the word about the concepts in The Art of Scalability. If you have a blog, feel free to post a review of the topics; if you use Facebook, post a link along with your thoughts; if you lead a team, have a discussion on the concepts covered. If you already have already purchased a copy of the book, thank you, and feel free to accept this offer to receive one to pass along to someone else.

Check the comments on this post before you email me to see if we’ve reached our goal.

I don’t want to take credit for this idea and while it is said that immitation is a form of flattery I want to give credit. Seth Godin gave away copies of his new book Linchpin, for a $30 donation to the Acumen Fund. Hopefully you took Seth up on his offer and will take me up on this one.