Cloud (Azure/AWS) vs on-premise data-transfer speed

[dejoma]

Beste mede-tweakers,

Ik kamp met een probleem qua 'data transfer' snelheid. Ik maak een software die 'data' nodig heeft om het eea te visualiseren. Normaal staat deze data op een fileshare samen met de .exe (denk aan 1GBps of 500mbps) en zijn de responstijden dus erg goed (denk aan minder dan 0.5 seconde voor files tot 30MB). Deze software vertaalt de data naar grafieken en tabellen etc. Nu switchen er veel bedrijven naar de cloud, Azure, AWS, je kent het wel. En als ik de data nu in een blob-storage of op een virtual-machine zet worden deze snelheden gewoon wifi-snelheden en zijn de responstijden minstens factor 10 slechter.

Wat heb ik in gedachten/probeer ik momenteel?
Alles in de cloud zetten, dus de data en de software, en via Citrix het scherm doorsturen. Alleen... is dit nog niet supersnel. Een RemoteApp kan uiteraard ook, maar met ca. 200 gebruikers en een RAM-gebruik van 1GB per "client" wordt dit nogal lastig (denk ik?). Misschien kan een RemoteApp wel in combinatie met dynamic VM usage, dus dat er automatisch meer resources beschikbaar worden gesteld wanneer nodig? Dit raakt denk ik weer Docker/Kubernetes waar ik alleen basis kennis van heb.. Ik bezit zelf helaas niet de nodige kennis qua AWS/Azure/Cloud computing/Citrix om hier nu een goede beslissing te kunnen maken.

Heeft iemand hier ervaring mee? I'm desperate for help! Wat is hier de beste oplossing om toch die snelle responstijd te krijgen die ik gewend ben met de fileshare of het lokaal opslaan van de data?

Hoor graag van iedereen, thanks!
Fijne dagen, dejoma

[F_J_K]

Wordt het niet tijd voor een webbased applicatie? Ik wil hier alleen bij hele hele goede redenen nog win32/64. Al zou 1GB per client dan wel een reden kunnen zijn ja

Als het om files van idd 30MB gaat: lokaal cachen?

[Bob-B190]

dejoma schreef op dinsdag 24 december 2019 @ 12:15:
En als ik de data nu in een blob-storage of op een virtual-machine zet worden deze snelheden gewoon wifi-snelheden en zijn de responstijden minstens factor 10 slechter.

Deze snap ik niet, de fileshare wordt toch ook via wifi benaderd door de clients? Dus dat zal dan niet de bottleneck zijn. Hoe dik is de lijn naar het internet (ik ga er vanuit dat je geen directe koppeling hebt met Azure/AWS maar via VPN met je omgeving koppelt)?

[dejoma]

@F_J_K We zijn inderdaad bezig met een webversie, maar de huidige oplossing moet voor de komende paar maanden nog draaien.. Tot die tijd deze manier helaas. En het lokaal cachen dat gebeurt met de ingelezen files. Dus ik kijk naar data van 2018 en ik dubbelklik voor 2019, dan moet de cache dus veranderen en dat duurt circa 5-10 seconden wat normaliter 0.1-0.5 seconden duurt.

@Bob-B190 Ik weet 100% dat de transfer-snelheid de oorzaak is.. En de lijn naar het internet, dus van de workstation naar Azure (in dit geval) is een parameter die we niet kunnen beïnvloeden helaas, wel via VPN ja.

[Question Mark]

dejoma schreef op dinsdag 24 december 2019 @ 14:10:
@F_J_K We zijn inderdaad bezig met een webversie, maar de huidige oplossing moet voor de komende paar maanden nog draaien..

Is het écht wel nodig om nu een architectuuraanpassing door te gaan voeren, die nog ontworpen én geimplementeerd moet worden om een paar maanden te overbruggen?

[raptorix]

Blob storage is natuurlijk bedoeld als "storage" niet om daar realtime bewerkingen op te doen, als je dat wel wilt in Azure dan kun je natuurlijk wel werken met VM's en Managed Disks. Overigens als ik het aantal gebruikers hoor, en het toch wel complexe probleem, dan is het wellicht nuttig om daar wat consulantancy in te huren. Nu ben ik zelf zo een consultant Nu ga ik hier geen diensten aanbieden, maar zeker met cloud kun je je enorme kosten besparen door wat slimmigheden.

[dejoma]

raptorix schreef op zaterdag 4 januari 2020 @ 12:51:
Blob storage is natuurlijk bedoeld als "storage" niet om daar realtime bewerkingen op te doen, als je dat wel wilt in Azure dan kun je natuurlijk wel werken met VM's en Managed Disks.

Ja het zijn geen bewerkingen, de files worden alleen ingelezen. En consultancy, ik zou het gelijk doen maar ik ben pas net in dienst en kan dit alleen maar voorstellen ^^ Thanks though!

[Question Mark]

Wellicht offopic, maar in welk vlak onderscheid jullie software zich nog ten opzichte van iets als PowerBI?

Data inlezen en visualiseren is nu het vlak wat bv een PowerBI heel goed kan (mits de juiste raporten aangemaakt kunnen worden). En vanuit een O365 abonement heeft een organisatie vaak al gebruiksrechten voor.

[Douweegbertje]

Ja dan ga ik toch een beetje advocaat van de duivel spelen om te zeggen dat de cloud geen magische oplossing is voor al je problemen. Wat ik hier ook mee wil zeggen is dat je dan soms ook aan andere werkwijze moet gaan denken.

Als ik dit zo lees vraag ik mij heel erg af waarom je in 1x zo'n grote dataset wilt inladen en waarom dat snel moet zijn.

Deze software vertaalt de data naar grafieken en tabellen etc.

Lijkt me dat dit toch gewoon eenmalig is? Wat maakt de responsetime uit als je het kan hergebruiken?

----

Ik heb echt mega veel data in zowel prometheus als elasticsearch staan. Vaak verwerken we nog wat data om het hapbaarder te maken voor het doel. Stel dat ik elke 5 seconden een waarde heb (timeseries) en ik wil uiteindelijk alleen dagelijkse/wekelijkse overzichten maken. Nu hoef ik dat maar 1x de gemiddelde te pakken en heb ik zo mijn data uitgedund.

Dus my 2 cents, ik zou meer gaan kijken naar:
- Hoe sla je data op
- Hoe maak je data toegankelijk
- Hoe maak je data uniform & consistent
- Welke beschikbaarheid heb je benodigd
- Realtime data?

En dan ga je vanuit daar kijken naar hoe/wat/waar je dat gaat doen. IMO het simpelweg neergooien van data en 1GBps vereisen omdat je anders een slechte responsetijd hebt, is met alle respect een aparte aanpak.

[dejoma]

Douweegbertje schreef op maandag 6 januari 2020 @ 13:45:
Als ik dit zo lees vraag ik mij heel erg af waarom je in 1x zo'n grote dataset wilt inladen en waarom dat snel moet zijn.

Ons Unique Selling Point is dat we miljoenen rijtjes aankunnen met response tijden van milliseconden, en dat lukt ook met een FileShare. Hoe wij de data opslaan is dus al extreem efficiënt, een unzipt bestand van 1GB kunnen we meestal terug brengen naar 5MB zonder dat we inlees snelheid verliezen. Maar al je vragen die je stelt zijn dingen die we jaren terug hebben bedacht waarvan alles al verbeterd is. Desalniettemin, zeer goede vragen uiteraard.

Ik ga denk ik mezelf verdiepen in shared disks van Azure, en allicht kan ik de big boss overhalen om een consultant in te schakelen. Thanks iedereen