VDI Options - Modernization
-
@pete-s said in VDI Options - Modernization:
If you make big changes it will impact the business in other ways such as cost for training, lower productivity while getting up to speed etc.
Exactly, which means that modernization's value is biggest when done early. The longer you linger on old systems that are outdated (that is IF the determination is that they WILL be modernized at some point, not saying that everyone should) the more you invest in technical debt, the higher the cost of moving to the modernized system, and the less time to get the increased value from the modernization.
When you know a system will be modernized, you have a huge training / productivity benefit to making the switch right away and not holding out.
-
@pete-s said in VDI Options - Modernization:
What I've seen is that companies replace their VDI solutions by doing things differently, but it's done over several years.
So when companies have the long term goal of getting rid of their VDI solution they would one by one remove the reasons for it's existence and as a result get fewer and fewer users on it. Eventually they can retire it.That can be better, but can also lead to a lower benefit overall. It helps to hide the pain and cost of the modernization, but rarely removes it. Making people not realize it might solve an emotional need, but typically (again, just typically) is actually more costly than just ripping off the bandaid all at once and making the leap forward. COntinuing to pay for old systems for fewer and fewer users often has an increasing price tag on it.
-
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.
-
@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.
-
@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.
Do you think this is because the ERP is so horrible it's pulling data to the local session and working locally on it - or are they doing it simply for security reasons?
-
@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.
Do you think this is because the ERP is so horrible it's pulling data to the local session and working locally on it - or are they doing it simply for security reasons?
I'm guessing just because ERP is the biggest reason (to my knowledge) for any company to use VDI. ERPs are the single largest LOB application period, and are the biggest legacy apps that still do 1990s style client/server applications that require a fat client to operate (the main reason that apps need VDI.)
VDI isn't good for security (it's not horrible, but it isn't something you ever do FOR security) so that would not make any sense and could just be modernized in a heartbeat if that were the case. But if there is a client/server app running like a pre-Internet application that has high latency sensitivity at the fat client / database interface, then VDI is the primary way that that is addressed while providing remote access options. It also requires that the app need sole sessions or desktop licensing which is only common in ERP clients.
This is exactly what is done in the veterinary space (except without the licensing requirement so TS is used instead of VDI) because of the legacy ERP-style client/server apps that are in use that haven't been updated in 30+ years (literally).
-
@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.
