Pragmatic Dictator

Patrick and Fuzzy jumped on something from Mark Baker about Apollo and whether or not it’s built on top of the web.

Mark’s argument essentially amounts to “make it work in the existing browser” as opposed to “extend beyond the browser”. There’s a fine dividing line here because the current environment provided by the browser is limited.

There are a multitude of ways to deal with the fact that browsers don’t support local file access etc. One might be to properly “web-enable” the local computer’s operating system having it provide access to resources etc via 127.0.0.1 in a browser friendly fashion.

Another would be something like Apollo or Java or …..

More interesting for me is that whilst the web is supposed to be this de-centralized thing (and it is indeed in terms of services and combining them together) we’re not really de-centralizing the implementation of individual services such that we are able to push substantial logic into the client-side.

The current model, as I’ve said before, can make maintenance of services easier because new code for the browser is but a page refresh away. I think we could maintain a good deal of this constraint whilst getting closer to something like Apollo.

[ And how Jini like is the web-deployment model? Seems very similar - push the impl to the client just when it needs it. ]

So maybe Apollo isn’t the solution, maybe the existing browser isn’t the solution, maybe we need to consider the browser to be a work in progress, in need of extension so we can build better “on top of the web”.

Who knows?

Why do we want this kind of logic in the client anyway? Well because whilst statelessness is great and all, the reality is that if the state is not held inside of a human being’s head, it’s going to be in the browser and manipulating that state in efficient fashions (not pushing it all back to the server in every call) dictates a fair amount of client-side intelligence. We might also want to batch things up and so on for the purposes of making better use of the network. Lastly we might want enhanced user-interaction but eye-candy is sweet, you can never get enough and your browser could end up obese.

[For more on state in web apps, see Dave Orchard's note]

Technorati Tags: architecture, browser, distributed systems, web

Manny is by his own admission a “pretty pictures guy” hence his interest in web clients, Ajax, REST etc.

His first posting covers the basics of the Betfair business model which will set the scene for future tech postings and discussion of the brutal challenges Betfair faces (expect to see some serious performance numbers).

Technorati Tags: betfair, blogger, technology

Normally we class availability as a non-functional requirement of the systems we build but I’m starting to think that’s a mistake because often when we get to project scheduling it’s forgotten. We allocate time, budget and resource to make sure we’re feature complete, that this button or that tick box is visible or that we can gather credit card details but rarely do we treat availability similarly.

Unlike a functional requirement which has some form of physical manifestation availability tends to be invisible dotted around the system in all sorts of different places from architecture and code to hardware. In contrast real features are a logical sequence of inter-linked pieces of code and design that are naturally traceable from entry to exit point. No entry point means the feature is not complete and this can be trivially determined prior to deployment. The first time we know availability isn’t “feature complete” is when our deployed website is down.

Worse, with every single feature or subsystem we add and the corresponding increase in load and size of dependency graph there’s an increased chance that we compromise availability. This can make for some serious growing pains where we add more features, attract more customers and thus more load all the time paying no attention to availability until it’s too late.

Consider the wiring in a house, we add a garage which needs lighting, maybe heating and a motor-powered door. Then we build an extension for guests, more lighting, heating and wall sockets. Eventually, something gives, maybe it’s a piece of wiring that should’ve been replaced or a bad junction but the net effect is to risk burning out all the wiring in the house. Replacing all the wiring would’ve been hard enough without the extensions but now the house is twice as big and the wiring is four times more complex. Worse, we cannot do a piecemeal upgrade instead we must replace all the wiring at once and until it’s done we can’t have all the heating on or we can’t cook at the same time as using the garage.

Like the wiring, availability needs constant and sometimes significant attention and putting the work off can lead to significant cost down the line. Similar arguments apply to other non-functional aspects of our systems such as scalability (it’s no good adding features that attract more customers if the system won’t cope with the additional load).

In light of the above, I believe it might be better to classify availability as a feature if not the feature. After all if the system is not available, none of the cool features we’ve implemented are worth anything because they can’t be accessed. It might also be a catalyst for discussion (especially amongst non-technical staff) of availability’s costs and benefits as compared to those of other features leading to improved strategic thinking.

Relevant Links:

• Vogels on Scalability
• SD Forum 2006 – The eBay architecture
• Inside MySpace.com
• Vogels – E-Commerce at Interplanetary Scale
• A Conversation With Werner Vogels

Technorati Tags: architecture, distributed systems, availability, web

Observations on the long running “browser as a platform” debate.

We often talk about browser-based apps but really what we’re talking about (at least for now) is browser-accessed apps (web apps). This is because the browser doesn’t really house much app logic – it mostly does the presentation and bundles up data for processing by remote logic. AJAX has made it easier to do this in more user-friendly/intuitive ways but the computational load and location of logic is clearly at the back-end.

The browser is a powerful force in that it’s pretty much on every desktop. It’s become part of a computer’s DNA. Delivery of an “app” via the browser means it can permeate to virtually all desktops and is endowed with the appearance of “zero install time”. Of course, we forget about the time spent downloading and installing browser upgrades and plugins because it’s been made “low-pain”.

It’s widely held that the bulk of innovation goes on in the browser but that’s at least in part inaccurate – the innovation is in the apps themselves which typically exploit the increasing level of networked’ness that is a hallmark of today.

The current divide of web app logic between browser and web back-end has another benefit. Essentially it endows the app builder with the ability to choose their deployment platform. The front-end (browser) has a limited but well understood set of presentation technologies (HTML, JavaScript etc) that the back-end must deliver against but one can use pretty much any back-end technology to generate the content to be consumed by the front-end. Thus the app builder can select their preferred webserver, libraries, languages etc for the task knowing that it has almost zero effect and dependency on the front-end. However, note there is some pain out there caused by variations in browser behaviour which mimics the kinds of trouble desktop-based apps face daily.

The nature of networking (bandwidth constraints and latency) exerts some force on the architecture of web apps which means we must use single bulk refresh to do the work rather than lots of querying. And bulk refresh is slow, AJAX helps here because we can hide that bulk update in the background to some extent but there’s a computational penalty in the form of polling.

One thing web apps aren’t so good at right now is exploiting the typically huge number of spare CPU cycles available at the client-side. All the load is in the data-centres and networks, a classic centralized architecture with all the usual scaling issues. Perhaps the most significant aspect though is how un-green this is. Surely there’s some sense in utilizing that client CPU for more than just presentation logic?

Expanding use of client-side compute power beyond presentation will begin to change the architecture of the typical web-app. For it to work we’ll need to do more serious app logic client-side which might take us back to longer downloads of that logic and threaten the “zero cost of install” perception. It’s also possible that browsers will need to support more sophisticated programming languages. The browser as a platform could become more difficult of a concept to execute well because we will encounter challenges such as providing consistent API behaviour across filesystems etc. We’ve seen these kinds of problems played out previously – Java anyone? One possible way around the API issue might be to adopt a more abstract approach such as having the browser provide all this stuff via a REST-based web interface available to in-browser app logic.

In complete contrast to the web app is the desktop app where rather than do almost all work in the back-end on the net somewhere we do it all in the front-end which limits computation and storage to what’s “near” (on or accessed via networks local to) the desktop machine.

Likely as not the ultimate solution is a hybrid of web and desktop app – seamless integration into the browser with sufficient client-side desktop API access to make genuine client-side processing easier whilst accessing network resources like servers and storage so users can “break out” from the limits of their own machine. The trick will be in defining a workable limit to browser APIs and programming languages which balances the need to avoid the cross platform consistency issues against sufficient functionality to make client-side apps appropriately powerful.

Technorati Tags: architecture, distributed systems, web