VDI Options - Modernization
-
@dashrender said in VDI Options - Modernization:
I know Gene's company is using VDI for access to their EMR - which is cloud hosted.. I can't really understand the gain there.
Cloud hosted doesn't mean it's accessed by a web browser. It might be a Windows application of some kind.
So insert VDI to allow access to the application from any type of client device. And without having to install something locally on the client and without having sensitive data stored on the client.
Accessed by a web browser also doesn't mean that nothing is stored locally. I'm not talking cached files here but client side databases and local storage as defined in html5. Another reason you might insert VDI into the chain.
-
@pete-s said in VDI Options - Modernization:
Cloud hosted doesn't mean it's accessed by a web browser. It might be a Windows application of some kind.
Definitely, and more often than you'd think. The "cloud hosted" quickbooks is exactly that way. Cloud hosted Avimark. Just two things I run into literally daily.
-
@pete-s said in VDI Options - Modernization:
So insert VDI to allow access to the application from any type of client device. And without having to install something locally on the client and without having sensitive data stored on the client.
AND.... low latency (in theory) between the application and the database. Remote displays are generally far less latency sensitive than database connections. So many times, this is the only way it remains functional.
Avimark is a prime example. It's a client/server system with a super inefficient database call design (every action requires a LOT of DB calls.) So ever millisecond added between the app layer and the DB causes big delays in application response. But the interface is essentially static and really basic (e.g. no photos, no fancy graphics, easy to show remotely.)
So by going to VDI or terminal services you can move the app layer super close to the database and get that DB connection round trip into the nanosecond category, and then put the onus on the remote graphics layer (RDP, VNC/RFP, Spice, PCoIP, etc.) to deal with the latency over the WAN which generally, they can do pretty well. And then any delay is a human related one, not an app one. The app happens lightning fast, even if you can't see it necessarily.
-
@pete-s said in VDI Options - Modernization:
I'm not talking cached files here but client side databases and local storage as defined in html5. Another reason you might insert VDI into the chain.
Worth pointing out that this "should be" a configuration thing and not something you need heavy VDI to work around. But here in the real world, it isn't always configurable and VDI can be used to deal with that.
-
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
I'm not talking cached files here but client side databases and local storage as defined in html5. Another reason you might insert VDI into the chain.
Worth pointing out that this "should be" a configuration thing and not something you need heavy VDI to work around. But here in the real world, it isn't always configurable and VDI can be used to deal with that.
Yeah, it depends entirely on what the html/javascript code looks like. Which in most cases depends on what framework was used.
It was easier to keep track of the data when a html browser was as dumb as a vt100 terminal.
-
@pete-s said in VDI Options - Modernization:
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
I'm not talking cached files here but client side databases and local storage as defined in html5. Another reason you might insert VDI into the chain.
Worth pointing out that this "should be" a configuration thing and not something you need heavy VDI to work around. But here in the real world, it isn't always configurable and VDI can be used to deal with that.
Yeah, it depends entirely on what the html/javascript code looks like. Which in most cases depends on what framework was used.
It was easier to keep track of the data when a html browser was as dumb as a vt100 terminal.
Wanna take bets that a new "HTML-lite" protocol surfaces that has modern GUI and graphical components, but none of the heavy data-handling components so that people can be confident that no data leaks beyond what is seen on the screen?
-
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
So insert VDI to allow access to the application from any type of client device. And without having to install something locally on the client and without having sensitive data stored on the client.
AND.... low latency (in theory) between the application and the database. Remote displays are generally far less latency sensitive than database connections. So many times, this is the only way it remains functional.
Avimark is a prime example. It's a client/server system with a super inefficient database call design (every action requires a LOT of DB calls.) So ever millisecond added between the app layer and the DB causes big delays in application response. But the interface is essentially static and really basic (e.g. no photos, no fancy graphics, easy to show remotely.)
So by going to VDI or terminal services you can move the app layer super close to the database and get that DB connection round trip into the nanosecond category, and then put the onus on the remote graphics layer (RDP, VNC/RFP, Spice, PCoIP, etc.) to deal with the latency over the WAN which generally, they can do pretty well. And then any delay is a human related one, not an app one. The app happens lightning fast, even if you can't see it necessarily.
This ^, this is really the only reason I can figure that Gene's company does it. Gene and I use the same EMR product.
They are using a web based EMR - there are no local DBs
The only thing that's local is printing/scanning/medical device connected.BUT - the interface gets super slow sometimes. I haven't been able to determine why, our internet connection isn't saturate, other websites seem to be speedy (except for M365 - man that's just a dog no matter where I use it).
That's why I mentioned for potential performance enhancement - MS has huge pipes to the internet - so perhaps their VDI can get a faster connection to the EMR (over the web) and the screen delivery is less of an issue.
-
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
I'm not talking cached files here but client side databases and local storage as defined in html5. Another reason you might insert VDI into the chain.
Worth pointing out that this "should be" a configuration thing and not something you need heavy VDI to work around. But here in the real world, it isn't always configurable and VDI can be used to deal with that.
Yeah, it depends entirely on what the html/javascript code looks like. Which in most cases depends on what framework was used.
It was easier to keep track of the data when a html browser was as dumb as a vt100 terminal.
Wanna take bets that a new "HTML-lite" protocol surfaces that has modern GUI and graphical components, but none of the heavy data-handling components so that people can be confident that no data leaks beyond what is seen on the screen?
why did some move away from that model in the first place? to put the processing power onus on the end user?
-
@dashrender said in VDI Options - Modernization:
They are using a web based EMR - there are no local DBs
Many people are not aware that the web browser has a built in database engine (IndexedDB) that webpages can use. It's a persistent database storage space on your local drive. It's stored among your browsers files.
It not something that you install or are normally aware of.
Sites can also use other storage mechanisms on your local browser, besides cookies that are familiar to most, there is also a cache, session storage and local storage.
These storage spaces are not encrypted so if a webpage or a webapp decides to put sensitive information there, well, it sits on your local drive then.
-
@pete-s said in VDI Options - Modernization:
@dashrender said in VDI Options - Modernization:
They are using a web based EMR - there are no local DBs
Many people are not aware that the web browser has a built in database engine (IndexedDB) that webpages can use. It's a persistent database storage space on your local drive. It's stored among your browsers files.
It not something that you install or are normally aware of.
Sites can also use other storage mechanisms on your local browser, besides cookies that are familiar to most, there is also a cache, session storage and local storage.
These storage spaces are not encrypted so if a webpage or a webapp decides to put sensitive information there, well, it sits on your local drive then.
OK I leave room for that to exist, and I don't know for a fact that isn't happening with this EMR.
-
@dashrender said in VDI Options - Modernization:
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
I'm not talking cached files here but client side databases and local storage as defined in html5. Another reason you might insert VDI into the chain.
Worth pointing out that this "should be" a configuration thing and not something you need heavy VDI to work around. But here in the real world, it isn't always configurable and VDI can be used to deal with that.
Yeah, it depends entirely on what the html/javascript code looks like. Which in most cases depends on what framework was used.
It was easier to keep track of the data when a html browser was as dumb as a vt100 terminal.
Wanna take bets that a new "HTML-lite" protocol surfaces that has modern GUI and graphical components, but none of the heavy data-handling components so that people can be confident that no data leaks beyond what is seen on the screen?
why did some move away from that model in the first place? to put the processing power onus on the end user?
Oh it makes TONS of sense. If you saw every day apps built both ways side by side you'd chose this "every" time. First, it saves the hosts and the ISPs tons of money because it shifts lots of processing power out to the end units where typically there is loads of excess power. Why do something in an expensive way when there is a free way waiting to be utilized?
Second, it makes websites a lot faster. I mean a LOT faster. It means you can do lightning fast calculations without waiting for long internet round trips, you can cache data, etc.
Third, you can work offline. People always complained that apps were unable to work offline. This is what allows things like email or document editing when you still lose your Internet connection, and what allows many things to keep working when your Internet might be flaky.
-
S scottalanmiller referenced this topic on
