egi cost models m egi from indirect methods [email protected]
TRANSCRIPT
2
Introduction
• So far, there have been various hints at possible – and even impossible – sizes for an eventual EGI “virtual organisation”• To cover scenarios where all or parts of its functions may be
distributed• We need – rather soon – to come up with some concrete
scenarios for discussion• IMHO – the place is here & the time is now!
• The following admittedly hand-waving arguments show that the range of possible sizes is not infinite!
This has strong implications on possible funding and start-up scenarios
• I do not wish to re-emphasize on each slide the absolute fundamental necessity that the functions & services offered by an EGI must be of clear value to the funding bodies and application communities
Preferably performed more efficiently and cheaper – even if in some / many cases implemented in a distributed and / or federated manner
Methodology…
• Estimate minimum management overhead;
• Estimate minimum FTEs per 'agreed' function;• More detailed calculations will be presented during
rest of workshop – these numbers can be ‘plugged in’ to the model!
• Consider mitigations;
• Summary
3
Significant RoI
• The requirement for a significant return-on-investment already gives some indication of a possible size of an EGI• RoI = “Cost savings” + “Functionality benefit”
• For each “FTE” invested, ideally would like a return of a factor (2-3?)
• A return of ± 10% is simply uninteresting• A return of an order of magnitude if simply unrealistic!
• This would suggest a threshold (average) contribution of ~1FTE
• (If you invest << 1FTE, your return will also be << 1FTE!)
4
The CxOs
• Whether you take a company / organisation of the size of Oracle (~40,000), one the size of CERN (<3,000) or a SME the “pinnacle of management” – i.e. the CEO, CFO, CTO etc. is roughly constant
• It is the layer(s) below that scale with width and depth• Executive Vice Presidents for Inter-galactic marketing etc.
• How many people:1. 5th floor, B60 at CERN (directorate): 17 people (at least 1
retired)2. EGEE project office (Bob & friends): ~15 people3. WLCG “project office”: ~6 people4. LCG Management Board: ~30 people (plus alternates)
• I doubt that the EGI management + assistants will be <<10 – so let’s use 10 for sake of argument!
5
Other Support Staff / Groups
• Assuming that EGI is an independent – and non-hosted – organisation, additional support teams are needed• HR, legal, purchasing, transport, IT, security & maintenance etc.
• OK, you can perhaps out-source some / many / all of these, but that doesn’t make them free!
• If EGI were to be “hosted” by a kind organisation, may hope to get some of these functions “for free” – or at significantly reduced cost
• But again, for simplicity, let’s assume something like 10 – 15 for the sum of these functions• Maybe a serious underestimate!
6
7
The Story so Far…• So far, we have a “virtual organisation” of 20 – 30 staff, but
no clearly defined “EGI functions”• See also, e.g. http://www.terena.org/about/people/
• The cost of such an organisation is 0.5 – 1 FTE per participating NGI• Maybe we’d better start looking for some application
communities who would like to contribute!• But we have probably failed pretty miserably on RoI!
Time to look at some of the functions!
• Again with some simple analogies / hand-waving arguments!
• I will simply look at some of the groups around me, their size, their roles & functions – more detailed analyses will presumably be part of the presentations that follow!
8
Caveat
• There are two main reasons for choosing these examples:
1. I have been part of each of these three groups (or their ancestors / descendents) during the period of ramping up Grid production services – I hence have “insider knowledge” of what they do!
2. The information is readily accessible and verifiable
• I already suggested some time ago that a more in-depth study – perhaps as part of D3.1, perhaps (also) performed by WP5 – should complement these estimates
• We do have staffing numbers for a wide range of “WLCG Sites” – detailed info on Tier0 & Tier1 + a survey of Tier2s
I am not suggesting these groups be part of EGI!
9
CERN Grid Deployment Group
• This group – in it’s 4th iteration – provides the following key functions:
• CERN ROC• (m/w) Integration, Certification, Testing• Pre-production Service (together with other PPS partners)• Includes critical functions such as SAM, …• i.e. CERN’s contribution to EGEE SA1/SA3
• All of these functions are candidate functions for EGI – although there are a variety of implementation models
• IT-GD consists of about 30 people, mainly funded by EGEE (see caveat on previous slide)
10
Grid Support Group at CERN
• This new group inherits functions that were previously provided in IT-GD & IT-PSS
• To keep it simple, primary role in EGI-speak is Application Support
• It consists of about 35 people focusing on HEP AS plus a few others on non-HEP VOs
• I am not suggesting such a size “centralized” in EGI, but we already discussed an absolute minimum size of 2 (e.g. per NGI as appropriate), with perhaps 5 people in a “central” team
11
Data Management Group at CERN
• Performs data management and (related) middleware development for CERN, HEP and to some extent (e.g. gLite FTS, LFC, DPM…) EGEE+ communities
• Also offers DB services to physics community• Roughly the same number of people as GD & GS
• Not so easy to count as many “visitors” registered in all groups
• Again, these are key functions that must – somehow – be provided in the “EGI era”
• Of course, models whereby some of these functions are performed by one or more NGIs (funding model?) – as is the case in EGEE (I/II/III) – can be discussed
12
A Range of Functions…
• Depending on how you count, the “EGI portfolio” consists of some 10 – 15 functions
• Taking an average of 5 FTEs per function, you arrive at a size of 50 – 75 – to which the CxOs, legal etc must be added• I’m basing this purely on the number proposed for EGI Application
Support, as proposed at December 7th Meeting in Munich…
• For some functions – such as the examples given in previous slides – 5 FTEs is clearly far too few• e.g. (overall) operations (see presentation), middleware dev.
(ditto?)
• But for others, this may be about right (e.g. Application Support) and there is the possibility of “dual roles”• e.g. Application Support experts performing Out-reach, training
and other functions part-time 13
The Ballpark
• Using 3 simple arguments… 1. Minimum useful investment to get useful RoI;2. Size of existing “grid deployment / support / development”
teams;3. Size calculated based on range of functions in DoW and from
NGI questionnaire… we arrive at roughly the same size
Will be interesting to cross-check against ‘functional calculations’ tomorrow and Thursday as well as equivalent EGEE calculations!
• The “optimal” RoI will depend not only on the exact functions provided, but also on the implementation model
• But we’re O(1FTE + overheads)
14
15
EGI – The Challenge
• I believe that the challenge can be distilled into the “Essence of this Workshop”
¿ How can a core set of key functions be built and presented in such a fashion as to be “stunningly attractive” – and hence virtually irresistible – to NGIs?
• It would seem (most) unlikely that an EGI offering all possible functions “centrally” would be affordable – let alone desirable
• But some are almost certainly essential and will hopefully be clearly identified through this workshop!
• We are still left with the “boot-strap” issue:¿ How to ensure EGI starts on-time and takes over from
EGEE III in a smooth and non-disruptive manner?
16
Boot-Strap Scenarios…
• It seems most unlikely that enough NGIs will be in a position to pay for the range of functions – still to be defined – that will be required as from day 1
• But if a core set of functional – together with the needed continuity from EGEE III – is not provided then we will not have met our key objectives!
¿ Can we hope for “start-up” money – e.g. from the EU – to cover the years when additional NGIs are ramping up internally and joining the overall EGI world?
• This would still require that we identify the absolute core functionality as well as the initial contributing NGIs
Plus work on an urgent plan for attracting additional NGIs and / or Application Communities in a timely fashion!
17
Summary & Conclusions• Through a variety of hand-waving arguments and
analogies with existing structures, we have come up with a basic costing model of ~1-2 (and not much more…) FTEs per participating NGI / Application Community
• We should be careful in counting total costs – obvious overheads (buildings, heating, IT infrastructure, snow-clearing in the winter…) should not be overlooked
• The question of location could have an important influence on total costs – but so could “hosting” – i.e. benefiting from the existing infrastructures of a host institute
However, the decision should be based on the overall package – where, when & how the agreed range of functions can be offered in the most attractive and professional manner
18
Backup Slides
The End