VDI Options - Modernization
-
@dashrender said in VDI Options - Modernization:
so horrible it's pulling data to the local session and working locally on it
This statement is the "entire" reason for remote desktops sessions to exist across the board
BUT, that said, it doesn't have to be "horrible." If this is a medical system, that would be pretty pathetic. But what if it was something like video post processing and attempting to distribute CPU and GPU processing to the edge for end user performance? There are cases where these models, while older, can still make sense. They are fewer over time, but they remain and will remain for a long time.
-
@dashrender said in VDI Options - Modernization:
@scottalanmiller said in VDI Options - Modernization:
@dashrender said in VDI Options - Modernization:
I'm really curious to know what is running on this VDI platform that makes it needed in first place - especially for 600-1000 users.
Dollars to donuts, I bet it is ERP related or similar.
horrible it's pulling data to the local session and working locally on it - or are they doing it simply for security reasons?
I know there are other applications, under active development today, that still do this..... and is just one reason I have a nervous twitch whenever I see Microsoft Dynamics.
-
@stacksofplates said in VDI Options - Modernization:
@jimmy9008 said in VDI Options - Modernization:
@jt1001001 said in VDI Options - Modernization:
@jimmy9008 We have a use case involving a legacy client/server app that we've determined we're going to have to go VDI for in order to secure it. One lousy app for approx 5 users that I hope we eventually move away from. We are currently reviewing Azure VDI for this and it so far will fit the bill though we had to go throught a lot of "hoops" to configure networking, VPN back into our infrastructure, etc. We have not yet presented budget numbers to the bean counters but Im hoping when we do they will see the $$$$$ wasted for 5 users and will force them to a new product.
What other products do you plan to look at? Still VDI or something else? Any experience of VMWare Horizon?
We have around 600 - 1000 users globally (mostly developers) on the VDI I need to replace. The company dictates that the VDI must be in the same datacenter as the rest of the developers environments, so I don't think Azure VDI would work for us because of that mandate.
I know this isn't VDI, but what about something like GitPod, Eclipse Che, Coder, etc? In everyone's defense, developing over VDI truly sucks. This would keep the development environments in the same data center, but would give a much better experience.
Yeah I agree. Putting developers on VDI is a total waste. But it sounds like OP doesn't want a different solution and is not interested in thinking outside the box to implement IT based on strategy vs this is way things were always done.
That's why these people won't be calling the shots or making big bucks because they can't think outside their comfort zones and refuse to stand up to their superiors in order to make positive change.
-
@scottalanmiller said in VDI Options - Modernization:
@dashrender said in VDI Options - Modernization:
so horrible it's pulling data to the local session and working locally on it
This statement is the "entire" reason for remote desktops sessions to exist across the board
BUT, that said, it doesn't have to be "horrible." If this is a medical system, that would be pretty pathetic. But what if it was something like video post processing and attempting to distribute CPU and GPU processing to the edge for end user performance? There are cases where these models, while older, can still make sense. They are fewer over time, but they remain and will remain for a long time.
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.
I suppose his local internet connection isn't great - and VDI might be a faster overall experience.
-
@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.
Generally, none. Many VDI deployments are done out of confusion. But there could be other factors at play, like the EMR needed to be access and manipulated using MS Word and there was no web hooks for it because it was legacy.
But, like cloud, VDI is often done solely because it's an easy to remember term that almost no one understands making it an easy target for sales people to sell managers on or IT folks who just want to be able to say that they "did something" to management or people looking to pad their resumes. "Moved a company to cloud" or "rolled out VDI" look great to the untrained managers that tend to do hiring. So it is VERY popular to do where it has no purpose.
-
@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
