Re^2: Getting pure CGI application to run under FastCGI on IIS

Thanks. This was exactly the kind of feedback I was looking for. I wish you could have said that this would be trivial, but you can't get everything :)

I also think that this conversion is something that probably has to be done, but management buy-in is going to be difficult. We have a limited amount of resources so arguing for using good chunk of our available time on this is going to be difficult. I will probably try to get it to work more or less flawlessly on a small and recently implemented part of the application as a proof of concept. Then I can use that to showcase how much more responsive the application feels and convince them to do the conversion for the rest of the application as well. Given that I can actually get it to work of course.

BTW I am still interested to hear others experience with doing this type of conversion and on getting it to work both under CGI and FastCGI.

Comment on Re^2: Getting pure CGI application to run under FastCGI on IIS

Replies are listed 'Best First'.
Re^3: Getting pure CGI application to run under FastCGI on IIS by locked_user sundialsvc4 (Abbot) on Feb 05, 2009 at 15:31 UTC
(Shrug...) So you have to make a compelling business-case for it. And then they have to decide if they want to spend the money to do it now. Or, just as likely, they may come back to you and ask how they can do some worthwhile piece of it. You of course absolutely must prove the engineering viability of the project first. And, you must establish that there is an acceptable amount of business risk, because the risk of this change is quite-substantial and “they can always throw more silicon at it.” If, and only if, both the viability and the risk-management of the proposition can be established (in the eyes of a non-technical devil's advocate), and you can come up with a believable budget and timeline (with “escape paths” that can be taken in the event of an unforseen snag), then “this is a worthy project that very-likely ought to be done.” But you're gonna be put in the dock for this one, and grilled heavily. Expect that. Fair warning: the business decision could go either way. The technical risk scares me, even from this distance. It's a big gamble if it succeeds, and a big fat “sunk cost” if it doesn't. And all of that is no reflection whatsoever upon you. In fact, I think that I would spend some time play-acting, taking the devil's advocate position yourself and arguing-like-hell that: “It would be absolutely insane to think about even touching that thing! This is our product! It's what stands between us and the unemployment line! You must be out of your mind!” Think of every possible thing that the company could do “instead,” and argue every one of those alternatives mightily. Because that's exactly what the managers are going to be wrestling with, too. Try to think of every angle. You say, for instance, that “we can host it, or we can install it on a customer site.” Uh oh... How much are all those installs gonna cost? What if a customer doesn't want to install it? What if half of them do and half of them don't? How certain are we that everyone who wants to install it will succeed in doing so? What if an obscure technical problem crops up and suddenly a happy customer turns into an unhappy one? What sort of test-plan and rollout-plan will be needed to prove that it's as stable as what we have now? Why shouldn't we let a 100,000-line sleeping dog lie? Where's that ROI now? Still there? “Good...! Is it ready yet?” `:-D`

Replies are listed 'Best First'.

Re^3: Getting pure CGI application to run under FastCGI on IIS
by locked_user sundialsvc4 (Abbot) on Feb 05, 2009 at 15:31 UTC

(Shrug...) So you have to make a compelling business-case for it. And then they have to decide if they want to spend the money to do it now. Or, just as likely, they may come back to you and ask how they can do some worthwhile piece of it.

You of course absolutely must prove the engineering viability of the project first. And, you must establish that there is an acceptable amount of business risk, because the risk of this change is quite-substantial and “they can always throw more silicon at it.”

If, and only if, both the viability and the risk-management of the proposition can be established (in the eyes of a non-technical devil's advocate), and you can come up with a believable budget and timeline (with “escape paths” that can be taken in the event of an unforseen snag), then “this is a worthy project that very-likely ought to be done.” But you're gonna be put in the dock for this one, and grilled heavily. Expect that.

Fair warning: the business decision could go either way. The technical risk scares me, even from this distance. It's a big gamble if it succeeds, and a big fat “sunk cost” if it doesn't. And all of that is no reflection whatsoever upon you.

In fact, I think that I would spend some time play-acting, taking the devil's advocate position yourself and arguing-like-hell that: “It would be absolutely insane to think about even touching that thing! This is our product! It's what stands between us and the unemployment line! You must be out of your mind!” Think of every possible thing that the company could do “instead,” and argue every one of those alternatives mightily. Because that's exactly what the managers are going to be wrestling with, too.

Try to think of every angle. You say, for instance, that “we can host it, or we can install it on a customer site.” Uh oh... How much are all those installs gonna cost? What if a customer doesn't want to install it? What if half of them do and half of them don't? How certain are we that everyone who wants to install it will succeed in doing so? What if an obscure technical problem crops up and suddenly a happy customer turns into an unhappy one? What sort of test-plan and rollout-plan will be needed to prove that it's as stable as what we have now? Why shouldn't we let a 100,000-line sleeping dog lie? Where's that ROI now? Still there? “Good...! Is it ready yet?” :-D