What to tell web developers

First, Thank you for your excellent and speedy reply. Secondly, taking a knee and paying respects to a Grand Master...

 

 

I just might have that ability to make the developers read the correct books. The power that I might achieve with being able to leverage these requirements on the developer has no bound at this moment. Though you are absolutely right on the documentation. I am so used to having a firehose and just keeping things running that I do not make the time to get that done.

 

 

I wanted to keep it general to catch any "ah-ha" type things. But I guess describing my specific environment might have help with my examples.

 

 

We have 6 locations around the globe. We have GTM doing the wide area. The main application has about 30 VIPs, going to 150 webservers, that go to about 50 Dbs. They are distributed evenly about the globe. Some of the reasoning is vague as to why, but lets see if I can sum up. The user's session must persist to a database. Each VIP has a pool of webservers that point to the same Db. Dbs are in a multimaster replication. They can be 5 minutes between sites and sometimes up to 30 minutes if congestion is bad.

 

 

On the issue mentioned before about moving from VIP to VIP during a POST happened on the wide area. I cannot visualize how cookies might help in that instance, but ready to learn.

 

 

I am not sure why we didn't try wide area persistence on the old 4.6 3DNSes, but when I tried to turn persistence on the new GTMs, we lost a VIP, but users persisted to that VIP even when it was down (by F5 design, have submitted RFE). Another Grand Master "RAHM" helped with an iRule to just persist none when LB::FAIL. He and F5 Professional services helped with an iRule layout to put an warning screen "the data you were working on may not be available until replication catches up sorry" on the VIPs so when users are moved from VIP to a different VIP they are not caught off guard. MGMT seems fine with this for the most part. The bad is there are a few application screens that take 30 minutes for the users to fill out, if they are moved in the middle, they loose 30 minutes worth of work.

 

 

Thank You,

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.