Saturday, December 31, 2011
Friday, December 23, 2011
Sunday, November 20, 2011
Thursday, November 03, 2011
Friday, October 28, 2011
This year was a mix too, with the main theme of cloud. (Though it turned out that cloud wasn't that prevalent). I think the best way to summarise the workshop would be concentrating on high performance and large scale (up as well as out). With talks from the likes of Amazon, Facebook and Microsoft we covered the gamut of incredibly large numbers of users (700 million) through eventual consistency (which we learnt may eventually not be enough!)
Now it's important to realise that you never go to HPTS just for the talks. The people are more than 50% of the equation for this event and it was good to see a lot of mixing and mingling. We had a lot of students here this time, so if past events are anything to go by I am sure we will see the influence of HPTS on their future work. And I suppose that just leaves me to upload the various presentations to the web site!
Thursday, October 13, 2011
Sunday, October 09, 2011
Thursday, October 06, 2011
Sunday, September 11, 2011
But they all pale into insignificance when I look at my 9 year old son! And then there's nothing more I can really say except thanks.
Sunday, September 04, 2011
Monday, August 29, 2011
Sunday, August 21, 2011
Today we live in a world of instant publishing and less and less peer review. It's also unfortunate that despite the fact more and more papers, article and journals are online, it seems that less and less people are spending the time to research things and read up on state of the art, even if that art was produced decades earlier. I'm not sure if this is because people simply don't have time, simply don't care, don't understand what others have written, or something else entirely.
You might ask what it is that has prompted me to write this entry? Well on this particular occasion it's people using the term 'fault tolerance' in places where it may be accurate when considering the meaning of the words in the English language, but not when looking at the scientific meaning, which is often very different. For instance, let's look at one scientific definition of the term (software) 'fault tolerance'.
"Fault tolerance is intended to preserve the delivery of correct service in the presence of active faults. It is generally implemented by error detection and subsequent system recovery.
Error detection originates an error signal or message within the system. An error that is present but not detected is a latent error. There exist two classes of error detection techniques: (a) concurrent error detection, which takes place during service delivery; and (b) preemptive error detection, which takes place while service delivery is suspended; it checks the system for latent errors and dormant faults.
Recovery transforms a system state that contains one or more errors and (possibly) faults into a state without detected errors and faults that can be activated again. Recovery consists of error handling and fault handling. Error handling eliminates errors from the system state. It may take two forms: (a) rollback, where the state transformation consists of returning the system back to a saved state that existed prior to error detection; that saved state is a checkpoint, (b) rollforward, where the state without detected errors is a new state."
There's a lot in this relatively simple definition. For a start, it's clear that recovery is an inherent part, and that includes error handling as well as fault handling, neither of which are trivial to accomplish, especially when you are dealing with state. Even error detection can seem easy to solve if you don't understand the concepts. Over the past 4+ decades all of this and more has driven the development of protocols behind transaction processing, failure suspectors, strong and weak replication protocols, etc.
So it's both annoying and frustrating to see people talking about fault tolerance as if it's as easy to accomplish as, say, throwing a few extra servers at the problem or restarting a process if it fails. Annoying in that there are sufficient freely available texts out there to cover all of the details. Frustrating in that the users of implementations based on these assumptions are not aware of the problems that will occur when failures happen. As with those situations I've come across over the years where people don't believe they need transactions, the fact that failures are not frequent tends to lull you into a false sense of security!
Now before anyone suggests that this is me being a luddite, I should point out that I'm a scientist and I recognise fully that theories and practices in many areas of science, e.g., physics, are developed based on observations and can change when they prove to not be sufficient to describe the things you see. So for instance, unlike those who in Galileo's time continued to believe the Earth was the centre of the Universe despite a lot of data to the contrary, I accept that theories, rules and laws laid down decades ago may have to be changed today. The problem I have in this case though, is that nothing I have seen or heard in the area of 'fault tolerance' gives me an indication that this is the situation currently!
Tuesday, August 09, 2011
As a researcher, you're expected to question the work of others who may have been in the field for decades, published dozens of papers and be recognised experts in their fields. You don't take anything at face value. And I believe that that is also a quality really good engineers need to have too. You can be a kick-ass developer, producing the most efficient bubble-sort implementation available, but if it's a solution to the wrong problem it's really no good to me! I call this The Emperor's New Clothes syndrome: if he's naked then say so; don't just go with the flow because your peers do.
Now as I said, I've had the pleasure to work with many great engineers (and engineering managers) over the years, and this quality, let's call it "thinking and challenging" is common to them all. It's also something I try to foster in the teams that work for me directly or indirectly. And although I've implicitly been talking about software engineering, I suspect the same is true in other disciplines.
I've heard a few things about the new film and they can all me summarised as saying that it was a more faithful telling of the story than the John Wayne version. After watching both, and reading the book, I have to wonder if those reviewers knew WTF they were on about! Yes the new film is good, but it's no where near as good as the original. And as for faithfulness to the book? Well with the exception of the ending, the original film is far closer to the book (typically word for word). While watching the remake I kept asking myself time and again why had they changed this or that, or why had they completely rewritten the story in parts?!
If you have a great novel that you know works well on screen, why do script writers seem incapable of leaving it untouched? Maybe they decided that they had to make the new film different enough from the original so people wouldn't think it was a scene-for-scene copy. But in that case, why remake it in the first place? FFS people: if an original film is good enough, leave it alone and learn to produce some original content for once! And for those of you interested in seeing the definitive film adaptation of the book, check out the John Wayne version.
Friday, July 29, 2011
Unfortunately this time I brought my iPad and iPhone, both of which I connected to the wifi. Checking email was too easy and as a result I was working every day! Fortunately it only took me about 4 days to realise this (with some not-so-subtle hints from family) and I disabled wifi. This means I can now get on with the holiday. Since we are out in the middle of nowhere this means sitting by the pool reading a book on my (wifi disabled) iPad, or fishing!
But recently I've started to see more and more adverts substituting the good old vendor URL for a Facebook version, e.g., moving from www.mycompany.com to www.Facebook.com/mycompany. Now at first this might seem fairly innocuous, but when you dig deeper it's anything but! As I think Tim Berners-Lee has stated elsewhere, and I'm sure Google has too, the data that Facebook is maintaining isn't open for a start, making it harder to search outside of their sub-web. And of course this is like a data cloud in some ways: you're offshoring bits of your data to someone else, so you'd better trust them!
I don't want to pick on any single vendor, so let's stop naming at this point. Even if you can look beyond the lack of openness and the fact that you're basically putting a single vendor in charge of this intra-web, what about all of the nice things that we take for granted from http and REST? Things such as cacheing, intelligent redirects and HATEOAS. Can we be sure that these are implemented and managed correctly on behalf of everyone?
And what's to say that at some point this vendor may decide that Internet protocols are just not good enough or that browsers aren't the right view on to the data? Before you know it we would have a multiverse of Webs, each with their own protocols and UIs. Interactions between them would be difficult if not impossible.
Now of course this is a worst case scenario and I have no idea if any vendors today have plans like this. I'd be surprised if they hadn't been discussed though! So what does this mean for this apparent new attitude to hosting "off the web" and on the "social web"? Well for a start I think that people need to remember that despite how big any one social network may be, there are orders of magnitude more people being "anti-social" and running on the web.
I'm sure that each company that makes the move into social does so on the back of sound marketing research. Unfortunately the people making these decisions aren't necessarily the ones who understand what makes the web work, yet they are precisely the people who need it to work! I really hope that this isn't a slippery slope towards that scenario I outlined. Everyone on the web, both social and anti-social, would lose out in the end! Someone once said that "just because you can do something doesn't mean you should do something."
Thursday, July 21, 2011
Tuesday, July 19, 2011
Monday, July 18, 2011
Thursday, July 07, 2011
Sunday, June 26, 2011
Saturday, June 18, 2011
Sunday, June 12, 2011
Saturday, June 11, 2011
Sunday, June 05, 2011
One of the early pieces of research I did was on combining replication and transactions to create consistency domains, where a large number of replicas are split into domains and each domain (replica group) has a relationship with the others in terms of their state and level of consistency. Rather than try to maintain strong consistency between all of the replicas, which incurs overhead proportional to the number of replicas as well as their physical locality, we keep the number of replicas per domain small (and hopefully related) and grow the number of domains if necessary. Then each domain has a degrees of inconsistency with others in the environment.
The basic idea behind the model is that of eventual consistency: in a quiescent period all of the domains would have the same state, but during active periods there is no notion of global/strong consistency. The protocol ensures that state changes flow between domains at a predefined rate (using transactions). A client of the inconsistent replica group can enquire of a domain the state at any time, but may not get the global state, since not all updates will have propagated. Alternatively a client can request the global state but may not know the time it will take to be returned.
If you know Heisenbergs Uncertainty Principle then you'll know that it means you cannot determine the momentum and position of a particle at the same time (or other related properties). Thus it was fairly natural for me to use this analogy when describing the above protocol: an observer cannot know the global state of the system and when that will be the steady state at the same moment, i.e., it's one or the other. It's not a perfect analogy, but in a time when others seemed to like to bring physics into computing it seemed appropriate.
Now of course the original work was before the CAP theorem was formalised. So today we see people referring to that whenever they need to talk about relaxing consistency. And of course that is the right thing to do; if I were reviewing a paper today that was about relaxing consistency and the authors didn't reference CAP then I'd either reject it or have a few stern words to say to them. But I still thing Heisenberg is a way cooler analogy to make. However, I do admit to being slightly biased!
Friday, June 03, 2011
Thursday, June 02, 2011
Friday, May 27, 2011
Call for Papers: The International Workshop on Clouds for Enterprises (C4E) 2011
held at the 13th IEEE Conference on Commerce and Enterprise Computing (CEC'11, http://www.tudor.lu/cec2011)
on Monday, 5 September 2011 in Luxembourg, Luxembourg
Paper submission: Monday, 20 June 2011 (strict, except for re-submission of papers reviewed by CEC'11)
Notification of acceptance: Monday, 4 July 2011
Cloud computing is an increasingly popular computing paradigm that aims to streamline the on-demand provisioning of software (SaaS), platform (PaaS), infrastructure (IaaS), and data (DaaS) as services. Deploying applications on a cloud can help to achieve scalability, improve flexibility of computing infrastructure , and reduce total cost of ownership. However, a variety of challenges arise when deploying and operating applications and services in complex and dynamic cloud-based environments, which are frequent in enterprises and governments.
Due to the security and privacy concerns with public cloud offerings (which first attracted widespread attention), it seems likely that many enterprises and governments will choose hybrid cloud, community cloud, and (particularly in the near future) private cloud solutions. Multi-tier infrastructures like these not only promise vast opportunities for future business models and new types of integrated business services, but also pose severe technical and organizational problems.
The goal of this workshop is to bring together academic, industrial, and government researchers (from different disciplines), developers, and IT managers interested in cloud computing technologies and/or their consumer-side/provider-side use in enterprises and governments. Through paper presentations and discussions, this workshop will contribute to the inter-disciplinary and multi-perspective exchange of knowledge and ideas, dissemination of results about completed and on-going research projects, as well as identification and analysis of open cloud research and adoption/exploitation issues.
This workshop invites contributions from both technical (e.g., architecture-related) and business perspectives (with governance issues spanning both perspectives). The topics of interest include, but are not limited to:
- Patterns and best practices in development for cloud-based applications
- Deployment and configuration of cloud services
- Migration of legacy applications to clouds
- Hybrid and multi-tier cloud architectures
- Architectural support for enhancing cloud computing interoperability and portability
- Architectural principles and approaches to cloud computing
- Cloud architectures for adaptivity or robustness
- Evaluation methods for cloud architectures
- Architectural support for dynamic resource management to support computing needs of cloud services
- Cloud architectures of emerging applications, such as mashup of enterprise/government services
- Impact of cloud computing on architecture of software and, more generally, IT systems
Enterprise/Government Application Perspective:
- Case studies and experience reports in development of cloud-based systems in enterprises and governments
- Analyses of cloud initiatives of different governments
- Business aspects of cloud service markets
- Technical and business support for various cloud service market roles, such as brokers, integrators, and certification authorities
- New applications and business models for enterprises/governments leveraging cloud computing
- Economic evaluation of cloud-based enterprises
- Service lifecycle models
- Architectural support for security and privacy
- Architectural support for trust in/by cloud services
- Capacity planning of services running in a cloud
- Architectural support for quality of service (QoS) and service level agreement (SLA) management
- Accountability of cloud services, including mechanisms, algorithms and methods for monitoring, analyzing and reporting service status and usage profiles
- IT Governance and compliance, particularly in hybrid and multi-tier clouds
Review and publication process:
Authors are invited to submit previously unpublished, high-quality papers before
***20 June 2011***.
Due to the limited time for review, this is a strict paper submission deadline and extensions will be given only to re-submission of papers reviewed by CEC'11 (authors of these papers will have about 3 days after CEC'11 notification to improve their papers). Papers published or submitted elsewhere will be automatically rejected. All submissions should be made using the EasyChair Web site http://www.easychair.org/conferences/?conf=c4e2011.
Two types of submissions are solicited:
* Full papers – describing mature research or industrial case studies – up to 8 pages long
* Short papers – describing work in progress or position statements – up to 4 pages long
Papers presenting and analyzing completed projects are particularly welcome. Papers about on-going research projects are also welcome, especially if they contain critical, qualitative and quantitative analysis of already achieved results and remaining open research issues. In addition, papers about experiences and comparative analysis of using cloud computing in enterprises and governments are also welcome. Submissions from industry and government are particularly encouraged. In addition to presentation of peer-reviewed papers this one-day workshop will contain a keynote from an industry expert and an open discussion session on practical issues of migrating legacy enterprise and government applications to clouds.
All accepted papers (both full and short) will be published by the IEEE and included into the IEEE Xplore digital library. A follow-up journal issue with improved and extended versions of the best workshop papers is also planned.
Paper submissions must be in the IEEE conference paper format. Papers in other formats will be rejected automatically. Guidelines and templates for this format are available at: http://www.ieee.org/conferences_events/conferences/publishing/templates.html. All submissions should include the author's name, affiliation and contact details. The document format for all paper submissions is Adobe PDF.
All submissions will be formally peer-reviewed by at least 2 Program Committee members. The authors will be notified of acceptance by
***4 July 2011***.
Since this date is very close to the deadline that the workshop chairs have for submission of camera-ready papers to the IEEE, there will be very short time (if any) for improving accepted submissions into camera-ready versions of the final papers. Further information about the procedure will be provided to the authors closer to the notification date.
At least one author of every accepted paper must register for the whole CEC’11 conference (there is no separate workshop registration) and present the paper.
Inquiries about paper submission should be e-mailed to Dr. Vladimir Tosic (vladat at server: computer.org) and include "Clouds for Enterprises 2011 Inquiry" in the Subject line.
Dr. Vladimir Tosic, NICTA, Australia; E-mail: vladat (at: computer.org) – primary workshop contact
Dr. Andrew Farrell, HP Labs, UK; E-mail: andrew.farrell (at: hp.com)
Dr. Karl Michael Göschka, Vienna University of Technology, Austria; E-mail: Karl.Goeschka (at: tuwien.ac.at)
Sebastian Hudert, University of Bayreuth, Germany; E-mail: sebastian.hudert (at uni-bayreuth.de)
Prof. Hanan Lutfiyya, University of Western Ontario, Canada, E-mail: hanan (at: csd.uwo.ca)
Dr. Michael Parkin, Tilburg University, The Netherlands, E-mail: m.s.parkin (at: uvt.nl)
Workshop Program Committee (to be completed):
Danilo Ardagna, Politecnico di Milano, Italy
Tina Balke, Uni. Bayreuth, Germany
Paul L. Bannerman, NICTA, Australia
Rajkumar Buyya, Uni. Melbourne, Australia
Shiping Chen. CSIRO, Australia
Torsten Eymann, Uni. Bayreuth, Germany
Felix Freitag, Uni. Politècnica de Catalunya, Spain
Lorenz Froihofer, A1 Telekom Austria, Austria
Ian Gorton, PNNL, USA
Matti Hiltunen, AT&T Labs, USA
Christophe Huygens, Katholieke Uni. Leuven, Belgium
Hans-Arno Jacobsen, Uni. Toronto, Canada
Bastian Koller, HLRS, Germany
Kevin Lee, Murdoch Uni., Australia
Mark Little, Red Hat, UK
Yan Liu, PNNL, USA
André Ludwig, Uni. Leipzig, Germany
John Mace, Newcastle Uni., UK
Patrick Martin, Queens Uni., Canada
Leandro Navarro, Uni. Politècnica de Catalunya, Spain
Rui Oliveira, Uni. Minho, Portugal
José Orlando Pereira, Uni. Minho, Portugal
Nicolas Repp, TU Darmstadt, Germany
Giovanni Russello, CREATE-NET, Italy
Derong Shen, Northeastern University, China
Philipp Stephanow, Fraunhofer SIT, Germany
Francois Taiani, Lancaster Uni., UK
Yazhe Tang, Xi'an Jiaotong Uni., China
Eddy Truyen, Katholieke Uni. Leuven, Belgium
Hiroshi Wada, NICTA, Australia
Philipp Wieder, TU Dortmund, Germany
Guido Wirtz, Uni. Bamberg, Germany
Yun Yang, Swinburne Uni. of Tech., Australia
Liangzhao Zeng, IBM Research, USA