Archive for January, 2009

Open Storage Summit Keynote

Friday, January 30th, 2009

Here is the video of the keynote speaker, Ben Rockwood of Joyent, talking about “Storage in the Cloud” at the OpenSolaris Storage Summit on Sept 21, 2008.  Warning it is a pretty long video but worth checking out.

http://blogs.sun.com/video/entry/open_storage_summit_ben_rockwood

A couple items in the video resonated with us.

The first was ~8min in he tells of how they found that PayPal was using their cloud for quick development.  This is very much in line with our recommendations on the use of the cloud for enterprise class applications http://venturebeat.com/2008/10/13/the-cloud-isnt-for-everyone/

The second comment was ~12min in where he talks about how flaky customers can be and that you only get on shot with most of them. We completely agree with this and your architecture must scale on demand or you might lose customers permanently.

Coming soon to a book store near you!

Tuesday, January 27th, 2009

 

Well it’s not actually coming soon but it is in the works.  We’re very excited that we’ve just signed a book deal with Prentice-Hall for a book covering all aspects of scalability.  The working title is The Art of Scalability – Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise.  Prentice-Hall is a Pearson Education company and the nation’s leading educational publisher.  Together with another Pearson company, Addison-Wesley, they have published some of the classics including The Art of Computer Programming, The C Programming Language, The C++ Programming Language, The Mythical Man-Month, and Design Patterns.  We are very pleased to be working with this excellent team.  

We have been considering putting together a book for some time and even started the process over a year ago but things got very busy and we put the idea on the backburner.  Having written dozens of articles over the past year we decided it was time to revitalize the idea.  We were fortunate enough to get the attention of couple publishers and ultimately it worked out for us to partner with Prentice-Hall on this project.  

We know there are other scalability books out there but none of them deal with the entirety of the problem.  If you are familiar with our methodology you already know that we think scaling a service or application is dependent on much more than just technology.  We approach scalability from three perspectives and as with the over used stool analogy, if one of the three legs is missing or defective the stool isn’t stable and neither is the application.  The three must have “legs” for scalability are people, process, and technology.  The Art of Scalability will teach engineers, architects, managers, and executives how to solve technology scalability problems through changes in their architecture, processes, and organization structure.

One of the very neat things that Prentice-Hall has setup is an online review system that allows anyone interested to get a sneak preview of the book as it is being written and it allows anyone interested in acting as part of our editorial staff to provide feedback before the book is published.   We’ll give you more information about this process as we get started.  We also plan to use our forum and this blog to keep everyone updated on our progress, so check back often or subscribe to it through your RSS reader.

The Purpose of QA

Sunday, January 18th, 2009

 

What is the purpose of functional testing, regression testing, load and performance testing, stress testing, and any other type of testing done at the end of the product development life cycle?  If you said something like, “to improve the quality of your product”, keep reading.  You cannot QA quality into your product.  The quality of your product or service is determined to a large degree long before any test is performed.  The reason for this is that QA’s purpose is not to ensure quality but rather to check if all the other quality affecters have been included, providing a warning if they have not been.

 

We would put forth an argument that feature prioritization and resource allocation is the very first step in determining the quality of your product.  Mess this up and you are building your product on a shaky foundation.  Ensuring that the product team has clear guidance on business priorities and that these do not change every week sets the ground work for a high quality product.  Changing direction is intensely distracting for the entire organization and should only be done when there is a clear business necessity.  A litmus test is that if a change in direction happens more than once per quarter there is a problem.  

The next crucial step in ensuring high quality is a set of well defined requirements that include the purpose, expected benefits, user functionality, and methods of verification.  Depending on the development methodology this set can be developed all at once or incrementally. 

Of course engineering has the largest and most direct role in determining the quality of the product.  A professional engineering shop that can continuously deliver high quality features are usually places that are a joy to work in and make everyone better for being part of the team.  Some things that a team such as this are likely to have in place are mentoring programs, coding standards, unit tests, logging framework, and even documentation requirements.    

Don’t make the mistake that so many technology executives do and either blame QA for poor quality or think that by dedicating more time or resources to QA your quality will improve.  Do this and you will likely get more warning signs such as more bugs but you will not improve the overall quality of the product.  For that you must look further back in the product development life cycle.

New Year’s Tech Resolutions

Friday, January 2nd, 2009

 

In the spirit of the New Year, we thought we would share our list of top things that you should consider putting on your technology’s roadmap for 2009.   

  1. Develop the ability to rollback: If you can make only one change to your product and process in 2009 and you don’t currently have the ability to rollback, this should be at the top of your list.  Being able to push code changes and then pull them back from production in the event of a problem will save you more customers and more effort than any other single item.
  2. Break changes into smaller pieces: There is almost never a need to redesign the entire site or service at once.  Break it into parts and take it one piece at a time.  This will be lower risk and give you an opportunity to learn along the way.
  3. Remove SPOFs:  Commit to removing all single points of failure in your architecture.  Single servers, firewalls, load balancers, power supplies, etc should all be listed and tackled one at a time until they are all eliminated
  4. Remove synchronous calls:  Having one service call another service in a synchronous manner causes a multiplicative effect of failure.  Five synchronous calls on servers with five 9’s availability (99.999% uptime) leads to a maximum of 99.995% for the system.  Eliminate synchronous calls wherever possible and create fault-isolative architectures to help you identify problems quickly.
  5. Incent a culture of excellence:  Hire the right people and hold them to high standards. Set aggressive yet achievable goals and motivate them with your vision. Be a leader.  
  6. Develop a disaster recovery plan: Disasters happen, no one expects an entire data center to be down but things like that happen.  Plan on it and start making changes today to keep your services up and running in the event of a disaster.
  7. Develop quality into the product from the start:  Don’t expect QA to ensure quality is built into the product.  We’ll post more about this in the New Year but quality starts much, much earlier in the product development life cycle.
  8. Split your application or database:  Start this year thinking about how to split your application and database.   We recommend our cube model for both because working on all three axes gives you unlimited scalability in both your app and database.
  9. Start Logging:  As we discussed in a recent post, start logging your application data but follow our three key guidelines – 1) logging must not impede the performance of the application 2) use a common framework and 3) look at the data
  10. Celebrate your success:  Take time now and throughout the year to look back and congratulate your team and yourself.  If you want to foster creativity on your team, celebrating victories is a great way to keep the energy up on your team.  If you are getting ready to present your 2009 goals to your team, we recommend that you start by focusing on the amazing accomplishments that you have had in 2008.

Wishing you and your teams a great New Year!   

 

-The AKF Team