The redevelopment of metalcon is going on and so far I have been very concerned about performance and webscale. Due to the progress of Martin on his bachlor thesis we did a code review of the code to calculate Generalized Language Models with Kneser Ney Smoothing. Even though his code is a standalone (but very performance sensitive) software I realized that for a Web application writing maintainable code seems to be as important as thinking about scalability.

Scaling vs performance

I am a performance guy. I love algorithms and data structures. When I was 16 years old I already programmed a software that could play chess against you using a high performance programming technique called Bitboards.
But thinking about metalcon I realized that web scale is not so much about performance of single services or parts of the software but rather about the scalability of the entire architecture. After many discussions with colleagues Heinrich Hartmann and me came up with a software architecture from which we believe it will scale for web sites that are supposed to handle several million monthly active users (probably not billions though). After discussing the architecture with my team of developers Patrik wrote a nice blog article about the service oriented data denormalized architecture for scalable web applications (which of course was not invented by Heinrich an me. Patrik found out that it was already described in a WWW publication from 2008).

Anyway this discussion showed me that Scalability is more important than performance! Though I have to say that the stand alone services should also be very performant. if a service can only handle 20 requests per seconds – even if it easily scales horizontally – you will just need too many machines.

Performance vs. Maintainable code

Especially after the code review but also having the currently running metalcon version in mind I came to the conclusion that there is an incredibly high value in maintainable code. The hackers community seems to agree on the fact that maintainability comes over performance (only one of many examples).

At that point I want to recall my initial post on the redesign of metalcon. I had in mind that performace is the same as scaling (which is a wrong assumption) and asked about Ruby on rails vs GWT. I am totally convinced that GWT is much more performant than ruby. But I have seen GWT code and it seems almost impractical to maintain. On the other side from all that I know Ruby on Rails is very easy to maintain but it is less performant. The good thing is it easily scales horizontally so it seems almost like a no brainer to use Ruby on Rails rather than GWT for the front end design and middle layer of metalcon.

Maintainable code vs scalability

Now comes the most interesting fact that I realized. A software architecture scales best if it has a lot of independent services. If services need to interact they should be asynchronous and non blocking. Creating a clear software architecture with clear communication protocols between its parts will do 2 things for you:

  1. It will help you to maintain the code. This will cut down development cost and time. Especially it will be easy to add , remove or exchange functionality from the entire software architecture. The last point is crucial since
  2. Being easily able to exchange parts of the software or single services will help you to scale. Every time you identify the bottleneck you can fix it by exchanging this part of the software to a better performing system.
In order to achieve scalable code one needs to include some middle layer for caching and one needs to abstract certain things. The same stuff is done in order to get maintainable code (often decreasing performance)

Summary

I find this to be very interesting and counter intuitive. One would think that performance is a core element for scalability but I have the strong feeling that writing maintainable code is much more important. So my ranked list of priorities for backend web programming (!) looks like that:

  1. Scalability first: No Maintainable code helps you if the system doesn’t scale and can’t be served to millions of users
  2. Maintainable code: As stated above this should go almost hand in hand with scalability
  3. performance: Of course we can’t have a data base design where queries need seconds or minutes to run. Everthing should happen within a few milliseconds. But if the code can become more maintainable at the cost of another few milliseconds I guess thats a good investment.

If you like this post, you might like these related posts:

  1. Metalcon finally gets a redesign – Thinking about high scalability Finally metalcon.de the social networking site which Jonas, Jens and...
  2. Download Google n gram data set and neo4j source code for storing it In the end of September I discovered an amazing data...

Sharing:

Tags: , , , , , , , , , ,

2 Comments on My ranked list of priorities for Backend Web Programming: Scalability > Maintainable code > performance

  1. Jim says:

    Rails applications that grow beyond the size of a simple blog are an absolute nightmare to maintain. Calling them easily maintainable is far from the truth, imo.

    The big advantage of Rails is getting a prototype developed quickly to prove an idea. After that, it’s useless. Slow, horrible to maintain, difficult to change, and hard to have confidence in unless you have 100% test coverage (which, while not difficult to achieve is difficult to maintain as the application grows).

    Good luck.

    • I am not so sure. If we use rails in the way we want to use it with our service oriented architecture we will not use Active Record. Also we can use Eventmachine to go asynchronous. In this way we can quickly hack some front end that passes requests forward to services. Yes ruby on rails is slow but as I said the middleware can easily scale horizontally by setting up some load balencers or even have the DNS return more than one IP address in order to get more randomization.

      So yes I totally agree that a standard ruby on rails application will be or at least should be a nightmare to scale but I am rather confident that as soon as back end services exist and RoR uses them in the way I just described we should be able to benefit from the fast developing time and easy to read code while not running into scaling issues.

Leave a Reply

*

Close

Subscribe to my newsletter

You don't like mail?