Before we even get near a terminal, we’re going to want to think about the general architecture of our application and do a fair bit of planning. So put away your PowerBook, find a big whiteboard and some markers, order some pizza, and get your engineers together.
In this article, we’ll look at some general software design principles for web applications and how they apply to real world problems. We’ll also take a look at the design, planning, and management of hardware platforms for web applications and the role they play in the design and development of software. By the end of this article, we should be ready to start getting our environment together and writing some code. But before we get ahead of ourselves, let me tell you a story. . . .
Layered Software Architecture
A good web application should look like a trifle…
A well-layered trifle (photo by minky sue)
Bear with me here, because it gets worse before it gets better. It’s important to note that I mean English trifle and not Canadian - there is only one layer of each kind. This will become clear shortly. If you have no idea what trifle is, then this will still make sense - just remember it’s a dessert with layers.
At the bottom of our trifle, we have the solid layer of sponge. Everything else sits on top of the sponge. It wouldn’t be trifle without it. The sponge supports everything above it and forms the real inner core of the dessert. The sponge is big, solid, and reliable. Everything above it is transient and whimsical.
In web applications, persistent storage is the sponge. The storage might be manifested as files on disk or records in a database, but it represents our most important asset - data. Before we can access, manipulate, or display our data, it has to have a place to reside. The data we store underpins the rest of the application.
Sitting on top of the sponge is the all-important layer of jelly (Jell-O, to our North American readers). While every trifle has the same layer of sponge - an important foundation but essentially the same thing everywhere - the personality of the trifle is defined by the jelly. Users/diners only interact/eat the sponge with the jelly. The jelly is the main distinguishing feature of our trifle’s uniqueness and our sole access to the supporting sponge below. Together with the sponge, the jelly defines all that the trifle really is. Anything we add on top is about interaction and appearance.
Adding the Business Logic
In a web application, the jelly is represented by our business logic. The business logic defines what’s different and unique about our application. The way we access and manipulate data defines the behavior of our system and the rules that govern it. The only way we access our data is through our business logic. If we added nothing but a persistent store and some business logic, we would still have the functioning soul of an application - it’s just that nobody would want to eat/use it. In days of old, business logic was written in C or COBOL (seriously). These days, only the big (where performance really matters) and the entrenched (where it’s too painful to change) do it that way. It’s perfectly acceptable to write business logic in your scripting language of choice (PHP, Perl, Python, Ruby, etc.) or the corporate-friendly alternative of Java.
So we have our supporting sponge and our personality jelly (perhaps with lumps of fruit, which have no sensible analogous component, but are useful ingredients in a trifle, nonetheless). We might have a dessert and we can certainly see the shape it’s taking, but it’s not yet a trifle. What we need now is custard. Custard covers the jelly and acts as the diners’ interface to the layers beyond. The custard doesn’t underpin the system; in fact, it can be swapped out when needed. True story - I once burnt custard horribly (burnt milk is really disgusting) but didn’t realize how vile it was until I’d poured it over the jelly. Big mistake. But I was able to scrape if off and remake it, and the trifle was a success. It’s essentially swappable.
In our web application, the custard represents our page and interaction logic. The jelly of the business logic determines how data is accessed, manipulated, and stored, but doesn’t dictate which bits of data are displayed together, or the process for modifying that data. The page logic performs this duty, telling us what hoops our users will jump through to get stuff done. Our page and interaction logic is swappable, without changing what our application really does. If you build a set of APIs on top of our business logic layer, then it’s perfectly possible to have more than one layer of interaction logic on top of your business logic. The trifle analogy starts to fall down here (which was inevitable at some point), but imagine a trifle with a huge layer of sponge and jelly, on which several different areas have additional layers; the bottom layers can support multiple interactions on top of the immutable bottom foundation.
The keen observer and/or chef will notice that we don’t yet have a full dessert. There’s at least one more layer to go, and two in our analogy. On top of the custard comes the cream. You can’t really have custard without cream; the two just belong together on a trifle. A trifle with just custard would be inaccessible to the casual diner. While the hardened chef/developer would recognize a trifle without cream, it just looks like a mess to the diner/user. We need some way to convey the message of the lower layers to our diners/users.
In our web application, the part of the cream is played by markup on the web, GUI toolkits on the desktop, and XML in our APIs. The markup layer provides a way for people to access the lower layers and gives people the impression of what lies beneath. While it’s true that the cream is not a trifle by itself, or even a very important structural part of a trifle as a whole, it serves a very important purpose: conveying the concept of the trifle to the casual observer. And so our markup is the same - the way we confer the data and the interaction concepts to the user. As a slight detour from our trifle, the browser or other user agent is then represented by the mouth and taste buds of our users - a device at the other end of the equation to turn our layers into meaning for the diner/user.
The Finishing Touches
There’s once thing left to make our trifle complete, other than the crockery (marketing) and diners (users). It would already work as is, containing all the needed parts. A developer might be happy enough to stop here, but the casual user cares more about presentation than perhaps he should. So on the top of our layered masterpiece goes garnish in the form of fruit, sprinkles, or whatever else takes your fancy. The one role this garnish performs, important as it is, is to make the lower layers look nice. Looking nice helps people understand the trifle and makes them more likely to want to eat some (assuming the garnish is well presented - it can also have the opposite effect).
Atop the masterpiece of code and engineering comes our metaphorical garnish - presentation. When talking about web pages, presentation is the domain of some parts of the markup, the CSS, and the graphics (and sometimes the scripty widgets, when they don’t fall into the realm of markup). For API-based applications, this usually falls into the same realm, and for email, it doesn’t necessarily exist (unless you’re sending HTML email, in which case it resembles regular web pages).
So the point of all this? A good web application has many layers, each of which provides a discrete function. All of the layers together make up the application, but randomly combining them will get you a badly built application or a bowl of sugary foodstuffs. From the perspective of the developer/chef, the most important layers are at the bottom because they support and provide the basis for the ones above. From the perspective of the diner/user, the higher layers are the important part that set the dessert apart, with the lower layers being taken for granted, particularly the ones at the very bottom of the stack. And so it should be with web applications.
The Book
This article is an excerpt from Building Scalable Web Sites by Cal Henderson, published by O’Reilly. In the book, Cal talks about how best to tackle each of the stages of development mentioned above, and includes practical advice on the design of software architecture, how to keep your app data clean and secure, planning your hardware needs, scaling development and working with APIs.
Like this article? Digg it!
I think you should concentrate more on building scalable apps than drawing poor parallels with deserts. No digg.
Ahh, yet another coward from digg. No Digg? Really? I didn’t know this was digg.com where you could rate the article. Copy and paste queen with nothing better to do.
Anyway, I think this was a nice analogy to present a web application. I often times represents it two ways: The trinity of the client site and the trinity of the server side. The client site includes the markup, css, and javascript - while the server side includes datastore, programming language, and server software. All of these need to interact in a proper manner to get the job done. There are different approaches that they can be joined together, but they need to be separated as so they can later be updated easily as individual pieces. Switching from Oracle to Postgresql? Switching from ASP to PHP? Switching from Apache to lighttpd? Updating a design and funtionality?
Building a solid application allows these pieces to be updated easily and independent of the other pieces of the application.
Also, that looks like a good dessert!
My web apps are like shepherds pie - cook it for 45 minutes and cover any errors with tons of ketchup :)
Great article. But not even a brief shout-out or apology to Andy Clarke for the trifle comparison?
I’d never seen the Andy Clarke article and I’m not sure which one predates the other (I’ve been using the trifle analogy for a couple of years). I suspect they were arrived at independently :)
Minus the title (which I finally realized came from your book), it’s a nice article. It would have been nicer to see something that dealt more explicitly with scalability (since that’s what I was expecting).
Amidst the many useful articles on this site we find a book promo…
that is one misleading article title, nice analogy though…
Gregg, this isn’t about promoting a book. It’s about giving you good content for free.
I think Cal you could have done better, honestly i enjoyed reading your previous articles but this was just so awful.
Ryan, this response facility isn’t about uncritical feedback. It’s about letting you know what we think. (Isn’t it?)
Gregg clearly doesn’t think this is good content, and I agree with him. The title doesn’t reflect the content, the article itself is based on a weak analogy, and it felt like a book promo to me too.
Take the rough with the smooth - Vitamin has some great content, this just isn’t part of it IMHO.
I have to agree. The article doesn’t give you much guidance to building a scaleable web app other than a shopping list for what tech you sue for which layer, which while useful for someone beginnign a new project, does not really apply to this title.
Cal, you write great sutff, but missed the boat on this one.
I’m sure this piece works great in the context of the book, as a foundation for the further discussion. But I’m afraid I’ll have to agree with the previous speakers. By itself this text isn’t so good, and the title and intro sets the wrong expectations.
Just to make it clear, I’m a fan of Cal’s work and very grateful that he has shared so much of his knowledge of building large scalable web apps. (And I’m a fan of Vitamin and thankful for the work done by all those behind it.)
My bad for using the book title as the article subject - sorry for any wrong expectations it gave you.
interesting read, I am now feeling hungray, I suspect its the lack of breakfast but I now feel like having some triffle.
I might have a look at the book but only if its not full of food references :p
i am feeling hungry just by reading this article, at the middle of the post , i felt the urge to go to the kitchen then i lost the point :)
anyway, you are a very good writer, explaining how websites should work along the MVC pattern :)
but i didn’t see where are the scalability tips as the title said.
Very misleading title. Not very insightful information. I expected better from the thinkvitamin website.
Summary:
Build things in layers, loose coupling, etc, etc.
I think scalability of web apps is something which is very hard to talk about in a general way. What you have mentioned here is very basic and is probably taken care of automatically in something like rails. But when you’re doing something innovative (usually the case with most startups) scalbility is very important but is very particular to your service. Scalability issues for last.fm are vastly different to that of flickr for example. At messagr.com we have to deal with the various contraints put on us in the instant messaging domain. When it comes to scalability, there is no real generic answer other than (as you have mentioned) to plan very carefully before you embark on serious development. I think that it is important to create a rudimentary protoype first without any planning as this really helps highlight issues and gives you a feel for the system you will eventually develop.
[…] When is software architecture like a desert trifle? When it’s end the hands of an imaginative Cal Henderson. […]
Who cares if you promote anything?
I like the desert though, looks promising!
Another sound advice: Don take all too serious! Not every article that people write, can please all! Give all a break, dont whine but dine!
I bought this book and was deeply dissappointed - if I am allowed to cite the last page I read ( which is by far not the last page in the book) - in brackets are my comments :)
“The increased number of machines has additional cost impact beyond the basic cost of hardware and administration time. [wow!] Every box has its own power supply, [aha, thats really a surprise to me - don’t they work without power supply - what is the network cable for? ] which needs to draw a fixed amount of current. [do they really have to do that? I thought the power supply is only responsible for ventilation?]. For a full rack of boxes, this can easily hit a hundred amps, and power is never cheap [thaks god I bought this book !, I wanted to order tommorow 20 Units Dell Racks - but now that I know they need current, and it costs money… I have to reconsider.]
”
So far for the book : I am really amazed Orielly published such a garbage - now I try to sell it in amazon, because really - its not even 5$ worth!
No digg. No buy (book).
We loved the book, it’s one good book in our bible rack. I’d digg it if I knew what that meant.
Architecture…
Programming a computer can be performed in one of numerous languages, ranging from a higher-level language to writing directly in low-level…
[…] Building Scalable Web Apps […]
[…] My little sister’s picture shows up in an article about scalable web apps written by Cal Henderson over a year ago. Coincidence? I think not. […]