What to tell web developers

I have not seen a group to post this subject so I will start here:

 

[KEVIN]: Thanks for posting.

 

 

 

I am being give an opportunity to tell our web developers how they must write code to work in a wide area load balanced environment.

 

[KEVIN]: That’s an interesting topic, but hopefully not a complex one. Ultimately a request is a request is a request. High availability (load balancing and monitoring) ensures that the requests reach a viable server. Persistence ensures that the requests reach the same server as a previous request in that session. It’s still up to the backend infrastructure to provide application session state (if so required) in case servers fail mid-session. I’d investigate:

 

 

- Intelligent monitoring of services

 

 

- Session state services provided by the various web products (IIS, Apache, etc.).

 

 

Other than that, there really isn’t much that a developer should have to do differently in a load balanced environment. That said, there are some considerations that can be made if the load balancer is taking a more active role in the application. Take authentication for example. This is a big one. Traditionally you’d have to build complex multi-factor authentication mechanisms into the applications, and considering that this is a government solutions forum, it’s a fair bet that the prescribed mechanisms aren’t always native to the applications. So abstracting those mechanisms away from the apps, like PKI and Kerberos, mean that you can often use simpler mechanisms on the back side, like HTTP headers. This is something the developers would need to know about.

 

 

 

We have had issues in the past where the "create user" web page would get load balanced to two different websites during the creation process so it would have the same user in two different active directory controllers. When AD tried to replicate, it failed and shut down services from AD. Ugly situation, but ...

 

[KEVIN]: Isn’t this just a persistence issue that could be easily resolved with a cookie?

 

 

 

what else have you seen that might be helpful in telling them what not to do in their code?

 

[KEVIN]: I’m going to resist the urge to pull out my soapbox… The real magic of BIG-IP, IMHO, is not the ADC stuff. It’s the flexibility aspect. It’s what systems engineers rely on day-to-day to make applications, all applications, just work. There’s no common background, philosophy, or set of rules that all developers subscribe to, and as such, every application is different. And by “different”, I mean unique, interesting, and sometimes mind-boggling. So while I’d love to get every developer in your organization to read the same books and follow the same set of “rules”, that just isn’t going to happen. I have found in my own past, that if there’s something specific that needs to be done to support the load balanced environment (iRules, HTTP headers, etc.), you should document it (verbosely) in a language that the developers can understand.

 

 

 

I have started with my sales guys, and Professional services - they say something to the effect "we just make it work through the F5", but given an opportunity such as this, I could prevent alot of issues (and that is what MGMT is expecting to occur)

 

[KEVIN]: My advice: define and document your application objectives, inputs, outputs, architecture, and service levels. Get everyone in a room and talk about expectations, timelines, and deliverables. Treat objects (clients, servers, load balancers, etc.) as abstracts with defined inputs and outputs and let each party define what goes inside their respective abstracted objects. Also use this opportunity to ferret out capabilities/incapabilities. This is where BIG-IP will often come to the rescue.