egi cost models
Download
Skip this Video
Download Presentation
EGI Cost Models

Loading in 2 Seconds...

play fullscreen
1 / 20

EGI Cost Models - PowerPoint PPT Presentation


  • 101 Views
  • Uploaded on

W. EGI Cost Models. m egi from indirect methods [email protected] 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' EGI Cost Models' - dorie


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
egi cost models

W

EGI Cost Models

megifrom indirect methods

[email protected]

introduction
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
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
significant roi
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!)
the cxos
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:
    • 5th floor, B60 at CERN (directorate): 17 people (at least 1 retired)
    • EGEE project office (Bob & friends): ~15 people
    • WLCG “project office”: ~6 people
    • 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!
other support staff groups
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!
the story so far
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!
caveat
Caveat
  • There are two main reasons for choosing these examples:
    • 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!
    • 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!
cern grid deployment group
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)
grid support group at cern
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
data management group at cern
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
a range of functions
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
the ballpark
The Ballpark
  • Using 3 simple arguments…
    • Minimum useful investment to get useful RoI;
    • Size of existing “grid deployment / support / development” teams;
    • 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)
egi the challenge
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?
boot strap scenarios
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!
summary conclusions
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
ad