3 ms·
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 w
by 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 agoHow 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.