Shared nothing architecture: A solo performance
As time goes by: Occasionally we dwell into reminiscence of our first web projects some fifteen years ago. In this long bygone era E-Commerce applications sometimes contained SQL statements, which were included in the webpage itself.
There was no separation between the presentation layer and the logic layer of the application. In case you changed the underlying SQL table with an implied change of the SQL query you had to touch not only the database but also the above mentioned presentation layer.
Such interlacing of applications was altogether not really a crispy idea – not even in a time when SQL injection was an unknown term.
Today we rely on the opposite: shared nothing architecture.
|
The main idea is a distributed computing architecture with no application interlacing. Each node (hardware or software component) is self sufficient and redundantly available. There is no single bottleneck that may break the system when failing. On the other side you can scale to near infinity as Google has shown. To make this happen in our case three items stand out: standard hardware, http, and representational state transfer (REST). |
|
To take advantage of simple hardware we sliced the local.ch platform into digestible pieces. For example we set up the local.ch frontend over multiple servers (at latest count over 12) in two data centers. Each server is a standard middle of the road Dell pizza box. We actually only installed this type of server. One down: we simply switch. Heavy workload elsewhere: a simple reconfiguration and the same server is working as load balancer.
The system got way more versatile still when we started to use virtualization (more on this in a next blog post). This plus the use of open source components netted us a dramatic result: throwing small bucks at the problem solves load issues – literally. No haggling with some large account proprietary software vendor, no lengthy hardware delivery times that get you nervous.
A second piece was to take advantage of http. Obvious you say, a website gets called over http. Correct, it simply is a lovable protocol and comes with a bunch of mechanisms that let you take advantage of caching mechanisms, compression, encryption, and authorization. It is easy to understand, robust, tried and tested. And it scales.
The third item is representational state transfer, a method to build web services. Example: The frontend server talks xml with the backend servers over http employing a RESTful method. So long as you don’t change the backend API (resource representation) you can do whatever you want in that backend without breaking the system.
It is of great importance to design and implement these services / resources as small and distinct as reasonably possible. An additional plus is achieved when being able to deploy such services anywhere, i.e. on different machines, different data centers, different countries etc. and still communicate efficiently with each other. At local we had an uptime of over 99.993% with this architecture (that is correct, a downtime of less than 30 minutes over an entire year – one force majeure clause or act of God excluded*).
At Nektoon we do the same thing again with a trick: We outsource the entire hardware platform to Amazon or similar cloud computing services. Our goal: A global and quickly scalable and highly performing platform from day one.
Next in the series how to build a scalable startup: Automation.
_______
*) Yes we admit there was an act of God, a suicidal squirrel more precisely. The incident killed the electricity supply in all of Zurich Nord for a number of hours on 24 August 2008. But then again: The outage was such that the national broadcaster, half Zurich, and countless other sites and services went out of business that day.
Comments
2ni
@ 06.08.2009 10:45 CESTDo you already set up the frontend-backend communication in a way you could easily create an open API "on top" of that somewhen later?
Do you have more insights about the restful service? How small did you cut it, e.g. is it similar to a "flickr api"?
dorian
@ 06.08.2009 17:48 CESTYes we do that. As a matter of fact, Patrice and Marc just commenced work on our API service in the last few days.
The service is quite finely wrought and draws amongst others on inspiration from the Flickr API. For more insights, come over and have a coffee with us.
