The majority of .NET developers are web developers and web development definitely has complexity in terms the required breadth of technologies that a developer needs to master - html, css, javascript, database, and a whole host of other technical jiggery-pokery that needs to be dealt with. However, even though there usually at least three distinct tiers in a typical web application, from a distributed and cross-process perspective, web development is fairly flat and simple. This has an impact of the ability of existing development teams to even grok, never mind deliver upon, the needs of a cloud-based architecture.
Pre-web developers (some of you don’t remember those days, or pulse dialling) had a hard time with their first web development, mainly because of the stateless nature of the web. The client-server developers of the time were used to developing an application where local objects, specific to the current user, session and process could be instantiated and run indefinitely – spinning up threads and generally hanging around waiting for windows events or polling some other process to see if something had changed enough and desired action. Web development, on the other hand, is concerned with getting a request and processing it as fast as possible, in its own little space and spitting out a response – no process hangs around to monitor anything, wait for the next event or anything else. I know I am simplifying here, but other out-of-process things that happen are more scaffolding than core functionality and the biggest out-of-process functionality is the database, which is also the bottleneck (illustrating my point). For some reason (probably simplification) it seems that the linear ‘Wham! Bam! Thank you ma’am!’ approach to processing requests has become more narrow and linear over time and I see a tendency to rip out tiers in favour of request processing ability – some of the biggest websites run on nothing more than a large web farm of vanilla web servers with a database at the back – no middle tier, no messaging and no event response objects.
While web farms may be scaled out, they are not distributed in a sense that they communicate out of process, except with the database. A single client session can be handled by any server for subsequent requests and the state is maintained either by the client or shared, persisted state management – actual object instances relevant to the session do not hang around in process and wait for things to happen (and we don’t want them to either).
The average web application does not care about anything that happens to an object between requests, assuming that the objects can be rehydrated from the session or persisted storage, and is only interested in one event – the request itself.
This understandable and architecturally correct culture is at odds with cloud architectures. The cloud, by definition, is engineered to be distributed and as such is not only concerned with, but specifically addresses, the age-old concerns in distributed computing – latency, cross process object instances, partial failure, recovery and others. The software development skills to deal with this are virtually non-existent in modern development teams because of the nature of web development. Think for a moment about your current solution, the following points are clues that your solution is not very concerned with the same issues that a cloud-based solution would be:
- When did you last write multi-threaded code with event response methods, thread safety and race conditions
- When did you last update an object (or even a row in a database) and write code to check that it hadn’t been altered by another process in the meantime?
- Does your application save objects in an intermediate state (say pending order) and then not care about them any more (a separate order fulfilment module is responsible to getting them to the next state)?
- Do you have code in your web application that could get a response produced quicker if a slow process was handled by a completely different processor? For example, do you persist to the database in the request processing thread instead of pushing it out of process?
- If you get a timeout or error when processing a request, is the problem of trying again dumped on the user, or do you take corrective action on the fly?
- Could you quickly come up with a solution to implement a roll-your-own distributed cache across the servers on your web tier?
- How much non-database transaction code do you have?
Cloud solutions are dependent on messaging, background processes, workflow, long-running transactions and ‘Apology Based Processing’. These tools, techniques and patterns are virtually non-existent and mass knowledge about them has fallen away since the seventies, when people had to write their own cross-process protocols (and no, I don’t remember that but I did colour in punch cards with crayons). I am concerned that we make the promise about being able to deliver on the cloud and, due to the lack of skills in the teams tasked with delivery, we simply don’t have the necessary basics. These skills go beyond the technical usage of the tools and frameworks and extends to the ability of our architects and solution designers to understand the problem and come up with practical, implementable designs. Recently I did some messaging based work myself and definitely remember a point where I went all cross-eyed with the sequence, rate of delivery and failure conditions of messages being pushed around – never mind trying to debug cross-process, multi-threaded and message-based code.
I imagine that the solution is to build up the skills in three ways.
- The first, and obvious one, is to try and get developers interested in the cloud paradigm and the problems encountered.
- The second, is to start bringing those tools and techniques into mainstream web development, where they are needed – just not badly enough. The Microsoft stack has a lot of these components already in place such Workflow Foundation (WF) and Windows Communication Foundation (WCF) messaging – both of which have a place in any modern web development solution. Also, the increasing adoption of client scripting and ajax necessitates more thinking about cross-process objects.
- Lastly, web developers should hang out more with colleagues that do integration. Although often derided, it is the Biztalk, database and Integration Services people that have to think about these sorts of things every day. Consider, for a moment, why your abandoned baskets need to be cleaned up by a database script – then go and ask someone.
So, maybe as you tinker with your next proposed solution you can digress for a while and try and put some distributed processing mastery in there somewhere.
Simon Munro @simonmunro
PS: Over the last few days a series of events took place that resulted in some lurkers (people who read my posts without commenting) providing some support and a ‘Thank You’ goes to those that declared that they would miss my posts. It takes a lot of energy to produce original content every single week as I have done for the last few months and it is good to know that some people find some value in it.