Retiring another interview question
I've been talking to people who have built cloud services that communicate with on-premises equipment (like storage arrays or routers.) One of my questions has been: "can you give me an example of some difficulties, or customer requirements, that you've encountered about the device-to-cloud communication channel?"
The clearest sign of somebody who has not deployed to production is that they don't know of any, or the best they can come up with is "use a web proxy."
Here's my list, which I'm pretty sure is incomplete.
1. Some customers want to know the exact IP address and port you will connect to, and hard-code it in their firewall. Want to change cloud service providers? Forget it. Want to scale via DNS load balancing, or add a second server in Europe? Are you really going to go back and tell all those customers to open up more holes? Probably not.
2. Customers want you to use an HTTPS proxy. (No problem, everybody expects that.)
3. The HTTPS proxy is username and password protected. (No big deal.)
4. There are multiple ways to provide the username and password to the proxy. Are all of them supported? (Oops, we didn't turn on GSSAPI/Kerberos until a customer specifically requested it.)
5. Some customers install a proxy that spoofs HTTPS, so you get a certificate mismatch. Does your code give up at that point, or ignore the error and do application-level authentication and application-level encryption? (If so, what is the point of HTTPS? Well, some customers won't support HTTP going out.)
6. Some proxies support HTTPS but not WebSockets.
7. The customer wants you to use a web proxy, and also to configure that web proxy to only allow your box access to one server.
8. An isolated storage network is standard. Some customers put the admin interface on a separate network too. (This is not too different from having no access at all.)
9. Some proxies have maximum connection lifetimes or maximum request sizes configured.
The clearest sign of somebody who has not deployed to production is that they don't know of any, or the best they can come up with is "use a web proxy."
Here's my list, which I'm pretty sure is incomplete.
1. Some customers want to know the exact IP address and port you will connect to, and hard-code it in their firewall. Want to change cloud service providers? Forget it. Want to scale via DNS load balancing, or add a second server in Europe? Are you really going to go back and tell all those customers to open up more holes? Probably not.
2. Customers want you to use an HTTPS proxy. (No problem, everybody expects that.)
3. The HTTPS proxy is username and password protected. (No big deal.)
4. There are multiple ways to provide the username and password to the proxy. Are all of them supported? (Oops, we didn't turn on GSSAPI/Kerberos until a customer specifically requested it.)
5. Some customers install a proxy that spoofs HTTPS, so you get a certificate mismatch. Does your code give up at that point, or ignore the error and do application-level authentication and application-level encryption? (If so, what is the point of HTTPS? Well, some customers won't support HTTP going out.)
6. Some proxies support HTTPS but not WebSockets.
7. The customer wants you to use a web proxy, and also to configure that web proxy to only allow your box access to one server.
8. An isolated storage network is standard. Some customers put the admin interface on a separate network too. (This is not too different from having no access at all.)
9. Some proxies have maximum connection lifetimes or maximum request sizes configured.