Giv et bud på intelligent offentlig IT

Som Ole så klart beskrev, hersker der totalt anarki indenfor offentlige persondataregistre, hvor firmaer som CSC og KMD skovler penge ind på manglende offentlig omtanke og beslutsomhed.

Jeg er sikker på at hvis vi bare overlader dette til politikerne, koster det nogle hundrede millioner i konsulentrapporter og ender med at blive dårligere og dyrere når de nye offentlige IT projekt engang bliver færdigt.

Så lad os løse det problem for vores egen og vores trækprocents skyld.

Her er en kravspecifikation:

1) Der skal laves et fællesoffentligt register for oplysninger om juridiske personer (firmaer, foreninger, fonde, personer osv).

2) Det kan antages at der findes en globalt unik nøgle for alle juridiske personer (CVR, CPR), men registeret skal understøtte hurtigt og effektiv fritekstsøgning i alle felter en bruger har adgang til at læse.

3) Registerets data skal være dynamisk konfigurerbare, således at nye felter kan tilføjes under drift. Felter defineres med regler for hvornår de kan existere, som funktion af andre felters existens eller indhold. Data Dictionary for alle felter skal leve op til rigsarkivets regler.

4) Registeradgang styres på to niveauer: "kunde" og "bruger". Adgangskontrol skal styres på både kunde, bruger og feltniveau (læs/ret/tilføj/slet) Kunder kan være offentlige myndigheder eller private aktører. Kunderne skal selv vedligeholde deres brugerlister via et API.

5) De enkelte registrerede jurdiske personer skal have real-tid, elektronisk read-only adgang til alle registreringer om sig selv.

6) Registerets felter opdeles i følgende klasser:

a) Felter der er offentligt tilgængelige (Navn, alder, køn, uddannelse, nuværende addresse, email, telefon etc.) Dette feltsæt administreres af en "pseudokunde" i form af et af indenrigsministeren nedsat udvalg.

b) Felter alle offentlige myndigheder har adgang til (Skatterestancer, familie-relationer, etc.) Dette feltsæt administreres af samme udvalg.

c) Tillægsfelter per kunde.

I) Offentlige myndigheder får 10kB per juridisk person (i gennemsnit) til egne felter, gratis.

II) Private kunder får 32 tegn per juridisk person (i gennemsnit) til egne felter, som del af pakken.

III) Kunder kan give andre kunder adgang til deres tillægsfelter, men som udgangspunkt kan de kun selv se dem.

IV) Kunderne administrerer selv disse felter, via et API, uden indblanding eller behov for at registerets personale eller organisation involveres.

V) Er der behov for yderligere lagerplads, kan dette tilkøbes til kostpris.

7) Registeret tilgås alene via et maskinbrugbart API, via Internettet, med kryptografisk sikret auth/priv/ident. APIet skal som et minimum understøtte følgende operationer: Opslag, Opdatering, Nøglesøgning, Fritekstsøgning og abonnemt på oplysning om ændringer i felter. Hertil kommer de nødvendige API operationer for vedligehold af kundespecifikke felters definition.

8) Alle adgange og alle ændringer i registerindhold skal logges i et format der gør det muligt for "robotter" at være på udkig efter registermisbrug. De registrede juridiske personer skal selv, on-line, i real-tid, kunne se kundenavn (men ikke brugernavn) på alle der har tilgået deres registreringer indenfor det seneste år.

9) Omkostningerne ved registerets konstruktion og drift afholdes af staten.

a) Offentlige myndigheder betaler ikke for deres brug af arkivet, med mindre de har brug for yderligere plads.

b) Indenrigsminsteren fastsætter de detaljerede krav til og betaling for private kunders adgang. Administrationen heraf må maksimalt udgøre 5% af registerets samlede driftomkostninger.

c) For non-profit private kunder, som f.eks spejdergrupper, grundejerforeninger mv. bør betalingen være symbolsk og implementeringen af deres adgang tilsvarende billig.

d) For profit-søgende private kunder fastsætter indenrigsministeret det årlige abonnement og prisen på ekstra lager.

e) Ingen kunder betaler transaktionsafgift, men private kunder kan miste deres adgang, hvis deres transaktionsmønster er urimeligt.

10) Registeret implementeres i tre driftcentre, et primært og to backup centre, med indbyrdes afstand på min. 100km.

11) Svartider over 1 sekund må kun forekomme for en transaktion ud af en million.

12) Registeret må have 1 times planlagt, varslet nedetid om året. Resten af tiden skal det virke, come hell or high water.

13) Datatilsynets irettesættelser skal nemt kunne implementeres ("disse felter er ulovlig registring, slet dem.")

14) Hele kildeteksten skal være offentlig tilgængelig og rettigheder til udviklet software 100% ejet af den danske stat.

Giv et bud:

Hvad koster det at udvikle ?

Hvad koster det at drive ?

Hvor lang tid vil det tage før det er i drift ?

phk

Kommentarer (78)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Nils Bøjden

Glimrende forslag. Jeg har altid undret mig over hvordan de oplysninger staten/fællesskabet har om mig kan koste mig penge at tilgå.

Og en sådan service er et oplagt system til den cloud services som staten skal køre for alle de services som indeholder personfølsomme data.

"Private kunder får 32 tegn per juridisk person (i gennemsnit) til egne felter, som del af pakken"

Er det 32 B? Det er nok lidt i underkanten. 1MB til hver skulle være passsende (ca 6TB hvis alt var brugt). Omkostning for 6TB i et datacenter ligger vel i størrelsesordenen 500 - 5000 om året alt efter hvilken disktype og access tid man forventer til systemerne.

  • 0
  • 0
Anonym

KMD, CSC, og en hel del andre, har fået milliarder, gennem mange år, for at komme til at sidde hårdt på den løsning.
Der er vel som sådan ikke det store i at lave selve løsningen, det koster det samme som altid.

Det bliver ikke billigere, fordi man skal lave det hele en gang til.
Det er der INTET der gør.
Oftest, så er det dyrere at lave tingene om, så jeg er helt enig i, at man skal starte fra bunden.

Fordelen skal findes i, at det er ejerskabet, der skifter hænder.

Jeg er også helt enig i, at det ikke bør være en privat virksomhed, der ejer retten til persondata, i et frit demokratisk retssamfund.

Kig på, hvad DanID/Netz, har fået for udvikling af NemID.
Læg det sammen med tilsvarende dataløsninger fra CSC eller KMD.
Så har du ca. prisen på den del.

Du stiller nogen krav til brand og bombesikkerhed, som koster voldsomt meget.
Hvis det skal være, som det har været set i forbindelse med andre infrastrukturelle løsninger, så skal der skabes redundant kabling, mellem en række datacentre der er sat op med et redundant serverset, UPS, osv..
Det koster en del, at foretage denne kabling, og det koster også en del at oprette sådanne centre.
Der findes løsninger på det problem, men så skal man tænke sig lidt om.

Hvis det er noget man vil have et egentligt overslag på, så skal der lidt mere til, end vi kan trylle frem her offentligt på V2.

Igen. Det bliver ikke billigt, men ejerskiftet er vigtigt.
Ellers fortsætter den tommelskrue, og man kommer til at betale kassen for selv det mindste, i al fremtid.

Og jeg er helt enig med dig i, at det skal løses ansvarligt.
Men hvis det betyder, at man igen vælger at sælge løsningen, til et udenlandsk firma, efter 10 år, så er der intet formål med at lave en sådan forkromet løsning.
Tænk bare på, at "Telefonselskaberne" nød helt enestående monopol beskyttelse, for efterfølgende at blive solgt til udlandet.

Jeg tror, den slags starter, bl.a. hos personer som dig, der udviser et ansvar for opgaven, og respekt for, at det er skatteydernes penge.
Men det kræver, at man tilsvarende kan stole på de politikere, der skal sikre løsningen bliver forvaltet med en tilsvarende respekt.

Jeg ville ikke være så bange for at tilslutte mig din løsning, hvis du fik lov til at løse opgaven, men jeg ville ikke have det god med, at nogen andre politikere, med helt andre holdninger, sælger hele skidtet til en foundation, om 3½ år.

  • 0
  • 0
Poul-Henning Kamp Blogger

Fordelen skal findes i, at det er ejerskabet, der skifter hænder.

Og i de nye muligheder det åbner.

Du stiller nogen krav til brand og bombesikkerhed, som koster voldsomt meget.

Ja, det er jo ikke nogen bolsjebutik vi taler om.

Pointen her er jeg gerne vil høre nogle kompetente forslag til hvad det ville koste.

Jeg er ikke et øjeblik i tvivl om antallet af ciffre hvis KMD eller CSC skulle byde på opgaven.

Men jeg har en ide om, at hele systemet kunne bygges for mindre end advokatregningen til EU-udbudet, hvis det blev gjort af kompetente mennesker.

Den pointe skal vi have frem i lyset.

  • 10
  • 0
Søren Breddam

Lige nu indeholder CPR også distriktsdata såsom skoledistrikter og valgdistrikter på adresseniveau og dermed også en adressekomponent. Det ville være oplagt at der var en geografisk komponent, som lå under CPR-registreringen, og som definerede de nødvendige flader. Adresserne burde i princippet kunne komme fra BBR, som indeholder den officielle adresseregistrering. CPR-loven siger dog, at man skal registrere borgere, hvor de bor, og derfor slipper man ikke for at have en selvstændig CPR-adresse - også selvom CPR-loven i princippet er i modstrid med BBR-loven.
Stedfæstelsen af personen og de deraf geografiske afledninger vil åbne for mange muligheder for analyse, modellering, visualisering og datamanipulation.

  • 0
  • 0
Nils Bøjden

Hvis der foretages 10.000 opslag pr dansker (6mio) pr år og udtrækslogningen fylder ca 1KB (indeholder forespørger, timestamp, samt hvilke data der blev trukket som minimum) pr opslag kommer loggen til at fylde ca 60TB/år. Den skal så gemmes svarende til registerlovgivningen (5 år) = 300TB. Dette skal så indexeres hvad der formodentlig øger datamængder med 100 -> 200%.

Så alene logningen vil fylde 1PTB (jeg tror at jeg fik regnet rigtigt)

  • 0
  • 0
Poul-Henning Kamp Blogger

Hør nu her: Et af de største problemer i offentlig IT er at man ikke kan finde ud af at skære opgaver til.

Du har helt ret i at der mangler en fællesoffentlig GIS database, men der er ikke det samme som en persondata database og det er lodret idiotisk at tro at man kan løse begge opgaver med samme database.

Skæg for sig, snot for sig, og så videre med den stillede opgave: Persondatabasen.

  • 1
  • 0
Søren Breddam

Skæg for sig, snot for sig, og så videre med den stillede opgave: Persondatabasen.


Jaja, lad os kaste os ud i et projekt, hvor vi glemmer halvdelen men så lige medtager sådan noget som telefon og emailadresse.

Hvad gør vi, når der skal indskrives børn i skolen eller udsendes valgkort, hvis vi glemmer disse data på bekostning af andre ønsker? Foreløbig tegner det meget fint til at blive et meget normalt offentligt projekt.

Jeg ønsker absolut ikke en fællesoffentlig GIS-database. Det er en vederstyggelighed!
Og jeg forstår godt, at du bare gerne vil have en pris.
Jeg beder bare om, at vi overvejer, hvad vi skal have en pris på. Det behøver du ikke at blive sur over.
Hvis vi nu har en ID på den juridiske person og en ID på placeringen og så håndterer de øvrige CPR-opgaver i et andet system, kan vi vel godt blive enige?

Eller er det ikke meningen, at alle CPR-opgaver skal adresseres indenfor prisen på din løsning?

  • 2
  • 2
Poul-Henning Kamp Blogger

Eller er det ikke meningen, at alle CPR-opgaver skal adresseres indenfor prisen på din løsning?

Jeg er ikke rigtig sikker på at jeg overhovedet fatter hvad du brokker dig over lige nu...

Er det fordi jeg ikke explicit nævnte en felttype for længde&bredde ?

Selvfølgelig kan der defineres felter der refererer til geografisk informationer, ligesom de kan referere til alt muligt andet, fra bankkonti til antal puddelhunde med racerenhedsbevis.

Dette er et register der skal arbejde sammen med andre registre, det er sådan set præcist den eneste opgave det har. GIS registre er kun et ud af tusinder eksempler og de hverken kan eller skal have særbehandling.

  • 1
  • 0
Nils Bøjden

En PetaByte er altså ikke noget særligt særligt mere, jeg har bekendte der nu laver lang-pisseri i exabytes..

Og så skal den lige ligge i et eller andet raid (0+1?) på 3 centre = 6PB.

Jeg ved godt at der masser af stedet rodes med exa men vel ikke specielt mange steder i datacentre med organiserede data. Der hvor jeg har hørt om det er LHC, astronomiske observatorier og Google.

http://www.informationweek.com/news/global-cio/interviews/224400178?pgno=2
"In the last bit, we create 5 exabytes every two days. "
Det var i 2010, Yeik!

Nå men 6PB i 1TB(2,5" kræver mindre plads og mindre strøm) diske = 6000 diske = 6000(500/disk)+racks+strøm+plads+dimser= 5 mio i start.

MTBF 3 år/årlige geninvesteringer ca 1,7mio + strøm + diverse = 2,5 mio

Løn=?????

Og så maskiner og netværk + licenser (burde kunne drives på åbensovs)

  • 0
  • 0
Daniel Madsen

Hvis ingen vil starte legen, gør jeg det gerne.

Hvad koster det at udvikle ? 20 mio.
Hvad koster det at drive ? 5 mio.
Hvor lang tid vil det tage før det er i drift ? 1 år

Ja, det er med livrem og seler, men det er trodsalt det offentlige vi har med at gøre her.

Nogen billigere?

  • 0
  • 1
Lars Hansen

Nå men 6PB i 1TB(2,5" kræver mindre plads og mindre strøm) diske = 6000 diske = 6000(500/disk)+racks+strøm+plads+dimser= 5 mio i start.

Det var godt nok nogle billige diske, vil du bare bruge almindelige consumer SATA diske? Vi bruger FibreChannel diske i vores SAN til 5000,- /stk og 450GB kapacitet per enhed.

Hvor mange IOPS skal det her trække? Ikke at jeg forventer nogen på stående fod kan svare på det, men vi skal jo vide hvad vi bygger til inden vi vælger materialer.

Det er vel heller ikke alle data der død og pine skal returneres prompte? Måske kunne noget placeres mere økonomisk fornuftigt end andet.

Anyways, der er en stor forskel, om vi taler enterprise klasse udstyr, eller når man bare finder det billigste skrammel på edbpriser. Måske kunne det overliggende system være robust og redundant nok til at tillade det underliggende materiel, at være substandard?

Lyder som et rigtigt spændende oplæg det her, jeg har tit undret mig over, hvad alle vores IT skatte milliarder går til og om det kunne tænkes på ny.

  • 1
  • 0
Eskild Nielsen

Hvis der foretages 10.000 opslag pr dansker (6mio) pr år og udtrækslogningen fylder ca 1KB (indeholder forespørger, timestamp, samt hvilke data der blev trukket som minimum) pr opslag

Hvis du har ondt i diskpladsen så kan du vel udnytte at det er relativt sjældent der bliver spurgt til den log.

Det er så muligt at komprimere de storede data kraftigt
timestamp 4 bytes, kunde (der foretog opslaget) 2-4 bytes, numerisk kode for felter der blev søgt på, 4 bytes, entitet opslaget vedrørte 4 bytes ialt 16 byte pr log entry- men det kan sikkert gøres bedre/smartere

  • 1
  • 0
Nils Bøjden

"Det var godt nok nogle billige diske, vil du bare bruge almindelige consumer SATA diske?"

Jeps. What's Good enough for Google is good enough for mé.

3 datacentre 0+1 raid/stripe med foranstillede load balancer. Jeg kan ikke rigtigt se hvorfor ganske almindelige 2.5 7200rpm diske ikke skulle være gode nok. Og så en fantasillion GB RAM

  • 0
  • 0
Søren Jacobsen

De funktionelle krav ser overkommelige ud. Men det var vel også meningen. De nævnte krav om logning, finkornet adgangskontrol og andre sikkerhedsmekanismer er gjort før, så det virker også fremkommeligt. Det helt grundlæggende funktionalitet kan vel skrives af en kompetent og fokuseret udvikler på en måned, men med støttesystemer, sikkerhedskrav, test mv. ryger der hurtigt noget på.

Slag på tasken: 2-20 udviklere i et års tid hvis du vælger at skrive det hele fra bunden.

Mit bud på arkitekturen er et schemaløst persistenslag som understøtter partitionering/sharding samt applikationslogik der kan skaleres horisontalt så du kan opnå dine performancetal også ved høje loads. Til rapportering/BI kan du have et andet datastore.

Man kan overveje et nonfunktionelt krav som siger noget om registerets evne til at flytte sig mellem datacentre, så man evt. slipper for at bygge 3 nye fysiske datacentre men kan leje sig ind hos en kommerciel leverandør, og gøre det praktisk muligt at shoppe rundt mellem leverandørerne (evt. placere centrene hos forskellige leverandører for at sprede risiko).

Ellers aner jeg ikke hvad det koster at bygge fra bunden, men man kan jo spørge NNIT, som lige har bygget et par stykker af slagsen.

Men vi er ved priser må vi dog ikke glemme prisen for at tage systemet i anvendelse. Hvor mange offentlige/private systemer skal retrofittes for at kunne bruge denne service? Jeg tror at de fleste vil betakke sig med mindre du gør ændringen transparent for dem, og så er vi ude i at systemet skal levere det samme data som CVR/CPR, hvilket stiller andre krav til hvilket data systemet skal indeholde.

Alternativt skal kravet bare være at nye systemer skal bruge den nye service, og at CPR/CVR kører videre as-is, men så ryger din business case, så jeg skeptisk overfor om det er en holdbar model.

  • 3
  • 0
Nils Bøjden

Jeg er forbavset over at det er det tætteste vi er kommet på at tale arkitektur endnu.

Det er fredag aften og tegnefilm og slik med ungerne.

"hvorledes ville I organisere databasen, med de krav der er stillet ?"

Måske en eller anden NoSQL fætter med master-replika. Måske MongoDB.

Og så skal der stilles krav til opdateringhistorik. Skal det være hele posten der skal gemmes eller kun de ændrede data.

  • 0
  • 0
Anonym

Snip----------
Re: Det koster kassen

Fordelen skal findes i, at det er ejerskabet, der skifter hænder.

Og i de nye muligheder det åbner.

Du stiller nogen krav til brand og bombesikkerhed, som koster voldsomt meget.

Ja, det er jo ikke nogen bolsjebutik vi taler om.

Pointen her er jeg gerne vil høre nogle kompetente forslag til hvad det ville koste.

Jeg er ikke et øjeblik i tvivl om antallet af ciffre hvis KMD eller CSC skulle byde på opgaven.

Men jeg har en ide om, at hele systemet kunne bygges for mindre end advokatregningen til EU-udbudet, hvis det blev gjort af kompetente mennesker.

Den pointe skal vi have frem i lyset.
Snip-----------

Din pointe holder desværre ikke ;)
Jeg er ked af det, men det holder bare ikke.

Lad os bare kigge på lidt af det.
Der er 100 kommuner:
I forbindelse med hver kommune, skal der læres mindst en op, der kan lidt omkring implementering osv. Det kan sagtens være den samme, som er både ansvarlig for ditten og datten, men regn med, at der skal en til fra hver kommune. Det er en million i det første år pr. kommune. Bare lidt groft sagt. Det er 100 millioner.
Kigger jeg erfaringsmæssigt på det, så koster det ca, 3,2 mill., for at slå en stilling i gang, hvis det er en virksomhed der startet, fra bart betongulv. Det er inkl. alle første års udgifter. Jeg ved ikke hvad andre har af erfaring, men det er min.
Skal vi skabe en mellemstor virksomhed, der løser opgaven, skal der vel omkring små 50 stykker, til at gøre det. Det vil koste 150 mill. for det første år, og efterfølgende 50 mill. om året.
Ud over det, så skal der bygges mindst 3 bombesikre centre, det er nok i omegnen af andre 150 mill.
Skal der trækkes kabler imellem, med relæstationer osv. koster det også en del.
Det koster mange mange penge, at have en kabellægger til at trække søkabler, og det er mildt sagt heller ikke gratis at grave/skyde, sådanne kabler frem over land.
Vi rammer langt over en milliard, og vi har stadigvæk ikke noget produkt, kun grundlaget for at kunne skabe produktet.

Det ER ikke så biligt og simpelt som det lyder.
Desværre.

Det er også årsagen til, at man har købt dyr skodløsning, på dyr skodløsning.
Som også har medført, at man efterhånden er blevet manøvreret ud i de problemer man har nu.

Det er jo lige meget hvordan man vender og drejer sig, ting koster det de koster. Der er ikke noget der falder ned fra himlen........

Jeg er sådan set også ligeglad, med hvad det koster. Det er jo bare en kostpris, og hvis man gør det rigtigt, så indgår den som omsætning i det Danske samfund.
Betyder 3 milliarder noget ? Gør det noget, at man hjælper 3 - 5000 landmænd med 3 milliarder (altså godt og vel en million til hver) ? Nej, det betyder ikke så meget, så længe det er penge der bliver i Dansk landbrug. Det handler om at skabe omsætning her i landet.

Bliver pengene brugt i Danmark, af Danskere, der skaber en Dansk løsning, så skaber det værdi for samfundet, også i fremtiden.

Men starter man med, at købe noget, som det man har accepteret i forbindelse med f.eks. NemID, som jo dybest set bare er en Bank-løsning, man har givet et nyt navn. Så kommer det til at koste kassen, og har efterfølgende absolut ingen værdi som en vare.
Det er fejlen omkring KMD, CSC, og alle de andre løsninger. De er noget som man kender i forvejen, med svingende succes.

Til dem der tror man kan gøre sådan noget, for 5 - 10 - 20 millioner....
Det kan man ikke engang købe hardwaren for, sådanne serversæt koster meget mere, hvis det skal være nogenlunde stabile maskiner.
Man kan ikke engang købe skriveborde PC'er og almindelige arbejdsforhold, til halvdelen af dem der skal udføre den elektroniske side af opgaven.
Hvad tror man det koster at bygge en bombesikker løsning ? Er det noget man har tænkt sig at ringe til Eddie C og spørge efter ?

Skal jeg skyde vildt fra hoften, så koster det 3 - 4 milliarder at fremstille, og 500 - 1000 stillinger om året at drive, for en population på 5 mill..
Giv lidt, tag lidt. Og vær fleksibel med hensyn til området implementering, førstegangsdata, osv...
For det, kan der skabes et system, hvor relevante person-/virksomheds- (følsomme) data ligger hos Staten, vedligeholdes af Staten, på et system der ejes ejes af Staten. Herunder en mulighed for tilgang til data, fra åben offentlig side, inden for de regler EU normalt opererer med.
Det vil også KUNNE, åbne mulighed for et setup, som det der netop er foreslået, hvor standardiserede kommunale hjemmesider, drives over samme fysiske løsning, eller f.eks. borger.dk ligger samme sted.
Så slipper man for at trække kabler til det, UPS-løsning, osv.

Det kræver dog, at dem der kan og vil, løser opgaven.
Det kræver også, at man kan have tillid til Politikerne, så de ikke bare sælger hele moletjavsen til en foundation bagefter.
Det første, er muligt at finde ud af.
Det andet, er helt umuligt, da der er så mange i folketinget, som man ikke kan stole på, at det i sig selv gør løsningen usikker.

Økonomisk, kan det nationalt sagtens hænge sammen. Især på langt sigt.
Vi er en lille micro-nation, men har samme strukturelle behov som alle mulige andre lande. Derfor KAN det gå hen og blive en eksportmulighed, hvis den side af sagen håndteres rigtigt.
Man kan oven i købet trække på det, i forbindelse med u-landsstøtte, og på den måde hjælpe andre lande til at skabe et grundlag for Demokrati og Retsstat.

Meeeen, selv i Somalia, har en transportløsning, der fungerer med en brugt hjemmefixet Lada Niva, ikke meget værdi. Jeg tror faktisk man vil betakke sig, og i stedet spørge efter en brugt IC4 løsning, i god stand.

  • 1
  • 0
Poul-Henning Kamp Blogger

Der er 100 kommuner:
I forbindelse med hver kommune, skal der læres mindst en op [...]

For det første er jeg overhovedet ikke klar over hvad du mener den pågældende skal foretage sig, for det andet lyder det præcis som en opskrift på at få et offentligt IT projekt til at koste en millard og blive fem år forsinket og for det tredje er det helt udenfor scope:

Opgaven er at finde ud af hvad en sådan løsning vil koste at bygge og drive. Først når vi kender det tal kan vi begynde at kigge på hvad vi sparer/tjener ved det.

  • 2
  • 0
Klavs Klavsen

nogen std. bokse (med remote admin a la HP's ILO) med lokale diske eller iscsi disk-miljø - afhængig af DB backend (se længere nede), hostet i et par store hosting centre i DK (er der nogen på fyn?)

3 mill. til hardware (højt sat - nu disk priser vist er på vej ned igen :)

en loadbalancer foran hver sæt bokse - der fordeler queries imellem alle 3 (hvis de er oppe - f.ex. prioriteret på sidste svartid).

redundans over 3 centre - kræver man har sit eget AS, eller (nok smartere) betaler en ISP der er kompetent nok, for at køre det - og route AS'en rundt. har ikke arbejdet med div. Global redundancy løsninger, men det koster nok ikke mere end 50k om året at sikre sig en IP der peger på et af de 3 - der er oppe.

Som jeg forstår dig, så kan man selv definere API'et og dermed hvad klientsoftwaren skal kunne.

Man kunne jo lave en klient der kunne finde ud af hvilken der svarede af dem der lå i DNS (a la DNS round robin, men hvor klienten så kan finde ud af at prøve den næste hvis den første ikke svarer - det giver dog lidt længere svartid lige den ene gang hvor en failover bliver nødvendig).

Bag i - noget kode og en nosql database lyder plausibelt, alternativt burde det fungere fint at få mysql cluster (eller bare dele det op i X shards) til at drive query delen. Begge dele skalerer rimeligt - så man kan nøjes med at smide flere servere på, for at øge kapaciteten.

Udvikling 1 mandeår og 2 mio. (hvorfor ikke være godt lønnet). Dette forudsætter at en detaljeret implementationsbeskrivelse bliver godkendt - den nuværende beskrivelse er jo rimelig fleksibel og sådan noget som NemID funktionalitet giver straks hovedpiner (i modsætning til den digitale signatur vi havde før :( )

Drift: 1 kompetent person fuld tid med vagtordning og udgifter til hostingen de 3 steder.
1,5 mio pr. år. (1 mio. hvis udgifter til hardware udskiftning kan faktureres separat :)

  • 0
  • 1
Jimmy Krag

Jeg forestiller mig noget a'la Google File System med én fil pr. person/firma. Hver fil starter med id og hver fil slutter med pointers til datafelter. Filen fungerer som en stream, og kan arkiveres i chunks. Indexes opdateres løbende. Det var hvad jeg kunne komme op med på tiden det tog at skrive det + det løse.

  • 0
  • 0
Klavs Klavsen

ikke en ringe idé til backend lagring. Man skulle klart lave en hurtig impl. af forskellige lagringssetups og se hvordan de skalerer med et sådan simpelt datasæt - og så skal det lige klarlægges hvad kravet er til opdateringstiden fra den celle der bliver opdateret, før opdateringen er fuldt distribueret. IMHO gør det ikke noget at der kan gå nogle sekunder.

  • 0
  • 0
Klavs Klavsen

På mig lyder det som om PHK bare siger at ekstra felter kan man altid tilføje senere - eller i et andet register (med samme nøgle - dvs. CPR/CVR). Sandsynligvis vil det billigste bare være at tilføje de relevanter felter.

  • 1
  • 0
Rene Madsen

Bruger Facebook, Google, Amazon og andre store huse ovenstående løsninger?

Nej, blot massere af billig hardware. Fordi de er billige kan man have flere kasser der køre redudant.

En hypotetisk tanke var at bruge noget af den infrastruktur vi allerede har i lille DK, der er massere af fiber rundt i landt og endda redudant.

2,3 centre placeret i hver sin del af DK forbundet sammen med evt. private lan over noget af al den fiber vi har på kryds og tværs i landet.

Jeg vil også mene at dette kan laves for omkring de 20 mio at skabe/udvilke + 5 mio i drift hvert år.

  • 0
  • 1
Poul-Henning Kamp Blogger

På mig lyder det som om PHK bare siger at ekstra felter kan man altid tilføje senere

Nej, jeg siger at tilføjelse af felter er en af de services der skal udbydes.

Når Sangforeningen morgenrøden bliver trætte af at få girokort tilbage ved addresseændringer, skal de kunne købe en "foreningsløsning" hos en IT-pusher, betale de 50 kr/år, bruge deres nye credential og deres "medlemsnummer" felt tilføjes automatisk til de medlemmer de søger frem i registeret. Alt sammen uden at noget personale fra registeret skal indblandes.

  • 0
  • 0
Pascal d'Hermilly

"Skal der trækkes kabler imellem, med relæstationer osv. koster det også en del."
Ja du mangler jo noget konkret her. Jeg ved fra flere fiber-tilbud at det koster 30.000 at få gravet fiber 10 meter(f.eks. ind i haven) dvs. 3.000 kr per meter gravet. Ergo vil 3 forbindelser mellem datacentrene koste 3netværk * 100.000meter * 3.000kr/m = 900.000.000 kr for at forbinde datacentrene. Men når vi først har lavet det kan det sagtens blive en eksport-success.

  • 0
  • 3
Daniel Madsen

Hvorfor er vi ude i at bygge datacentrer? Det lykkes fint nok at hoste offentlige løsninger i de eksisterende - sådan her får I aldrig plads til en rød ferrari i jeres tilbud :-)

Klavs vinder formentlig udbuddet, men som CSC og lign. får han svært ved at holde prisen er jeg sikker på :)

  • 0
  • 0
Klavs Klavsen

Det er jeg faktisk pænt sikker på at jeg ikke får svært ved. jeg har designet løsninger med lign. krav - dog ikke i den skala - men det drejer sig bare om at sørge for at teste de forskellige implementationer (bruger selv grinder), før man formoder noget og så implementerer det i fuld skala og tester løbende, istedet for at formode :)

Den eneste "reelle udfordring" er at teste DB strukturen, der alt efter hvilken write-garanti der ønskes (flush on write på alle 3 lokationer, før hver request er leveret - reads giver writes i accesslog) og sikre sig, at designet skalerer liniært, så der bare kan tilføjes mere hardware for at få ønsket performance.

Den del er der heldigvis rigtig mange der har løst før mig, så jeg kan frit vælge imellem en hel del Open Source løsninger (DRBD, OCFS2 eller div. noSQL) der alle kan levere og giver lidt varierende garantier (som er primær kriteriet som jeg ser det).

  • 2
  • 0
Anonym

@ Daniel Madsen.

Du har helt ret i, at oplægget er noget ude i skoven ;)
Men skal man forholde sig til oplæg, så koster det bare kassen.

Skulle jeg trylle en løsning frem, så blev det også på en anden måde ;)
Men nu leger vi med Poul-Henning Kamp's forslag.

Og, så køber man jo ikke en rød Fræser..... Man køber en grå Tysker :D

  • 0
  • 0
Anonym

@ Poul-Henning Kamp
Du beskriver at det skal være bombesikkert, så må du forholde dig til det.
Vælger du en eksisterende kabling, så er du afhængig af, at en kabel operatør er oppe, i alle tilfælde, hvilket ikke er muligt.

( Det koster i øvrigt ikke 9 milliarder, at trække et kabel rundt i DK. Prisen kan aldrig blive mere, end den pris energiselskaberne har betalt for at få lagt er meget tættere fibernet. )

Hvor langt er du kommet i din vurdering. Mener du stadigvæk, at det kan gøres for nogen få millioner ?

Hvor mange arbejdspladser har du skabt ?

Hvilken garanti, har vi for, at det er Staten der ejer et sådant setup, når det er færdigt ?

Hvad får advokaterne, for at skrive et EU-udbud ?

  • 0
  • 1
Nils Bøjden

Det er så muligt at komprimere de storede data kraftigt

Jeg tror ikke at det er ønskværdigt at gøre dette ukonditioneret.

Vi har i princippet 3 begrænsere:
Diskplads
CPU
Båndbredde

Hvis vi vælger at denormalisere data koster det i diskplads men til gengæld spares der CPU til dekomprimering/joins.

Vi vi vælger at normalisere data bliver forbruget i intern båndbredde sat ned men jeg tror ikke at dette har en signifikant betydning.

Mit umiddelbare gæt er at CPU er dyrere end diskplads og at man derfor skal pege på en model med dekomprimerede data / denormaliserede data alle de steder man kan komme afsted med det.

Da langt størstedelen af data i systemet aldrig skal opdateres (log samt historik hvilket dækker 90 - 98% af data) kan de udmærket ligge i et denormaliseret format . Men det muligt at man skulle vælge en mellemløsning så alle data der er mere end kalenderår + 1 år tilbage blev komprimeret.

Med hensyn til backup er det kun stamdata / personens aktuelle data det skal være i en backup. Denne må aldrig forsvinde. Men sikringen med raid/stripe + datacenter duplikering burde være sikring nok for alle de read only data der eksisterer i systemet.

  • 0
  • 0
Ole Kaas

Jeg er forbavset over at det er det tætteste vi er kommet på at tale arkitektur endnu.

hvorledes ville I organisere databasen, med de krav der er stillet ?

Opgaven lød vel også mest på hvad det ville koste og hvor lang tid det ville tage. Jeg har haft lejlighed til at kigge lidt på Cassandra DB og den virker som et oplagt valg. Det er nemt at smide ekstra felter på ifht. en relationel DB. Man kan så vælge kun at skrive ændringer når der opdateres. Det har den fordel at så har vi gratis en transaktionslog. Ulempen er at alle ændringer skal traverseres for at få aktuelle data - men det kan klares ved at lægge snapshots ind med jævne mellemrum. F.eks en gang om måneden - så skal der kun trampes rundt i data for den seneste måned. Da vi nu allerede er i gang med at nasse på teknologi doneret af Facebook, ville det måske være oplagt at bidrage til deres opencompute project og få strikket bl.a. en PSU til Danske/EU forhold. Jeg vil mene det er meget vigtig for dette project at det nemt kan skaleres. For det første er det jo træls (irriterende;) hvis man her undervurderet behovet. For det andet kan det jo tænkes at løsningen blev voldsomt populær og alle mulige ville stå i kø for at købe mere plads. Hvis vi forestilller os at hver lokation skal have 60 FB servere á 25.000 (incl switche, rack, osv), så er prisen samlet 4,5 mill for etablering. Mindre kan måske gøre det - men så stiger stykprisen på serverne og vi behøver jo kun at starte dem vi har behov for.

Hvis vi forestiller os at systemet skal varetages af en selvstændig enhed - institution. Vi kommer nok ikke uden om at der skal være en daglig leder, ansvarlig og ansigt ud ad til. Da der kommer til at være en form for afregning, bliver det nok også nødvendigt med en bogholder. Der findes ganske glimrende opensource sytemer til håndtering af økonomi. Vælg et og udfør tilretninger i forbindelse med udviklingen. Der skal være nogle driftteknikere til at sørge for 24x7 drift, vedligehold og opgraderinger. Vi kan starte med et par stykker ifbm. deployment - men på sigt skal der nok være en håndfuld (måske med en bosat nær hvert backup center. Ja man kan meget med remote management, men...). I starten en lille håndfuld kompetente udviklere - ildsjæle - der får udtænkt et design og lagt et roadmap. Der hyres flere ind efterhånden som opgaverne er til det. Der skal hurtigst muligt et alfa system i drift til test så design og roadmap kan justeres løbende - gerne med feedback fra brugere der vil være med i test. Da sourcen er fri, findes der an masse glimrende værktøjer til udviklingen ganske gratis (github, jira, osv). Efter driftstart, reduceres udviklerne til en mindre gruppe til forstsat videreudvikling og fejlrettelser. Der skal være nogle supportere der hjælper brugerne af systemet. Supporten består udelukkende af email og community/forum. Alle ansatte bidrager i forum.

Alt i alt forstiller jeg mig i snit 15 medarbejder. Hvad koster en arbejdsplads incl kontor, skrivebord, løn, kaffe , klips og firmaskovtur? 1 mill? Så bliver det 15 mill om året. De 3 datacentre incl redundat Internet, strøm mm. kan vil gøres for 1 mill pr. lokation om året - i alt 3 mill til datacenterdrift. Vi kan så lægge 1 mill oveni om året til mindre udvidelser, opgraderinger og hw der futter af.

Vi runder op - 20 mill. om året til drift.
Etableringen (kontor, datacentre, Internetforbindelser osv) indebærerer en række up front ydelser og deposita - så 20 mill til at kickstarte "butikken".

Hvornår er systemet så klar til brug. Hvis vi er optimistikse og tager "ja" hatten på: 6 måneder. Vi skal så lige huske at gange med pi - så har vi tidspunktet hvor alle de initielle ønsker er implementeret (og virker :)

  • 2
  • 0
Anonym

@ Poul-Henning Kamp,

Så forstår jeg ikke dine krav.
Du skriver:
10) Registeret implementeres i tre driftcentre, et primært og to backup centre, med indbyrdes afstand på min. 100km.

11) Svartider over 1 sekund må kun forekomme for en transaktion ud af en million.

12) Registeret må have 1 times planlagt, varslet nedetid om året. Resten af tiden skal det virke, come hell or high water.

Du forventer, at et sådan system, skal virke, uanset om så helvede bryder løs, eller vi oversvømmes. Uden at have nedetid på over en time. Med svartider der skal ligge bedre end et sekund.
Det gør man jo ikke, med en forbindelse, der er afhængig af en ekstern leverandør. Man gør det heller ikke, med 3 centre der er bygget ind i et blikskur 3 steder i landet.

Du forventer også, at det kan skabes som ren Open Source, det har jeg mine tvivl om.
Her er det vigtigt, at ejerskabet er på plads, ellers vil hele scenariet falde til jorden.
Du er nød til at beskrive hvordan du vil sikre ejerskabet hos Staten, ellers er du jo bare ude på, at vi sidder her på V2, og fortæller dig hvordan du kan skrue et billigt tilbud sammen.

Jeg tror ikke på, at det kan skabes for håndøre, og jeg har svært ved at se formålet med at skabe et sådant system efter billigste løsning.

Hvad er det du egentlig vil skabe ?
Er formålet, at skabe 20 arbejdspladser, så er det bedre at beholde de eksisterende løsninger. Ellers skaber du jo arbejdsløshed, uden nogen anden gevinst, end at samfundet skal betale for yderligere mennesker på understøttelse.

Skaber du en løsning, hvor der kun indgår en serverløsning, med en kode og en database, samt nogen brugertilladelser, så skaber du ikke noget nyt, og det er dermed uden anden værdi, end at skabe arbejdsløshed, og gøre dette på billigste måde.

Jeg må indrømme, at det virker lidt "løst" hvad du vil, eller ikke vil.

Er du sikker på, at det er "skatteborgernes" interesse, du forsøger at varetage ?

  • 1
  • 2
Rene Nejsum

I forhold til mange andre systemer, er kravene til power og plads beskedne:
DB: 10.000.000 CPR/CVR numre og 50kB til hver = 500GB data (det kan ligge i RAM hvis man vil)
Transaktioner: 10 opdateringer per år per CPVR giver 3/sekund, ingen problem.
Søgning: 10 søgninger per døgn/CPVR = 1200/sekund,
Loggen: 100 b/søgning = 10GB/døgn = 400 GB/år
Båndbredde: 1200 søgning/sekund 'a 1 kB = 10Mbit

Det er alt sammen ikke mere end tre mindre cluster med HP/Dell servere kunne klar uden at komme til at svede. Pris under 2 Mkr.

Spørg evt. drengene fra Tradeshift.com. De har lavet et system med lignende krav, blot globalt og ikke til et lille bitte land. Pris under 100Mkr (40-50 ansatte i 2-3 år, incl. husleje, salg, marketing, drift og udvikling)

  • 1
  • 0
Anonym

@ Rene Nejsum

Hvor vil du stille disse servere ?
Hvordan vil du sikre disse servere, ikke kan oversvømmes, eller på anden måde gå ned.

Hvem mener du skal vedligeholde data, for slet ikke at tale om at oprete data. Vil du taste data ind for 5 millioner Danskere gratis ?
Hvem skal vedligeholde servere, osv.
Hvem skal overvåge og handle på de situationer der opstår.

Er Tradeshift kun 2 millioner kroner værd ?

Hvis du kan gøre det for 2 mill., så skal du bare gøre det.
Var det et tilbud ?

  • 0
  • 0
Daniel Madsen

Klavs: Jeg har designet enterprise-løsninger i den her skala og 2 mio. til udvikling kan du godt glemme.
Det er det offentlige vi har med at gøre her, du er nød til at hyre en mand fuld tid til bare at rende rundt og holde møder med forskellige instancer - det er ihvertfald den første mio. der ryger der (alternativt får du intet lavet).

1 mio. ~= 1 mandeår (medmindre du vil lave det hele selv fra din kælder)

Det kan godt være at den rene udviklingsdel vil kunne lade sig gøre på 1 mandeår, men for det første er du nød til at inddrage slutbrugerne i processen - ellers får du lavet noget de aldrig vil acceptere at bruge - der ligger en del arbejde blot i prototyping og det tager tid. Derudover skal du også regne en meget stor test-del ind i det her projekt for at opfylde kravene.

Desuden skal du have fundet ud af hvordan drift og deployment skal fungere (som ikke er helt trivielt når der ikke accepteres nedetid) og det er ikke noget der ligger udenfor din udvikling - det er vigtigt at det er tænkt ind i din software-løsning.

Desuden er du nød til at have en buffer at løbe på, specielt når du har med det offentlige at gøre - det nytter ikke at prisen er presset så meget i bund at det kun lige kan lade sig gøre.

Hvis du er ekspert på alle områder kan du muligvis selv designe det hele så det fungerer, men det er risikabelt - specielt fordi man meget nemt kommer til at dumme sig hvis man ikke får input fra andre i processen.

Jeg vil mene det er mest realistisk med et lille team på ca. 5 mand med forskellige ekspertise-kompetencer til at løse denne opgave. Det koster lidt mere end 2 mio. - men det koster betydeligt mindre end de min. 200 mio. CSC formentlig skal have.

  • 0
  • 1
Poul-Henning Kamp Blogger

Hvem mener du skal vedligeholde data, for slet ikke at tale om at oprete data. Vil du taste data ind for 5 millioner Danskere gratis ?

Det er udenfor den stillede opgave.

Men rent umiddelbart, ville det første man gjorde jo være at fortælle CPR registeret at de skulle spejle deres data over i det nye "persondatadepot". Det kan ikke tage mere end et par dages tid. Max to uger.

  • 1
  • 0
Rene Nejsum

@Thomas: De 2 Mkr er hardwaren til at drifte løsningen

Jeg vil leje mig ind hos nogle af de eksisterende hosting firmaer, herunder helt sikkert TDC's "tårn" uden for Århus. (Det hed DIR.dk indtil 2010) Jeg synes det er godt tænkt at bygge hosting op på 3-5 sal, så er oversvømmelses problemet løst.

Men, jeg antydede at det kunne gøres for under 100 Mkr :-)

  • 1
  • 0
Ole Kaas

Alle forslag indeholder en eller anden form for brug af en NoSQL database

Når jeg selv skal sige det, er jeg efterhånden ret ferm til et fjolle rundt med MySQL både på applikations niveau og på SQL niveua. MySQL kan også en lang række tricks til replikering, clustering og HA - dens største problem er nok licensen - eller rettere, hvad Oracle bestemmer sig for hvad den skal være i fremtiden...

For en hammer ligner alle problemer søm... Så for at for at få en hurtig ide om Cassandra (og NoSQL generelt) købte jeg for nyligt et video foredrag fra oreilly. Med det i baghovedet, passer oplæget ovenfor umiddelbart bedre ned i Cassandra end i MySQL. Ikke nok med at brugerne kan have custom felter, de kan også selv bestemme både antallet og størrelsen (og købe mere til). Som jeg forstår det, er det bare noget man gør i Cassandra mens jeg vil mene det umiddelbart er noget mere bøvlet i f.eks MySQL. Det er ikke fordi det er svært f.eks at lave en "Shopping Cart" i MySQL - men det er legende let at gøre det i Cassandra (Materilized View).

Skalering lader også til at være en hel del nemmere med Cassandra. Man smider bare en server mere ind i clusteret. Det kan man også med MySQL NDB - så længe der er lige mange i hver node group, lige antal i hver node group, sol og måne. I værste fald kan man risikere at skulle opgradere med 100% flere ressourcer hvor 20% hvade været rigeligt. En vigtig faktor kunne også være evnen til at skalere ned. Der er mange penge at spare hvis vi kan slukke for halvdelen af serverne i sommerferien - eller om natten for den sags skyld.

Det er vel heller ikke enten eller. Det kan sagtens være både og :)

  • 0
  • 0
Jesper Frimann

Det er altid sjovt at se programmører med skruetrækkere.

For at få lidt perspektiv i tingene, hvis man skal ud og bygge f.eks. tre Tier 4 datacentre, som alt andet end lige må være requirements med de oppetidskrav, der stilles her, så kan det snildt koste et mellem 200-300KUSD per kvadratmeter, hvis man skal kunne levere og køle f.eks. 10KW per kvadratmeter.
Så er der lige den viden der skal til at bygge noget sådant, det er ikke noget der hænger på træerne, for slet ikke at tale om at drifte et sådant datacenter.
Det er ikke bare lige.. lad mig give et par eksempler fra den virkelige verden, der viser hvor vigtig kvalificeret personale er.

Jeg har 3 gange stået på sidelinjen og set offentlige datacentre blevet bygget/opdateret af 'eksperter'. Første gang måtte man f.eks støvsuge alle serverne for gips støv, og jeg ved ikke hvor mange gange man måtte fylde inergen anlæget op fordi man ikke lige forstod at det at svejse i et datacenter der er i drift er et nono. For slet ikke at tale om at man lagde stærkstrømskablerne parallelt med alle netværks kablerne, så når man startede nogle af de strøm tunge maskiner, så røg alle netværksforbindelserne, det tog rigtig rigtig lang tid før man fandt ud af hvad problemet var.
Så var der opdateringen, hvor man brugte 10 Millioner på at opgradere kølings anlæget, opdateringen var så at bygge et nyt helt specifikt anlæg til at køle bladeserver farmen. Det var så ikke lige folk der forstod køling sådan rigtig, der havde med det at gøre, så der hvor UNIX serverne stod steg temperaturen til 50C+ i de racks, hvilket gjorde at der begyndte at ryge kort og komponenter i alle de her servers. Og ja ... Blade farmen var så under 10C.
Og så var der lige den sidste, hvor man fandt nogle rigtig gode og billige forkromede køleribber til gulvet man må ha' sparet minimum 10.000 kr. Problemet var så lige at forkromningen skallede af og blæste rundt og satte sig i alle serverne, og ja så begyndte tingene at kortslutte. Så efter at leverandøren havde været igang med at skille alle maskinerne støvsuge dem og skifte alle køleribberne ud. Så ja... var den besparelse vist brugt.

// Jesper

  • 2
  • 0
Daniel Madsen

Det kan godt være det er svært at finde hosting-centrer i Danmark der vil garantere 99,99% oppetid i en SLA, men ved at distribuere løsningen ud over 3 datacentrer i landet, skal du jo "blot" sikre at de andre kan tage over hvis en falder ud og så er det indenfor det realistiske at holde en sådan oppetid rent driftmæssigt (hvis vi ignorerer målrettede terror-angreb og den slags scenarier og forudsætter at softwaredelen er fejlfri)

Jeg forestiller mig at TDC Hosting eksempelvis vil være en meget god partner, de har prof. datacentrer over det meste af landet.
Det er tænkeligt de endda vil tilbyde det til en fordelagtig pris, alt andet lige er der prestige i at hoste centrale offentlige løsninger, så det vil kunne bruges markedsføringsmæssigt for dem.

Jeg forstår simpelthen ikke at I mener det er nødvendigt at bygge nye datacentrer med alt hvad det indebærer, men jeg begynder at forstå hvordan det lykkedes for nogle af de her projekter at ende ud med at koste adskillige 100 mio. kr. hvis man føler man er nød til at estimere nedgravning af fiberkabler og opførelse af datacentrer ind i budgettet for at levere en softwareløsning...

  • 4
  • 0
Anonym

@ Rene Nejsum.

Hvis du vil give et tilbud på 100 mill. Så tror jeg bare du skal gøre det.

Prøv at læse hvad Jesper Friman beskriver.

Dit forslag:
Jeg har "hørt om" en serverpark, der var monteret oppe i en høj bygning. Hvor der blev oversvømmelse oven over, og hele serverparken gik ned, da vandet pludselig væltede ned gennem loftet.
Da man ville læse backup ind, så var der en fejl i den forbindelse, og derfor måtte man delvis genskabe data ud fra de data der lå ude i alle klienterne.
Det var en stor virksomhed, og havde det ikke lykkedes at genskabe data ude fra klienterne, og accepterer de mangler der var og blev, så havde haft alvorlig national betydning.

Det er ikke en bolsjebutik ;)

Der er bygget enkelte centre, der er specielt sikrede, også i Danmark.
De er ikke bygget som noget andet.
Det er bare ikke en option, om der overhovedet kan opstå en revne i et fundament, for bare at beskrive hvordan den side af sagen skal håndteres.
Man kan ikke bare bestille en almindelig industri/kontor-bygning.

Det koster bare kassen.
Det gør ikke noget, at det koster kassen.
Kun hvis det ikke virker, så er der tale om spild.
Kun hvis pengene ryger ud af landet, er der tale om, at det er en større omkostning for Danmark. Ellers er det jo bare en omsætning, som oven i købet skaber Danske arbejdspladser, og skaber Dansk viden.

Hvis ikke vi skaber denne Danske viden, på alle planer, og i forbindelse med alle håndværk / teknikker. Så ender vi med at være tvunget til at købe alt i udlandet.

  • 2
  • 0
Jesper Frimann

KHP. Nu tror jeg personlig at du får svært ved at finde 3 Tier 4 datacentre med 100 km mellemrum. Og hvis du endelig gør bliver det ikke fra 1 leverandør, med det administrative bøvl du får ud af det.
Det er så slet ikke sikker på at leverandøren vil hoste dig i et Tier 4 center, uden at have fuld drift. Ellers hænger deres business case ikke sammen.
Og du kan være helt sikker på at alt der skal laves onsite kræver at du har en leverandør vagt/konsulent med, som du betaler for, der ikke laver andet end at verificere at du faktisk kun piller ved din egen maskiner.
Så det bliver dyrt.. rigtig dyrt.

// Jesper

  • 0
  • 0
Ole Kaas

Glem alt om egne datacentre - det giver simpelthen ikke mening til det her projek. Der findes allerede udmærkede datacentre med døgnvagt hvor man kan leje sig ind med eget rum/bur med egen adgangskontrol osv. Det koster ikke en bondegård.

Dem der mener at det skal hostes i egne centre kan blot komme med et bud på etablering og drift af sådan 3 stk. Så kan andre snuppe udregningen som en "add in option" på deres beregning.

  • 0
  • 1
Ole Kaas

Øv - redigér funktionen virkede ikke...

Det kunne være mere spændende at høre hvad folk ville bruge at teknologier til løsningen. Kan OAuth 2.0 f.eks bruges til at give andre adgang til egne data? hvorfor? hvorfor ikke? Hvad med afregning af dataforbrug - hvordan trækkes det ud og hvordan faktureres det? Hvor ofte faktureres og skal der være en bagatelgrænse eller skal der samles sammen til prisen kommer over 50kr? Er der værktøjer til det - eller skal vi selv opfinde nogen?

  • 0
  • 1
Rene Nejsum

Jeg forstår heller ikke behovet for at bygge nye datacentre. Det lykkedes jo for andre at drive bank, CPR register, skat, RKI, etc. i dag.

Som jeg læser PHK's udfordring er spørgsmålet: hvor meget bedre/billigere kan det gøres hvis man tilføre hjernekapacitet, ikke mursten.

  • 1
  • 1
Poul-Henning Kamp Blogger

Det koster bare kassen.
Det gør ikke noget, at det koster kassen.

Man kunne næsten få det indtryk at du lever af at sælge meget dyre hosting-kvadratmeter...

Din argumentation om at du engang kendte en hvis onkel havde hørt om nogen der havde gjort noget dumt er ikke relevant i denne sammenhæng, en af forudsætningerne for opgaven er netop at man tænker sig ordentligt om.

  • 0
  • 1
Asbjørn Laurberg

Umiddelbart synes jeg denne tråd har udviklet sig til det, der er det nemmeste at snakke om: hardware, internetforbindelser og hosting.

Man kunne godt savne at diskussionen måske mere kom til at omhandle, hvordan vi ser softwaren designet. Her tænker jeg f.eks. ikke på om der skal gøres brug af SQL eller NoSQL, og om der skal stå PostgreSQL eller Redis på serveren. Vi burde i stedet for kigge på det domæne løsningen skal arbejde i, og vi burde se, om vi kan grave nok information og viden op, om hvordan man i det offentlige måske kunne tænke sig at bruge et sådan system som PHK nævner i sit blogindlæg.

Når vi så har afdækket ovenstående emner, kan vi måske begynde at sætte en pris på udvikling, drift og forbrug. Alt andet er gætterier og spild af tid.

  • 2
  • 1
Anonym

@ Daniel Madsen.
Det er en mulighed, at bruge hosting-centre.
Men det er ikke det som beskrives i oplægget.

Der beskrives netop, at det skal være sikret imod terror og ekstreme forhold. Om så helvede bryder løs, eller der er skybrud, højvande og skrueis.
Der beskrives også nogen andre fysiske forhold, som selv TDC ikke kan stille op på.

En nedetid, på max. en time om året, medfører, at der reelt ikke er tid til at indlæse en backup, endsige fejlfinde på et sæt der er nede.

Hvad forsvarer disse ekstremer ?

Hvis det skal være en vare der kan bruges til eksport, så er disse ekstremer reelle.
Det skal virke, selv om der er krig, terror, jordskælv eller lignende.
Det skal også være forbundet sikkert, så selve systemet ikke forsvinder, selv om man forsøger at klippe tråden, so to speak.

Det gælder også i Danmark, at der er krav om 100 % sikkerhed.
Hvis hele samfundet er digitaliseret, så skal det være umuligt, ikke kun usandsynligt, at data forsvinder eller kun findes i en kompromitteret form.

  • 1
  • 1
Jesper Frimann

@Ole Kaas.
Oh, der er masser af gode datacentre. Daniel Madsen nævner f.eks. TDC hosting, jeg ved så ikke om Daniel nogensinde har været i et TDC hosting datacenter. Men de er ifølge dem selv er de Tier 3. Jaaahh.. ja..
Hvis man skal have bare den mindste chance for at kunne leve op til de ekstreme krav som PHK skriver her, så skal alt være top notch.

Jo højere oppetid du vil ha jo mere koster det. Og prisudviklingen er IKKE lineær.
Du får hvad du betaler for. Og jeg ved ikke rigtig om jeg skal grine eller græde når f.eks. folk som Rene Nejsum, skriver som han gør.
Det at drive en banks core systemer koster KASSEN.
Og så har vi Asbjørn Laurberg med kommentaren "der er det nemmeste at snakke om: hardware, internetforbindelser og hosting.". En IT løsning er så meget meget mere end bare 'koden' eller databasen. Det er derfor man normalt snakke om en løsning stak.

// Jesper

  • 0
  • 1
Ole Kaas

Hvis man skal have bare den mindste chance for at kunne leve op til de ekstreme krav som PHK skriver her, så skal alt være top notch.

Jeg læser kravene om 3 centre som at de netop ikke behøver at være super duper Tier 4 og certificeret af alle mulige ligegyldige konsulent firmaer. Hvis én lokation fejler, er der 2 andre til straks at overtage opgaven.

Som jeg læser det, er oppetiden for registeret - ikke for den enkelte lokation. Så selv hvis 2 af centrene skulle være brændt ned og oversvømmet, er vi pressede men stadig i luften.

  • 0
  • 0
Daniel Madsen

Jeg er helt enig med Ole og Asbjørn. Jeg mener fint at eks. TDC Hosting (eller andre leverandører) vil kunne løse opgaven - datasikkerheden skal jo netop ligge i at man distribuere dataene og dermed har vi ikke brug for super topnotch datacentrer, de skal bare være i kategorien "gode nok".

Men det stiller krav til softwaren at lave distribuerede løsninger, hvis softwaren er god nok er hardwaren mindre interessant - det burde Google efterhånden have lært os. Så ja, drop nu al den snak om datacentrer.

  • 0
  • 0
Klavs Klavsen

@Daniel:

Jeg har designet enterprise-løsninger i den her skala og 2 mio. til udvikling kan du godt glemme.

Jeg har trodsalt designet og driftet løsninger der driver nogen af de mest besøgte hjemmesider i DK (flere af dem i FDIMs topliste) - de er så bare ikke fordelt på flere fysiske lokationer - men mængden af forespørgsler vil jeg mene er væsentligt højere end CPRs.

Så jo - jeg er rimelig sikker på at det ikke er så kompleks en opgave det her.

Det er det offentlige vi har med at gøre her, du er nød til at hyre en mand fuld tid til bare at rende rundt og holde møder med forskellige instancer - det er ihvertfald den første mio. der ryger der (alternativt får du intet lavet).

Her er vi helt enige. Jeg har også erfaringer med konsulentopgaver for det offentlige, og sådanne laver jeg helst ikke uden en god politisk-kyndig person med på opgaven. Det er ganske sørgeligt at de kan gå op i politik, når det ellers burde være en sten-klar teknik opgave :)

PHKs opgave nævner intet om politik - og jeg skrev også at det forudsatte at mit mere detaljerede designoplæg (der levede op til kravene) blev godkendt, uden alt det fis du nævner.

1 mio. ~= 1 mandeår (medmindre du vil lave det hele selv fra din kælder)

Det kan godt være at den rene udviklingsdel vil kunne lade sig gøre på 1 mandeår, men for det første er du nød til at inddrage slutbrugerne i processen - ellers får du lavet noget de aldrig vil acceptere at bruge - der ligger en del arbejde blot i prototyping og det tager tid.

Den smule gui der evt. er behov for her er så lille så det er meningsløst at prototype det. PHK nævner specifikt at de skal vedligeholde det via et API - det kunne f.ex. være SOAP baseret - så er der ingen GUI overhovedet :)

Derudover skal du også regne en meget stor test-del ind i det her projekt for at opfylde kravene.

Så svært er det nu ikke at teste hverken performance eller failover, og som jeg skrev ville jeg starte med at teste de forskellige DB-backend løsninger op imod de relevante krav, for at flush div. problemer ud og bekræfte teser.

Ligesom jeg selvf. hiver fiber forbindelser og andet ud, når vi tester at div. multipath opsætninger fejler over som det skal.

Desuden skal du have fundet ud af hvordan drift og deployment skal fungere (som ikke er helt trivielt når der ikke accepteres nedetid) og det er ikke noget der ligger udenfor din udvikling - det er vigtigt at det er tænkt ind i din software-løsning.

Nå.. var det mon derfor jeg netop skrev jeg ville teste setup'et af hurtigst muligt, for at udvælge den bedste løsning til opgaven (primært failover/data-replikering mellem de 3 lokationer er den "tricky" ting, mht. hvordan der reageres på pakketab osv.) Ikke noget jeg ikke har prøvet før - dog på samme lokation.

Desuden er du nød til at have en buffer at løbe på, specielt når du har med det offentlige at gøre - det nytter ikke at prisen er presset så meget i bund at det kun lige kan lade sig gøre.

Nu gik jeg udfra de krav PHK stillede (og spurgte lidt om krav til replikeringen) og så ville det selvf. kun være det jeg leverede. Hvis de har flere krav, kan det selvf. komme til at koste ekstra.

Så jeg mener faktisk jeg har rimelig pæn luft i mit budget.

Hvis du er ekspert på alle områder kan du muligvis selv designe det hele så det fungerer, men det er risikabelt - specielt fordi man meget nemt kommer til at dumme sig hvis man ikke får input fra andre i processen.

Jeg vil mene det er mest realistisk med et lille team på ca. 5 mand med forskellige ekspertise-kompetencer til at løse denne opgave. Det koster lidt mere end 2 mio. - men det koster betydeligt mindre end de min. 200 mio. CSC formentlig skal have.

Man kunne f.ex. ligge et design dokument op på version2 og få noget feedback - jeg vil vædde på at mange godt ville komme med konstruktive kommentarer - og uanset - så vil jeg foretrække at lade de forskellige muligheder blive vurderet på faktiske performance tests.

Man kunne godt være 2 på opgaven og nå det på ca. ½ år - mere end det, bliver nok et problem, da opgaven så vil tage længere tid, da ressourcer jo ikke skalerer specielt godt i den slags projekter :)

  • 1
  • 0
Poul-Henning Kamp Blogger

Bare lige for at bringe diskussionen ud af dette dødvande:

Thomas er alt for mustensfokuseret og han har tydeligvis ikke begreb skabt om hvordan man med tre gode hostingcentre får bedre oppetid end med et forgyldt hostingcenter.

De antages at de tre driftcentre er driftsredundante, således at selv hvis et oversvømmes og et andet rammes af inkompetence, så afbryder det ikke driften.

Mht til at læse backups ind: Det skulle meget nødig være en del af designet at man nogensinde skulle få brug derfor. Overvej snapshots som alternativ hvis softwaren ikke kan håndtere situationen på anden vis.

Videre.

  • 2
  • 0
Jesper Frimann

Man kunne næsten få det indtryk at du lever af at sælge meget dyre hosting-kvadratmeter...

Det var faktisk en kommentar under bæltestedet, efter min mening. Thomas er en af de få i denne her snak, der faktisk virker, som om at han ved, hvad han snakker om.

Og det kan da godt være, at Thomas arbejder et sted der sælger Hosting, så meget mere relevant er han viden jo. Det er jo ikke en snak om rigtig eller forkert, du har bedt om, men mere om en RF[I|V] (Request For Information/Viden), men jeg har måske taget fejl ?

// Jesper

  • 0
  • 0
Anonym

@ Poul-Henning Kamp.

Nej, jeg beskæftiger mig ikke med at sælge hosting-rum.
Jeg deltager ikke engang i at bygge dem.

" Din argumentation om at du engang kendte en hvis onkel havde hørt om nogen der havde gjort noget dumt er ikke relevant i denne sammenhæng, en af forudsætningerne for opgaven er netop at man tænker sig ordentligt om."

Det er i aller højeste grad relevant. Der var tale om en MEGET stor virksomhed i Danmark, der var ikke tale om at "Henning hvem som helst", havde trollet et anlæg sammen. Jeg har ikke engang hørt om nogen, der var større inden for konstruktion og drift af den slags anlæg.
Hvem er du, som mener at andre der beskæftiger sig med den slags, gør dumme ting ?

Har du nogen sinde været i et serverrum ?
Har du arbejdet i et serverrum ?
Er du klar over hvordan et sådan anlæg bygges og drives ?
Tror du, at verdens største aktører på området, er idioter ?
Du kan være 100 % sikker på, at dem der kan og vil levere den slags løsninger, har en hel del mere ekspertise, end det vi kan trolle sammen her på V2.
Der kræver en maskinmestereksamen med autorisation i el og køle, alene for at kunne forestå drift og vedligeholdelse af sådan et rum.
Og her er der kun tale om rum, der drives af private virksomheder, med den sikkerhed der kræves i den forbindelse.

En anden beskrev en pris på mindst 200.000 USD / m2.
3 meget små serverrum, betyder i den forbindelse 300 m2.
Jeg tror ikke engang det er muligt i den størrelse, men lad det nu bare være størrelsen.
Så er den pris alene 60 mill USD, eller rundt regnet 360 mill. kr. Og så er der ikke plads til kontor og tilhørende faciliteter.
Og rummene er stadigvæk ikke i drift.
Mere realistisk vil der være, med rum mindst dobbelt så store.

Du beskriver noget, som kræver ekstremer.
Ikke kun fordi du beskriver noget du har fundet på, men simpelthen fordi det, i sig selv, kræver ekstrem sikkerhed.

Du regner med, at det kan gøres for en slik. Det kan det bare ikke.
Det kan måske gøres lidt billigere end normalt, under observation af, det måske også kan gøres lidt sikrere end normalt.
Jeg tror ikke engang, at dit oplæg er optimalt. Jeg ville vælge en anden vinkel på hele opgaven. Men nu er det dit oplæg vi diskuterer.

Du har 100 % ret i, at det bør være Staten der ejer løsningen !
Du har 100 % ret i, at det skal være 100 % sikkert, både fysisk og i forhold til kode og data !

Kom ind i Kampen Henning.

  • 1
  • 2
Poul-Henning Kamp Blogger

Har du nogen sinde været i et serverrum ?
Har du arbejdet i et serverrum ?
Er du klar over hvordan et sådan anlæg bygges og drives ?
Tror du, at verdens største aktører på området, er idioter ?

Hvis jeg nu fortæller dig, at første gang jeg egenhændigt planlagde installation i et serverrum af en computer der kostede mere 10 gange mere end mindstelønnen var i 1988, behøver jeg så svare på resten af dine spørgsmål ?

Jeg kan også fortælle dig, at din opfattelse af virkeligheden strider imod fakta på jorden for mig og formodentlig en hel del andre i branchen.

Hvornår planlagde du første gang en installation i et serverrum ?

  • 1
  • 0
Søren Vind

De stillede krav betyder at man skal forvente maskinnedbrud og leve med dem - det er præcis de krav et datastore som HBase er bygget til, så det kan man jo tage udgangspunkt i. HBase er desuden karakteriseret ved at man kan tilføje kolonner til sin "database" som man måtte ønske uden at ændre skemaet og rammer derfor lige ned i krav 3 og 6. Da det benyttes i stor skala af Facebook og Yahoo til at servere nær-realtime søgeresultater er jeg også tilbøjelig til at tro at det nok kan klare denne opgave. Skalering af plads/performance er nær-lineær.

HBase er beregnet til at være en dygtig distribueret database i et datacenter, men er ikke umiddelbart bygget til at fungere fornuftigt på tværs af datacentre. Derfor giver det som udgangspunkt et krav til den ovenliggende implementation: Den skal kunne håndtere skrivning og synkronisering til flere HBase clustre, og en ændring til registret skal selvfølgelig først godkendes når applikationen har fået svar fra mindst to clustre.

For at indbygge redundans på rackniveau kan vi så forestille os 3 clustre med hver 20 servere fordelt i 4 racks til at drifte den bagvedliggende database. Fyld hver op med 4x1TB diske, og du har ~25TB brugbar dataplads tripel-spejlet i hvert datacenter. Det kan i USA eller Holland gøres til rundt regnet 2000kr/server/mdr ved lejede servere i yderst seriøse datacentre, men nu er vi i Danmark så lad os bare regne med 10000kr/server/mdr og regne med at det dækker indkøb af serverne samt reservedele og lejet hosting. Altså en årlig udgift på indkøb, hosting og drift på 10mio rundet op. Jeg vil vædde på at det er muligt at finde 3 seriøse datacentre i København, Odense og Aarhus med indbyrdes ikke-sammenfaldende upstreams (og ikke-sammenfaldende ejere) der er villige til at drifte 20 maskiner i et år for godt 3mio.

Den ovenliggende applikation skal selvfølgelig også have en stak maskiner at køre på, så lad os bare sige at et cluster i samme størrelse er nødvendigt i hvert datacenter (dette skulle gerne være nok til at inkludere diverse serviceopgaver). Så kan vi også skifte maskiner mellem hver clustertype som vi har lyst til, og reservedelsproblematikken forsvinder. Hvis man skal bruge mere end 20mio på at drifte selve maskinerne på et år skal man godt nok frådse med ressourcerne - det skulle meget gerne også inkludere 3 kompetente sysadmins.

Med ovenstående setup bør det være uproblematisk at tage enkelte maskiner (og sådan set også hele racks) ned for at udføre service. Jeg ser ikke umiddelbart nogen grund til at gøre meget ud af at clustre den ovenliggende applikation i lige så stor stil - en loadbalancer foran (i hvert datacenter) skulle være nok til at sprede requests og tage fejlende maskiner ud af drift.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize