On a Sustainable Infrastructure

On a Sustainable Infrastructure

Background

At the last AstroGrid Oversight Committee (Ref 01) meeting (02), the committee recorded the following comments about sustainability:

The Committee said that, if AstroGrid continued to build the software stack above the operating system, it would create a mass of software that would require significant levels of support into the future. This approach was not sustainable.
(03, p. 5)

AstroGrid would soon be applying for follow-on funding and further thought should be given to putting the project on a more sustainable footing. It should not aim to provide all the hardware and software from within the project. The projects should be picking up on existing work in the field e.g. middleware from the OMII and from projects in other domains. Likewise for hardware, the project should not be depending on goodwill for cpu and disk resources but seriously looking at a partnerships with the NGS.
(03, p. 7)

In this piece I'd like to investigate these statements and their implications.

Introduction

At first glance, it seems obvious that UK astronomers will be better served by the AstroGrid project adopting some standard e-Science derived and OMII supported components rather than developing its own set. But, as with many myths about computing (04), this claim may not stand up to investigation.

I'd like to pose a few questions about sustainability. Once I've formulated them here, I'll address some of these to Steve Newhouse, Director of the Open Middleware Infrastructure Institute (OMII: 05) and newest member of the AGOC, and post his responses here. His position with the OMII will hopefully give us a useful insight into this issue. I'll also address some to Guy Rixon, the AstroGrid system architect.

The questions I'd like to address are about:

what sustainability means to/for AstroGrid
the suitability of middleware components (OMII ones in particular) to AstroGrid
whether replacing existing AstroGrid components is feasible

Sustaining AstroGrid

The first comment above, that AG was creating a software stack which would end up being unsustainable, is not, in my opinion, correct. The current set of software was created by around 8-10 developers over three years with frequent research into best methods and consequent refactoring. This has resulted in a working infrastructure. By the end of 2007 this infrastructure will have most of what is required to run the Virtual Observatory. If it was simply a matter of maintaining that software onwards, it would only require having

...

IVOA conformance

While it is no requirement of Grid developers, nor of the OMII, that their components conform to IVOA (06), it most definitely is for AG.

...

Operational considerations

One would think that operating the UK-VO would be pretty much the same whether the software stack is completely built from scratch or built up from third-party components. But is this true?

...

Using middleware in AstroGrid

Replacing AstroGrid components with middleware

Conclusions

This essay is not really about coming to fixed conclusions but more about raising questions...

References

01: AstroGrid Oversight Committee (AGOC), see http://wiki.astrogrid.org/bin/view/Astrogrid/OversightCommittee

02: AGOC meeting 07, see http://wiki.astrogrid.org/bin/view/Astrogrid/OversightCommittee#Meeting_07_07th_February_2006

03: Minutes of AGOC07, see http://wiki.astrogrid.org/pub/Astrogrid/OversightCommittee/minutes.pdf

04: One example of such a myth is the 'promise' of re-usable components. The idea was that IT departments would create, as part of new projects, re-usable components which would reduce the time taken to develop future projects. This promise came out of and was made possible by the drive to develop using OO methods: such developments typically took longer and the justification that it led to more maintainable code seldom carried weight with the Finance Director, but that it led to re-usable code and cheaper future projects did. As it happened, when new projects came along the old components were, in all but a few cases, entirely unsuitable for the new project: either they were too difficult to integrate into the new project architecture without sacrificing features or new technologies made it possible to write much better (and also re-usable) components.
Perhaps now, with web services offering the realistic idea of separate and usable components, this old idea can be made to work. But, then again, there is a lot more effort on building these services than on using them, so maybe not. smile

05: Open Middleware Infrastructure Institute (OMII), see http://www.omii.ac.uk/

06: International Virtual Observatory Alliance (IVOA), see http://www.ivoa.net/

07:

-- TonyLinde - 03 Mar 2006

Main

Click here for the
AstroGrid Service Web

This is the AstroGrid
Development Wiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback