iApp suitable for a new deployment...

Hi Gavin,

I suspect that iApps might be a pretty good fit for your situation, but a few more details might help. When you say that you manage over 300 URLs for 60 applications - what does that end up looking like in the config? Is each app getting its own virtual server listening on an IP:port? Or perhaps you're using iRules to connect clients to appropriate pools based on HTTP data all arriving on a handful of virtuals. Sometimes it's easier to start with an example configuration that you would have created by hand and work backwards to see how an iApp could have been used to instantiate those configuration items and assist in managing them in the future.

Here's some answers to your questions:

A) probably - iApps are sometimes very appropriate for replacing external tooling using iControl because:

• give you a UI "for free"
• are naturally re-entrant and clean up after themselves
• let you manage your applications as applications - not as virtual servers, pools, etc

One concern I have here is whether this iApp needs to be customer-facing or if it's just for your own staff to interact with. I'd advise against v11 iApps as a customer-facing solution since it means exposing the BIG-IP GUI to them, whereas an external tool using iControl to orchestrate BIG-IPs might be cleaner/safer.

B) there are likely several ways to put this together, but the natural way that comes to mind would be building an iApp template that creates a distinct application instance for each of the applications that your customers use. That assumes that you can make one template that could handle the different applications - if that's not realistic, then perhaps several templates each with slightly different behavior might work better. In either case, I would recommend an approach where you create an application service for each customer (or for what you call an application) rather than as one big monolithic application.

C) iApps are quite suitable for handling ongoing changes - in fact this was one of its goals while in development: application lifecycle management. If you make changes via iControl, you have to be careful not to try modifying an object that doesn't exist, or creating an object that's already there - and also to delete things when you're done with them. iApps remove that burden. After initial deployment of an application service from a template, you're always able to jump right back into the template with everything as you configured it before and make small changes and adjustments on-the-fly.

Feel free to post back to this thread with more info - or let your sales team know what you're thinking about and they can loop me in that way if you want a deeper dive.

Cheers,

-Brent

ltm virtual Common/cms.wokingham.card.co.uk {
    description "Application A BackOffice"
    destination Common/172.16.26.2:https
    ip-protocol tcp
    mask 255.255.255.255
    persist {
        Common/cookie {
            default yes
        }
    }
    pool Common/applicationapool
    profiles {
        Common/HTTP_Rewrite { }
        Common/analytics { }
        Common/application_a_ssl {
            context clientside
        }
        Common/tcp { }
    }
    rules {
        Common/Catch_Errors
        Common/AccessLogging
        Common/Header_Stripping
    }
    snat automap
    vlans-disabled
}
ltm pool Common/applicationapool {
    members {
        Common/applicationanode:webcache {
            address 10.0.0.68
            session monitor-enabled
            state up
        }
    }
    monitor Common/tcp
}
ltm node Common/applicaitonanode{
    address 10.0.0.68
    session monitor-enabled
    state up
}