Why are my Directory costs so high?

In recent months I've been hammered by my client to get my costs down. "Why does it cost so much to run a Directory!?!?!" he said, and went on to threaten "The quote I got from [an India Application House] is 10% of what you're charging!!!".

Unfortunately, many application development houses don't take these conditions into consideration ... they're focused on programming, lines-of-code, and not the operational stability of something that underpins many applications. If you were to talk to them about databases, their comment is typically "well, that's handled by the database provider". That begs the question: "So then why do you think you can do it for 10% of their cost?" They thought that Directory was a black-box item which could just be installed and runs on it's own. I can assure you, this is NOT the case in the real-world.

However, my client's inquiries did make me double-think my cost-model. I called an industry-analyst earlier this year to get an idea of what an average FTE-per-Server ratio is for running Directory environments, their answer was 1:1. That seemed high to me. I further inquired "is that for a highly available directory environment, or just a single instance on a box". The answer was "the latter".

I ran numbers, and a 1:1 ratio would've caused me to go up in price, not down. Then I though about it ... "What do I do today to support my client's Directory?" and "What are my client's biggest complaints OUTSIDE of price?" I asked.

Directory servers are like Database servers ... they're middleware components that other applciations use. However, unlike databases, they're just now maturing as a major shared component in the environment. The costs to design and operate one must accomodate for constant change imposed by the applications who use them. Unbounded searches, new ACI's, Schema and DIT extensions all lead to continuous reviews, change controls, and thorough testing. When supporting a critical application, the Directory itself becomes critical, resulting in the need for high-availability designs, strict maintenance and change windows, and back-out plans. Furthermore, the tuning of the Directory can severely impact the responsiveness of the applications it supports. Unindexed searches can lead to long response times, causing more than one application to be affected. Throwing hardware at it doesn't help (e.g. who cares if it's a v880 if you've limited your instances to 2 simultaneous connections).

My client did have performance issues, stability issues, and I had been throwing bodies at it to solve this problem. This led me to think about the end-to-end support model, and I believe three items need to be considered:

1) Engineering the initial Directory solution based on requirements
2) Operatiions and Maintenance of the Directory enviornment,
3) On-Boarding Applications to the Directory environment

To gain Operational stability of your enviornment, you need to control the inputs and outputs. This means the initial design in the 1st step has to take a "assume deny" approach, prohibiting applications from utilizing the Directory unless explicitly authorized. It also has to accomodate for the service levels and expected volumes.

Operating the environment requires stringent monitoring and proactive maintenance, looking for trends and executing minor changes to further tune and optimize performance. Applications will not notice this singularly, only at the aggregate level w/in the directory will such trends be seen.

Quite often the3rd step, Application On-Boarding, is missed. Applications, once authorized to query the Directory, could still reak havoc unless they're programmed and tuned to "behave well". Often applciation developers don't give this a thought ... they'll short-cut their programming and testing by doing wild-card searches and parsing the resultant data themselves, vs. learning how to create well-formed queries to retrieve only the data they need. To prevent this, applications must run standardized tests, developed by the Directory team, to check for unindexed searches, wildcards, too-many-threads, etc. Only if the application passes would it be deployed.

Ok, so how does this relate to costing? Well, once you consider all the functions that need to be conducted, including designing, operating, maintenance, tuning, and application on-board testing, a ratio of 1:1 starts to seem reasonable. I explained this to my client, and they began to understand the periphery of work which surrounds the initial Directory design, which the [India Application House quoting at 10% my rate] hadn't even begun to comprehend.

In the end, I did come up with a repeatable cost-model (don't ask me to share the numbers), which allowed me to be more cost-competitive AND show value to my client by explaining (in more detail than I can put in this blog) why my numbers were right, and how it improves the quality and stability of their enviornment.

The moral of this blog: It's not always about the price, but about what you get for it.