4 ms·

Did anyone sit with the users for a few days? I hear the same success stories from the MSPs while simultaneously their users are crying into their coffee on a

by hughrr 5y ago

Did anyone sit with the users for a few days? I hear the same success stories from the MSPs while simultaneously their users are crying into their coffee on a daily basis. In fact “sorry our systems are slow today” is a normal catchphrase these days. Only high performance call centre outcome I’ve seen in recent years is run by Indian scammers.

jordanbeiber 5y ago
The users were working claims in the insurance industry. They used a lot of really specific, custom built software that all were integrated with each other as well as to ip-telephony system, mainframes and office suites (MS and Domino). These integrations was built at HQ, ”works on my laptop style”, but at a branch office 1000km away… no fun at all! An unholy mess that would take many years and a couple of $100.000.000 to untangle. I had weekly “continual improvement meetings” with the power/super users, one or two from each branch office. The whole team spent a lot of time at the local branch offices dog fooding the service and talking to the users. I used the service as my only workplace for three years in a development & ops role. The success factor here was that we built a solution for a specific set of users that we continuously improved. I’m talking “make something slightly better today than it was yesterday - every day” type of mindset. We started out with a PoC by brokering sessions to physical machines located in the datacenters. First users was the assigned "super-users". They were assigned due to being the most demanding and loud user base. After a few week they _demanded_ that every user should get the same setup - we interpreted this as a successful PoC and went on to explore options. At this time neither Citrix or vmware had a concept called VDI and we started out using pre-release code from vmware. First prod version was using vmware but we only gained performance, which ofc was a win, but we still needed to manage all the vm's through standard automations (os patches, asset and inventory, application repackaging and roll-outs) When Citrix bought ardence to get PvS it was a no-brainer - ICA protocol, PvS and app-v streaming was a great combo to rapidly deliver a high performing workplace. BUT - you need automations and reliable network links, both of which we could provide. We had dedicated hypervisor hosts with the fastest local storage available. You should NEVER user SAN/NAS or other centralized storage systems for these workloads IMO. Also, monitor the performance closely! Caching all application to host local SSD really took care of a lot of the potential perf issues we saw early on. Depending on user role they could get dedicated hardware as well, but this was only for a select few users. It was set up as a specific service delivery and my team was dedicated to improving and supporting the users. One of the most rewarding projects I've been involved in, mainly due to the really close collaboration with end-users.
- jordanbeiber 5y ago
  How we migrated to thin clients was also a fun project. First batch of users used a windows client on their pc. When we after some time commited to the solution we built a really tight linux os image with only the citrix client that we pxe booted the PC’s with. This allowed us a fallback in case of emegergency by simply rebooting a user. This was a fun project in and of itself! As we grew confident together with the users we started to phase in thin client instead of buying new PC’s - all in all we ended up with a really cost efficent and high performing setup. We started to move the central infra from “hyperconverged” to commodity 2u servers with local solid state disks which really made it easy and cheap for us to scale. It also made the whole service more reliable compared the integrated blade and storage solutions we were ushered in to at first.
OrvalWintermute 5y ago
I sat with users on our own setup as a technology demonstration, used the system as my primary desktop only for several months, and I have used other setups where I needed high security (mil/gov) paired with high degrees of access using crypto authN from another CTO. Our technology demonstration operated beautifully but in the end we decided not to go with it because (1) we needed to rearchitect our SMB storage to centralize it, so there were no round trips or long distance SMB (2) Our network performance could be inconsistent at times due to jitter, which was not a problem with the solution, but the underlying network performance as specified, vs as-built, for some recent WAN enhancements. A colleague at another location built a solution that I utilized as a desktop for sometime. Despite being ~1400 miles away and over our Center to Center network, performance was comparable to my engineering workstation, was always patched, excellent graphics performance, and was highly accessible provided strong authN. There were some substantial differences in both of these: (1) No oversubscription (2) Fully capable of handling bootstorms (3) Dedicated hardware / high performance VDIs (4) Not viewed as a cost avoidance but as an access enhancer (5) Optimized for expensive engineers / scientists where labor rates are the overwhelming cost, so 5 minutes of extra productivity more than pays for a solution.

by hughrr 5y ago

jordanbeiber 5y ago

The users were working claims in the insurance industry. They used a lot of really specific, custom built software that all were integrated with each other as well as to ip-telephony system, mainframes and office suites (MS and Domino). These integrations was built at HQ, ”works on my laptop style”, but at a branch office 1000km away… no fun at all! An unholy mess that would take many years and a couple of $100.000.000 to untangle. I had weekly “continual improvement meetings” with the power/super users, one or two from each branch office. The whole team spent a lot of time at the local branch offices dog fooding the service and talking to the users. I used the service as my only workplace for three years in a development & ops role. The success factor here was that we built a solution for a specific set of users that we continuously improved. I’m talking “make something slightly better today than it was yesterday - every day” type of mindset. We started out with a PoC by brokering sessions to physical machines located in the datacenters. First users was the assigned "super-users". They were assigned due to being the most demanding and loud user base. After a few week they _demanded_ that every user should get the same setup - we interpreted this as a successful PoC and went on to explore options. At this time neither Citrix or vmware had a concept called VDI and we started out using pre-release code from vmware. First prod version was using vmware but we only gained performance, which ofc was a win, but we still needed to manage all the vm's through standard automations (os patches, asset and inventory, application repackaging and roll-outs) When Citrix bought ardence to get PvS it was a no-brainer - ICA protocol, PvS and app-v streaming was a great combo to rapidly deliver a high performing workplace. BUT - you need automations and reliable network links, both of which we could provide. We had dedicated hypervisor hosts with the fastest local storage available. You should NEVER user SAN/NAS or other centralized storage systems for these workloads IMO. Also, monitor the performance closely! Caching all application to host local SSD really took care of a lot of the potential perf issues we saw early on. Depending on user role they could get dedicated hardware as well, but this was only for a select few users. It was set up as a specific service delivery and my team was dedicated to improving and supporting the users. One of the most rewarding projects I've been involved in, mainly due to the really close collaboration with end-users.

jordanbeiber 5y ago
How we migrated to thin clients was also a fun project. First batch of users used a windows client on their pc. When we after some time commited to the solution we built a really tight linux os image with only the citrix client that we pxe booted the PC’s with. This allowed us a fallback in case of emegergency by simply rebooting a user. This was a fun project in and of itself! As we grew confident together with the users we started to phase in thin client instead of buying new PC’s - all in all we ended up with a really cost efficent and high performing setup. We started to move the central infra from “hyperconverged” to commodity 2u servers with local solid state disks which really made it easy and cheap for us to scale. It also made the whole service more reliable compared the integrated blade and storage solutions we were ushered in to at first.

OrvalWintermute 5y ago

I sat with users on our own setup as a technology demonstration, used the system as my primary desktop only for several months, and I have used other setups where I needed high security (mil/gov) paired with high degrees of access using crypto authN from another CTO. Our technology demonstration operated beautifully but in the end we decided not to go with it because (1) we needed to rearchitect our SMB storage to centralize it, so there were no round trips or long distance SMB (2) Our network performance could be inconsistent at times due to jitter, which was not a problem with the solution, but the underlying network performance as specified, vs as-built, for some recent WAN enhancements. A colleague at another location built a solution that I utilized as a desktop for sometime. Despite being ~1400 miles away and over our Center to Center network, performance was comparable to my engineering workstation, was always patched, excellent graphics performance, and was highly accessible provided strong authN. There were some substantial differences in both of these: (1) No oversubscription (2) Fully capable of handling bootstorms (3) Dedicated hardware / high performance VDIs (4) Not viewed as a cost avoidance but as an access enhancer (5) Optimized for expensive engineers / scientists where labor rates are the overwhelming cost, so 5 minutes of extra productivity more than pays for a solution.