Comment by aaomidi

> when I suggest we self-host something instead of forking over millions to AWS, it’s an instant no.

This is something that bothers me a lot, and I've given up. It's to a point where we're paying thousands of dollars sometimes a year for 200 lines of code.

It also kinda makes it harder to sometimes just practice engineering skills.

For example, I wrote a just in time access request solution at work. However, okta also has one of these. Funny thing is, the one I wrote is a proof of concept - so it's a little rough around the edges but nothing spectacularly wrong.

I then used the okta solution for this and my god, what an absolute mess of software they have.

1. They don't have the ability to have the requester specify a duration of access they want. It all has to be hardcoded.

2. Imagine you request access to group A for 3 hours. 2.5 hours later, you're thinking "Hmm, I think I'm going to need more access. So you make another access request for 3 hours. After half an hour that first access expires, and just removes your access. Even if you still have 2.5 hours left from your second access.

3. Without even trying, I got the backend for setting up the access requests into an inconsistent state. Okta's UI is insisting I can't delete a group because it's used by an access request form. However, when I was making that access request form the save button partially failed, so now there's this dangling foreign key somewhere in their database. Inconsistencies like that in software that's supposed to be the source of truth of access is just absolutely unacceptable.

4. Okta "removes" access by removing you from the group that you had requested. However, if there's any issues with Okta's provisioning code, from Okta's perspective you don't have access but the third party service might still think you do. They don't _remove_ the access from the third party first before removing it from their own source of truth.

What's depressing is that in my proof of concept, before even trying Okta's product I thought about and planned around all of these problems.

---

Anyway rant over, but at least in hiring I am very adamant about the candidate knowing how to get a basic website up and running and understanding NAT/Port Forwarding/HTTP(S) Proxies. Why? Well, when our customers run into issues with our software our engineers need to have the fundamentals to help troubleshoot.