I recently read an interview with Google’s Sean Quinlan about GFS and the problems they faced with interactive Web applications like GMail, which require a certain maximum latency time. The original Google File System design was focused on batch efficiency, not latency. Although the interview is quite long, there are two remarkable paragraphs I would like to quote:
There’s no question that GFS faces many challenges now. For one thing, the awkwardness of supporting an ever-growing fleet of user-facing, latency sensitive applications on top of a system initially designed for batch-system throughput is something that’s obvious to all. [...]
The guys who build Gmail went to a multihomed model, so if one instance of your Gmail account got stuck, you would basically just get moved to another data center. Acutually, that capability was needed anyways just to ensure availability. Still, part of the motivation was that they wanted to hide the GFS problems.
To my surprise, the combination of SOA (Service-oriented Architecture) and Cloud Computing (basically outsourcing the server management/using many virtual machines) was described as something new in IEEE Computer’s October issue (“Software Engineering Meets Services and Cloud Computing”, Stephen S . Yau and Ho G. An, pp. 47 – 53).
Besides the fact, that this is nothing new, but an ongoing trend that started a couple of years ago, there are three observations I’l like to share:
- The authors seem to be at home in the Java world, because XML was mentioned as the only feasible data format for Web services. If you are used to work with PHP and/or JavaScript, you probably prefer JSON over XML, because it’s more lightweight and it is the natural choice for Rich Internet Applications that use a JavaScript frontend. The only real advantage of XML is the possibility to use XSL to transform data. Therefore it sometimes makes sense to use XML for server-to-server communication, but probably not when communicating with mobile or JavaScript clients, that don’t use XSL.
- The list of characteristics of a good service interface does not list API versioning, which is very important for mission critical applications that are mainly based on Web services. Otherwise these applications will break very often.
- Also, the API should be “stateless”, according to the authors. In reality, you want to use some sort of state for sessions (a shared token is common) and for transactions (to bundle a couple of API calls and only permanently store the data, when everything was successful).
An analysis of 32 factors that influence the software development estimation accuracy can be found in Computer’s October issue (Dirk Basten, Ali Sunyaev, pp. 88-90).
In my opinion, these are the most important results:
- Try to exclude candidates with a high general degree of optimism as well as optimism in the estimation process
- Split larger tasks into smaller ones, which can usually be estimated more precisely
- Communicate frequently with the client to obtain direct feedback
- Estimator experience is one of the most important factors in archiving development effort estimation accuracy, although it’s impractical to appoint the highest-qualified estimator on every project
