Nødhjælp til rødglødende servere: Nyt dansk firma laver kø i skyen

Der er godt nyt på vej til Skat og Billetnet. En ny cloud-løsning fra danske Fourkant leder automatisk besøgende over i en kø i skyen, når spidsbelastningen på en hjemmeside bliver for stor.

Du kender sikkert problemerne med at få købt billetten til U2-koncerten eller tjekket restskatten online, fordi titusindvis af brugere bestormer hjemmesiden og tvinger den bagvedliggende webserver i knæ.

Lange svartider er nærmere reglen end undtagelsen, og for at løse dét problem har den nystartede, danske virksomhed Fourkant udviklet det cloud-baserede køsystem Queue-it, der fungerer som den digitale version af træk-et-nummer på apoteket eller posthuset.

Queue-it lægger sig mellem brugeren og den hjemmeside, der skal sikres mod overbelastning. Overstiges serverens kapacitet, føres de seneste tilkomne brugere automatisk ud i en kø placeret i skyen.

»Vi fører de brugere, der ikke er kapacitet til, væk fra den hjemmeside, som skal beskyttes. De bliver placeret i vores kø i skyen med et nummer og bliver så sendt tilbage til hjemmesiden efter tur, når der igen er kapacitet til det på serveren,« fortæller partner i Fourkant, Camilla Ley Valentin, til Version2.

Queue-it er baseret på Amazon-platformen Web Services, og i tilfælde af kø ved indgangen til webserveren bliver brugeren præsenteret for et link, der fører videre til en hjemmeside, som viser brugerens plads i køen.

Brugeren kan også vælge at få tilsendt sin plads i køen per e-mail eller sms, og det er ifølge Camilla Ley Valentin de eneste to tilfælde, hvor Queue-it rent faktisk gemmer informationer om brugeren.

»Udover det har vi ikke nogle data om brugeren liggende i skyen, og hvis brugeren har prøvet at tilgå en hjemmeside med login, vil login'et først ske, når man er ude af køen igen. Vi integrerer heller ikke på nogen måde med de bagvedliggende systemer for hjemmesiden,« siger Camilla Ley Valentin.

Skat.dk i svære serverproblemer

Version2 har flere gange beskrevet skat.dk's problemer med at betjene borgerne, når årsopgørelsen og forskudsopgørelsen bliver frigivet digitalt.

**LÆS OGSÅ: **Ukendt flaskehals driller: Forskudsopgørelsen tvinger Skats servere i knæ

Også hjemmesider som billetnet.dk har ind i mellem kvaler med at betjene kunderne, når billetter til store koncerter herhjemme bliver sat til salg online.

Ifølge Camilla Ley Valentin aftales det med den enkelte kunde, hvad svartiden skal være på serveren, før Queue-it træder i kraft og forsyner den besøgende med et link til køen i skyen.

Men hvordan har I testet, at jeres løsning rent faktisk kan håndtere de store belastninger, man oplever på for eksempel skat.dk eller billetnet.dk?

»Vi har kørt live hos Skov- og Naturstyrelsen. Hvert år skal 170.000 danske jægere indberette, hvor meget vildt de har skudt, og Skov- og Naturstyrelsens bagvedliggende system er hidtil brudt ned hvert år, hvilket ikke er sket med vores løsning.«

»Derudover har vi testet koncertscenariet ved at sætte en række Amazon-servere op med testagenter, som hver har simuleret et par tusinde brugere, så det passer med i alt omkring 100.000 brugere, som venter på at komme ind på en hjemmeside.«

Hvem er jeres kunder?
»Udover Skov- og Naturstyrelsen er der er flere af de centrale, offentlige hjemmesideejere, som er meget interesserede, og som vi er i dialog med. Derudover er vi også i dialog med i hvert fald én af de virksomheder, du har nævnt (Skat og Billetnet, red.).«

Hvordan er jeres prismodel?
»Man betaler et månedligt abonnement, og derudover betaler man en billetafgift for hver billet, der bliver udstedt, når der opstår kø under spidsbelastning. Så det er en typisk cloud-model, hvor man betaler for det, man får.«

»Ser man det i forhold til, at for eksempel Skat senest har udvidet serverkapaciteten med 25 procent (i forbindelse med frigivelsen af årsopgørelsen 2009, red.), vil vores pris til sammenligning udgøre en promille af den investering.«

Hvem er jeres konkurrenter?
»Ifølge de analyser, vi har fået foretaget, er der er ikke andre, der har fremstillet samme løsning. Selvfølgelig er der altid konkurrence, men lige nu er det vores kunders nuværende it-leverandør, som selvfølgelig hellere vil sælge noget mere serverkapacitet eller virtualisering til kunden,« siger Camilla Ley Valentin.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ricki Gregersen

Det lyder som en god ide.
I forbindelse med lige præcis Billetnet kunne man også forestille sig at gav en større retfærdighedsfølelse hos kunderne. Jeg oplever ofte situationen med at sidde klar til at trykke refresh i min browser som rent lotteri.
Faktisk burde løsningen tage over så snart brugeren klikkede "køb billet" og allerede der tildele et kø-nummer, istedet for at vente til svartiden på serveren faldt:)

Det forekommer mig også, især, i forbindelse med Skat at det er lidt vanvittigt at investere millioner i hardware for at kunne modstå en belastning der forekommer 1 gang om året. Jeg kan som regel godt vente et par dage med at få af vide hvad jeg skal bidrage med til skats IT-udvikling for i år:)

Held og lykke med det!

  • 0
  • 0
Peter Nørregaard Blogger

Det er en ret spændende løsning, som jeg havde en blog på tegnebrættet om. Men artiklen kom i forkøbet og præsenterer løsningen udmærket.

Et af de seneste eksempler på nedbrud er Roskildefestivallens booknings-system: http://ibyen.dk/fokus/roskildefestival/article973040.ece

Den store tilstrømning kommer sjældent som en overraskelse, og flertallet af sites forbereder sig da også på de store dage ved at udvidde kapaciteten på serverne. De fleste nyere it-systemer i dag kan håndtere at blive afviklet på flere servere i parallel. Men for det første er det ikke alle (Skov- og naturstyrelsens ældre system inkluderet) og for det andet er det ofte ikke nok til at kunne behandle [i]alle[/i] forespørgslerne, der jo kan peake helt uforudsigeligt.

Den væsentligste årsag til at bruge en løsning som Queue-it er, at det ofte er alt for dyrt at åbne for nok kapacitet, da de færreste driftsleverandører kan tilbyde prisbillig, dynamisk skalering baseret på moden virtualisering endnu.

Løsningen er elegant i sin simple, nede-på-jorden tilgang til et kendt og irriterende problem. Jeg håber, at de fire iværksættere får god afsætning af produktet, både få deres egen skyld, men også så vi brugere kan få en bedre og mere smidig betjening på nettet. Og så kan vi som it-professionelle i tilgift måske en dag slippe for at høre på "morsomme" historier ved festlige lejligheder om de %&£* belastnings-baserede it-nedbrud, der hjemsøger vores branche og vores profession :-)

  • 0
  • 0
Nikolaj Brinch Jørgensen

Det forekommer mig også, især, i forbindelse med Skat at det er lidt vanvittigt at investere millioner i hardware for at kunne modstå en belastning der forekommer 1 gang om året. Jeg kan som regel godt vente et par dage med at få af vide hvad jeg skal bidrage med til skats IT-udvikling for i år:)

Det jeg ikke forstår er at SKAT m.fl. ikke selv bruger Cloud til netop at imødekomme de par gange om året hvor der er run på, således at dette ville ske automatisk.
Systemet der er beskrevet er et workaround for dårligt udarbejdede løsninger i det offentlige.
Billetnet/Billetlugen/Roskildefestivalen, skal bare tage sig sammen og få benyttet Clouding til dynamisk at allokere serverkraft og lade være med at gå ned.

Det er på ingen måde raketvidenskab, og ligger ligefor, det er viljen der mangler.

Den væsentligste årsag til at bruge en løsning som Queue-it er, at det ofte er alt for dyrt at åbne for nok kapacitet, da de færreste driftsleverandører kan tilbyde prisbillig, dynamisk skalering baseret på moden virtualisering endnu.

Dette er problemet for DANSKE forstokkede leverandører som har sovet i timen. Der findes mængder af leverandører som kan levere.

  • 0
  • 0
Peter Nørregaard Blogger

Dette er problemet for DANSKE forstokkede leverandører som har sovet i timen. Der findes mængder af leverandører som kan levere.

Nu går de færreste hen og skifter drift-leverandør uden videre, det er en ret tung proces. Der skal mere til, end at ens nuværende leverandør er 6-12 måneder bagud i udvikling af en virtualiserings-service.

Desuden tror jeg ikke de danske leverandører er mere forstokkede end andre, måske er de bare mindre i volumen.

Systemet der er beskrevet er et workaround for dårligt udarbejdede løsninger i det offentlige.
Billetnet/Billetlugen/Roskildefestivalen, skal bare tage sig sammen og få benyttet Clouding til dynamisk at allokere serverkraft og lade være med at gå ned.
Det er på ingen måde raketvidenskab, og ligger ligefor, det er viljen der mangler.

Ja, det er en workaround. Og en billig en, der er nem at implementere, derfor er det en fed løsning.

Uanset forberedelse, så [i]er[/i] de helt vilde peaks svære at tage højde for. Og massivt parallelle systemer, der skal slås om fælles ressourcer (fx biletter), er faktisk raketvidenskab :-)

  • 0
  • 0
Nikolaj Brinch Jørgensen

Der skal mere til, end at ens nuværende leverandør er 6-12 måneder bagud i udvikling af en virtualiserings-service.

Jeg vil mene flere af dem er langt længere bagud. Dertil kommer så udbud fra det offentlige som stadig behandles som for 10 år siden på hardware specifikationssiden.
Virtualisering har altså været tilgængeligt længe (VMWare holdt indlæg på JAOO i 2005, og der var det ikke specielt nyt).

Desuden tror jeg ikke de danske leverandører er mere forstokkede end andre, måske er de bare mindre i volumen.

Har du prøvet at arbejde sammen med dem. Jeg ved du kommer fra Rambøll, det er også den eneste af de store jeg har arbejdet sammen med, som kan lidt. Men der går generelt alt for meget SAN og fysiske maskiner i den.

Ja, det er en workaround. Og en billig en, der er nem at implementere, derfor er det en fed løsning.

Ja hvis man holder af ikke at tage fat om nældens rod, og få lavet det ordenligt fra starten.

Uanset forberedelse, så er de helt vilde peaks svære at tage højde for.

Hmmm, det sjove er at en masse sagtens kan få det til at virke fornuftigt, og har dokumenteret det. Danmark er uendeligt lille i den sammenhæng.

Og massivt parallelle systemer, der skal slås om fælles ressourcer (fx biletter), er faktisk raketvidenskab :-)

Der er forskel på hvorledes vi så betegner noget som er raketvidenskab. Massivt parallelle systemer er der vel næppe tale om?

Billetter er en ting. Der er løst måske 1000 gange før. Men det ville jo koste penge og vilje at finde ud af hvordan.
At SKATs hjemmeside går ned, tyder på at de simpelthen ikke kan allokere kræfter nok til at besvare antallet af brugere, det kan dynamisk skalering klarer temmelig nemt, hvis ellers driftsleverandøren kan. Men det kan de ikke og det er heller ikke i de 4-5 årige kontrakter. Ligesom viljen mangler (Det er jo ikke et problem for SKAT, men et problem borgeren).

  • 0
  • 0
Ricki Gregersen

Det jeg ikke forstår er at SKAT m.fl. ikke selv bruger Cloud til netop at imødekomme de par gange om året hvor der er run på, således at dette ville ske automatisk.
Systemet der er beskrevet er et workaround for dårligt udarbejdede løsninger i det offentlige.
Billetnet/Billetlugen/Roskildefestivalen, skal bare tage sig sammen og få benyttet Clouding til dynamisk at allokere serverkraft og lade være med at gå ned.

Det er netop min pointe… hvorfor investere i en stor cloud baseret løsning for de 3-4 dage om året hvor der er tryk på? Det er efter min mening ikke bedre end at investere i mere hardware for de overstående 3-4 dage.
Der er mange der får det til at lyde som om "cloud" er en "silver bullet" der bare klarer alt. Det har også udgifter, dit system skal være i stand til at køre i det virtuelle miljø en udbyder har sat op. Det offentlige har også for vane at bygge deres egne systemer i stedet for at bruge hyldevarer, så de står nok overfor at skulle opdatere mange steder før det er "cloud n' play".

Jeg kan godt forstå hvis Skat og andre offentlige institutioner slår bremsen i en gang i mellem og gerne vil have deres investering til at køre til den er betalt tilbage. Jeg tror oftest ikke de er 10 år bagud, så ville de jo kunne købe gennemtestede standard systemer, jeg tror nærmere de mener de har så specielle behov at de må have custom udviklede systemer til alt, det kan godt være svært at kombinere det med "plug n' cloud".

Jeg kunne også godt forstille mig der var nogle, sikkert forældede, regler omkring at sende danske borgeres oplysninger op i skyen som lige skal revurderes.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Det er netop min pointe… hvorfor investere i en stor cloud baseret løsning for de 3-4 dage om året hvor der er tryk på? Det er efter min mening ikke bedre end at investere i mere hardware for de overstående 3-4 dage.

Fordi det i længden er billigere. I dag dimensioneres til gennemsnitbrug. Det er unødvendigt. Om natten kan systemerne sådan set gå på standby, og hardwaren kan overgå til batchkørsler af andre ting, såsom kørsler af lønsedler osv. Det er fordelen, og det giver enormt billig drift - hvilket afspejles i prisen på løsningen.

Der er mange der får det til at lyde som om "cloud" er en "silver bullet" der bare klarer alt. Det har også udgifter, dit system skal være i stand til at køre i det virtuelle miljø en udbyder har sat op./quote]Nej det er ikke en silver bullet. Men det kan løse en hel del problemer, bla. dynamisk skalering, som vil give grønnere og billigere IT, det er værd at satse på. Der er selvfølgelig også elementer der er nye og som man skal sætte sig ind i. men det er der også hvis man kun har programmeret COBOL og nu stilles overfor C# og .NET i en SOA.

[quote]Jeg kan godt forstå hvis Skat og andre offentlige institutioner slår bremsen i en gang i mellem og gerne vil have deres investering til at køre til den er betalt tilbage.

Har du nogle eksempler på dette? At det er bevidst og at løsningerne har betalt sig tilbage. Har du arbejdet med f.eks. SKAT?

Jeg tror oftest ikke de er 10 år bagud, så ville de jo kunne købe gennemtestede standard systemer, jeg tror nærmere de mener de har så specielle behov at de må have custom udviklede systemer til alt, det kan godt være svært at kombinere det med "plug n' cloud".

SKAT systemmodernisering er bygget på BEA/Oracle WebLogic 9.2 platformen. Den kan i den grad kører i Cloud. Det er ikke gratis at bygge til Cloud, men er det dyrere end at bygge til CSC/KMD/Rambøll/<indsæt dansk driftsleverandør - typisk med HP hardware - efter behov> drift på fysiske servere? Nej det er det ikke. Det er oftest mange gange billigere.

Jeg kunne også godt forstille mig der var nogle, sikkert forældede, regler omkring at sende danske borgeres oplysninger op i skyen som lige skal revurderes.

Jeg er ikke helt med - hvad er det ved Cloud du mener der går imod danske regler? Cloud bygger på at vi deler den underliggende hardware (sådan som vi har gjort på Mainframe i et ½ århundrede), så den kan skaleres op når der er brug for den, hvordan er det du mener der kan være danske regler i mod det?

  • 0
  • 0
Martin Seebach

Det er simpelthen en hån mod IT-faget overhovedet at acceptere at selvbetjening på nettet er noget man skal stå i kø til.

Salg af billetter har éen delt ressource, antallet af u-solgte billetter. Det er IKKE rocket-science, det er "Transaktioner for Dummies", kapitel 1. Standard-funktionalitet i alle databaser. Billetlugen og venner gemmer sig bag ved et røgslør af "uhh, sådan noget med computere er svært" der dækker over ganske simpel inkompetence.

Skat er næsten værre. Årsopgørelsen er en i forvejen batch-genereret PDF - eller det var den i hvert fald den gang den blev sendt ud med post. Der er tale om et login og en download af statisk fil. Antallet af delte ressourcer (til skrivning): Nul.

  • 0
  • 0
Peter Nørregaard Blogger

Det er simpelthen en hån mod IT-faget overhovedet at acceptere at selvbetjening på nettet er noget man skal stå i kø til.

Det er vel værre - et forsmædeligt nederlag for it-faget - at blive mødt med en blank skærm på grund af overbelastning? For det er realiteten for mange systemer i dag. Så kan man mene, at de skulle have været designet anderledes og med mulighed for uendelig skalering indbygget - fint nok, og nemt at være enig i, men det er et noget akademisk synspunkt, for det ændrer ikke på realiteterne for mange systemer i dag. Her er alternativet reelt at stå i kø!

Faktum er, at det ville koste en formue at ændre systemerne til at kunne håndtere spidsbelastninger og at et kø-system er et nem og billig måde at lave en workaround på.

Salg af billetter har éen delt ressource, antallet af u-solgte billetter. Det er IKKE rocket-science, det er "Transaktioner for Dummies", kapitel 1. Standard-funktionalitet i alle databaser.

Det er sikkert en udmærket metode at uddele pinocchiokugler efter, men er i andre sammenhænge et forsimplet syn på tingene. Et it-system, der ikke tillod dig at vælge din plads til næste landskamp, men blot lod alle biletter være ens, ville du ganske sikkert ikke være tilfreds med. Jeg mener heller ikke at have set Amadeus-systemet omtalt i "Transaktioner for Dummies"...

  • 0
  • 0
Nikolaj Brinch Jørgensen

@Peter

men det er et noget akademisk synspunkt

Hvorfor er det akedemisk. Der er da masser af sites som skalere fint til mange brugere, rigtig mange endda. De er da ikke akademiske.
Der er iøvrigt ikke brug for uendelig skalering. Kun til den mængde brugere som vil tilgå systemet. Når det gælder download af statiske data (som SKAT), så kan jeg ikke se at det vil være kæmpe dyrt at lave thresholds for start og stop af flere instanser og dynamisk load balancing?

Faktum er, at det ville koste en formue at ændre systemerne til at kunne håndtere spidsbelastninger og at et kø-system er et nem og billig måde at lave en workaround på

Hvordan er det du mener dette vil koste en formue - det kan du umuligt have fornuftigt belæg for at sige? Ellers må du meget gerne fremlægge det. Jeg ser det i hvert fald ikke.

Det er sikkert en udmærket metode at uddele pinocchiokugler efter, men er i andre sammenhænge et forsimplet syn på tingene. Et it-system, der ikke tillod dig at vælge din plads til næste landskamp, men blot lod alle biletter være ens, ville du ganske sikkert ikke være tilfreds med. Jeg mener heller ikke at have set Amadeus-systemet omtalt i "Transaktioner for Dummies"...

Jeg vidste ikke at Queue-It er implementeret på Amadeus?

  • 0
  • 0
Peter Nørregaard Blogger

Hvorfor er det akedemisk. Der er da masser af sites som skalere fint til mange brugere, rigtig mange endda. De er da ikke akademiske.

Situationen med sites, der rent faktisk ikke kan håndtere spidsbelastningerne, kan man da godt skælde ud på. Men det er akademisk at diskutere at de burde have være lavet anderledes, når de nu ikke er det. Det kan næppe være svært at forstå.

Hvordan er det du mener dette vil koste en formue - det kan du umuligt have fornuftigt belæg for at sige? Ellers må du meget gerne fremlægge det. Jeg ser det i hvert fald ikke

Et eksempel: En af mine kunder har et system som ikke kan skalere op. De kan enten forsøge at ombygge det (estimat: en lille million - det er en forældet teknologi som er svært at finde folk til) eller at sætte en kø-mekanisme foran indtil der skal laves et nyt system om et par år.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Situationen med sites, der rent faktisk ikke kan håndtere spidsbelastningerne, kan man da godt skælde ud på. Men det er akademisk at diskutere at de burde have være lavet anderledes, når de nu ikke er det. Det kan næppe være svært at forstå.

Det synes du så. Jeg skælder ikke ud, jeg forventer bare at udbydere som jeg skal betale til og være kunde hos, løbende forbedrer deres service, så det kommer mig til gode. Samtidigt håber jeg da at man vil tage ved lære af disse bølere, så det kan undgås i fremtiden. At du ser kø som en fremtidig løsning, og ikke en workaround, indtil man har lært sig ny teknologi og fået rette op på problemet, kan du vel næppe kalde akedemisk. Jeg tror ordet er bagstræberisk ;-)

Et eksempel: En af mine kunder har et system som ikke kan skalere op. De kan enten forsøge at ombygge det (estimat: en lille million - det er en forældet teknologi som er svært at finde folk til) eller at sætte en kø-mekanisme foran indtil der skal laves et nyt system om et par år.

Ok det er fint med et eksempel, og jeg vil næsten godtage det. Dog ville det jo være interessant at vide hvornår Queue-It render ind i 1 mio. kroner på den løsning.
Men det ser da ud til at vi er enige alligevel. At der skal laves et system i stedet for Queue-It på lang sigt, og at det er en work around.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Det er sikkert en udmærket metode at uddele pinocchiokugler efter, men er i andre sammenhænge et forsimplet syn på tingene. Et it-system, der ikke tillod dig at vælge din plads til næste landskamp, men blot lod alle biletter være ens, ville du ganske sikkert ikke være tilfreds med. Jeg mener heller ikke at have set Amadeus-systemet omtalt i "Transaktioner for Dummies"...

Det ser ifølge Queue-It's video ikke ud til at de kan løse problemet med sædebestilling. Det ville også være meget sært om de kunne, da de jo bare giver et stykke infrastruktur (et subset af messaging), som er asynkront.

PS: Desuden bygger deres video demo på at man KAN tilgå website hos f.eks. ticketmaster og udføre submit af ordren, hvorefter Queue-It sætter ind og tilbyder en transaktionskø. Nu er det sådan at de fleste sites har problemer med overhovedet at lade folk komme ind på sitet, ved spidsbelastninger, disse skal afhjælpes først. Det kan være Queue-It hjælper med det, men det beskrives ikke særlig godt.
Hvis dette virker (at man flyttes fra sitet og kan flyttes tilbage når der er plads), forstår jeg ikke hvordan man reserveres en plads på sitet, og hvor længe (så andre i køen ikke kan komme til indtil jeg har shoppet færdig), specielt ikke hvis jeg får det på SMS, og skal til at logge ind igen og andre bare må vente på mig - er der nogen der kan forklare det?

kø-mekanisme foran indtil der skal laves et nyt system om et par år.

Kø-mekanismen sidder i Queue-It's video ikke foran, men bagved - nøjagtigt som enhver anden transaktionskø. Hvis videoen er beskrivelsen af hvad de har, så er det en ganske almindelig transaktionskø som bygger på optimistic concurrency begreberne, som vi har set så mange gange før, men nu som en SaaS/abonnementsløsning i Cloud. Problematikken er at mange systemer kan indføre den slags temmelig simpelt allerede, så deres systemer smider transaktionerne over et stykke middleware (hos dem selv vel at mærke), der afhjælper belastningen ved at være asynkront.

  • 0
  • 0
Leif Neland

Hvorfor skal muligheden for at komme til koncert være afhængig af at man har adgang til en pc i perioden mellem tirsdag 10:00 når salget åbner og 10:07, når der er udsolgt, hvis ellers systemet ikke bryder sammen.

Lad der være åbent i en periode, f.ex. 24 timer eller et par dage, hvor man med sit betalingskort "betaler" for billetten.

Når perioden er afsluttet, trækkes der lod imellem bestillingerne, og kun de, der har vundet, får trukket betalingen fra kontoen.

(I almindelige danske netbutikker bliver pengene først trukket fra din konto, når butikken sender varen, ikke når du bestiller; det siger reglerne)

  • 0
  • 0
Peter Nørregaard Blogger

Ideen er, at man sætter træk-et-nummer, som vi kender fra bageren om søndagen, foran det system, der har behov for at få reguleret antallet af samtidige brugere fordi det fx kun kan trække 100 samtidige sessioner. Når så der er din tur, giver Queue-it dig adgang til systemet, hvor man så kan gøre de ting, man skal gøre derinde, uden risiko for at systemet bryder ned undervejs. Så det er ikke queue-it, der håndterer ting som sæde-valg mm.

Der er en række specielle situationer som skal håndteres (hvis hele sitet er nede, hvordan kommer queue-it så i spil, hvad med folk, der forsøger at snyde sig foran i køen? mm) Hvordan det er håndteret ved jeg ikke - men jeg tror at de enten har løst det, eller arbejder på det.

  • 0
  • 0
Nikolaj Brinch Jørgensen

deen er, at man sætter træk-et-nummer, som vi kender fra bageren om søndagen, foran det system, der har behov for at få reguleret antallet af samtidige brugere fordi det fx kun kan trække 100 samtidige sessioner. Når så der er din tur, giver Queue-it dig adgang til systemet, hvor man så kan gøre de ting, man skal gøre derinde, uden risiko for at systemet bryder ned undervejs. Så det er ikke queue-it, der håndterer ting som sæde-valg mm.

Det er ikke hvad deres video afspejler, men ok - det kan være de vil forsimple deres kommunikation.

Der er en række specielle situationer som skal håndteres (hvis hele sitet er nede, hvordan kommer queue-it så i spil, hvad med folk, der forsøger at snyde sig foran i køen? mm).

Det eneste jeg ikke helt forstår er hvorledes kø princippet så afvikles i deres setup, med SMS beskeder eller emails som også kan være længere tid undervejs, ligesom kundens email server kan være i stykker, som vi ved ingen prioritet har og først kommer frem måske 4 timer senere, har man så stadig sin plads i køen? Blokeres systemet ikke af nølere oa.

Hvordan det er håndteret ved jeg ikke - men jeg tror at de enten har løst det, eller arbejder på det

Hvis ikke de har løst flere af de omtalte problemstillinger endnu, så synes jeg nyheden tangere varm luft. Så kan jeg også postulere med en flash at jeg har et system der kan tilføre uendelig skalering til dårligt designede systemer for ingen penge, ved at bruge Cloud computing.
Så ligner det mere en Cloud Buzz for at skaffe VC.

  • 0
  • 0
Martin Pronk

Det er dejligt at se den store interesse der for vores http://Queue-it.net løsning. Det ser dog også ud til, at der er lidt forvirring omkring visse aspekter af løsningen. Vi vil derfor gerne invitere alle interesserede til en uformel dialog hos os (fourKant) på Fruebjergvej 3, 2100 København Ø på torsdag den 3. juni kl. 15-17. Så kan vi få en kop kaffe / en øl og diskutere:
- Hvorfor alle IT systemer ikke er så nemme at flytte ud i skyen
- Hvordan vi håndterer 100.000 vis af samtidige brugere
- Hvorfor en virtuel kø ikke er så nem at implementere som det umiddelbart lyder
- Hvordan vi håndterer de udfordringer, der bl.a. er nævnt i de ovenstående indlæg
Hvis du er interesseret, så send en mail til info@queue-it.dk. Vi glæder os til at møde jer.

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