Having worked for a bank I will add my jaded opinion. Throw logic out of the window. Banks have their own regulations, history and internal policies. Finding a job is hard right now so one may have to grin and just accept it. Don't think too much about it.
Ask them if you can use VMWare or VirtualBox in the virtual desktop and get a VMWare license assigned to you. It's clunky but something they might actually have and may save some headaches. If this is an option ask them which Linux ISO is permitted and where it is.
How common is this?
Very common for a bank especially for offshore or remote employees.
Also, curious what kinds of workarounds people are using?
Nobody outside of the bank will like this answer. Ask them what work around is permitted within the policy. If your questions are always without emotion and always centered around policy they may grow to like you and with time you may earn more trust than others making your job just a little easier.
I've finished up there now, so this is purely retrospective.
For them - the workaround (sadly) was -- a lack of testing.
I was really surprised that in a heavily regulated environment (this project faced off to a regulator) Integration testing (which has gotten really easy on the JVM thanks to stuff like TestContainers) just didn't exist.
That could be symptom of a broader lack of a test-driven culture though.
It might just be an unintentional side effect of an older rule. They don’t want people running full-on nested VMs probably due to security concerns (inability to properly lock down the nested VMs). They wrote that rule in, say, 2005, and haven’t revisited it since the emergence of containerization as a best practice. Possibly because like most banks their software practices lag by decades.
I was in an Indian service company and worked for Indian and US branches of a company. The regulations were high, employees know more stuff and people and *carve out* a streamlined workflow, we contractors have to obey the rules literally, our feedback are Chinese whispers (me, my manager, their manager...) and we have to fend for themselves.
For specific stories. We had Windows virtual desktops. Our unit test suites assume an Unix environment like the employees Macs or Jenkins, so we had to coax Jenkins to run our feature branches and there may be 12 hour waits for our builds. We also had to plan leaves around their quarterly plans and hard deadlines while they they never treated quarterly plans as deadlines or cycles.
Debugging with client is affected by timezone differences too.
If they run in one dev env, (for cost reasons), it is preferably in Docker is VERY expensive if you are not using it for personal, noncommercial usage now ...
VDI VM in VM often not ideal aswell,
Docker is paid per seat monthly subscription for commercial usages
Just out of curiosity, what does the dev env look like? A set of VMs? K8s?
If k8s, then mirrord for teams can be useful for testing code locally against the dev env dependencies without having to containerize while also not breaking the shared env dependencies for others.
Every environment is a copy of the data, I would imagine. I think you would want to limit spawning of copies of your data in an offshore outsourced environment for security reasons. That's my guess.
Having worked in HFT, we had contractual obligations imposed on us by our customers for this very reason. In our case it wasn’t the data but rather the source code that we sold on to a few large banks that they were concerned for.
It is not common and as you could have figured from the rest of this arrangement, it's just yes, this organisation is broken. Which is usually a good thing, broken places are usually to make money off that's why they remain broken for a long time - some places might go under because of that, but not a bank.
I was doing some client work recently at a bank
Having worked for a bank I will add my jaded opinion. Throw logic out of the window. Banks have their own regulations, history and internal policies. Finding a job is hard right now so one may have to grin and just accept it. Don't think too much about it.
Ask them if you can use VMWare or VirtualBox in the virtual desktop and get a VMWare license assigned to you. It's clunky but something they might actually have and may save some headaches. If this is an option ask them which Linux ISO is permitted and where it is.
How common is this?
Very common for a bank especially for offshore or remote employees.
Also, curious what kinds of workarounds people are using?
Nobody outside of the bank will like this answer. Ask them what work around is permitted within the policy. If your questions are always without emotion and always centered around policy they may grow to like you and with time you may earn more trust than others making your job just a little easier.
Thanks!
I've finished up there now, so this is purely retrospective.
For them - the workaround (sadly) was -- a lack of testing.
I was really surprised that in a heavily regulated environment (this project faced off to a regulator) Integration testing (which has gotten really easy on the JVM thanks to stuff like TestContainers) just didn't exist.
That could be symptom of a broader lack of a test-driven culture though.
It might just be an unintentional side effect of an older rule. They don’t want people running full-on nested VMs probably due to security concerns (inability to properly lock down the nested VMs). They wrote that rule in, say, 2005, and haven’t revisited it since the emergence of containerization as a best practice. Possibly because like most banks their software practices lag by decades.
I was in an Indian service company and worked for Indian and US branches of a company. The regulations were high, employees know more stuff and people and *carve out* a streamlined workflow, we contractors have to obey the rules literally, our feedback are Chinese whispers (me, my manager, their manager...) and we have to fend for themselves.
For specific stories. We had Windows virtual desktops. Our unit test suites assume an Unix environment like the employees Macs or Jenkins, so we had to coax Jenkins to run our feature branches and there may be 12 hour waits for our builds. We also had to plan leaves around their quarterly plans and hard deadlines while they they never treated quarterly plans as deadlines or cycles. Debugging with client is affected by timezone differences too.
If they run in one dev env, (for cost reasons), it is preferably in Docker is VERY expensive if you are not using it for personal, noncommercial usage now ...
VDI VM in VM often not ideal aswell,
Docker is paid per seat monthly subscription for commercial usages
The block was not for docker license cost reasons - it was part compliance, and part an issue with the underlying VDI VM they were using.
The onshore team were able to use Docker, but not offshore.
Just out of curiosity, what does the dev env look like? A set of VMs? K8s? If k8s, then mirrord for teams can be useful for testing code locally against the dev env dependencies without having to containerize while also not breaking the shared env dependencies for others.
Disclaimer: I work for the parent company
Every environment is a copy of the data, I would imagine. I think you would want to limit spawning of copies of your data in an offshore outsourced environment for security reasons. That's my guess.
Having worked in HFT, we had contractual obligations imposed on us by our customers for this very reason. In our case it wasn’t the data but rather the source code that we sold on to a few large banks that they were concerned for.
It is not common and as you could have figured from the rest of this arrangement, it's just yes, this organisation is broken. Which is usually a good thing, broken places are usually to make money off that's why they remain broken for a long time - some places might go under because of that, but not a bank.
Banning docker equals to broken company to you? Please, have your opinion, but dont run around spreading absurd claims...