|
|
|
|
|
|
by t43562
298 days ago
|
|
|
I don't have any great answer - you may not want to bother to read the rest! Just a couple of thoughts. The problem I have seen with on premises is the inability to scale up. e.g. you have a server room and you don't have enough power or AC or space to add another server. You hit a problem at some point where the cost is not linear anymore - suddenly you need a new building or some bit of super expensive equipment. Since you may not be making money at the time this happens the company might get very reluctant to blow the cash to expand just to handle 5 more users and will start suggesting that the software needs some complicated change to fit the available hardware. This might turn the software into a pile of complicated crap. In your case your customer probably thinks they have limited requirements so running it themselves is going to be no problem. It's going to be essentially a testing problem for you. For ever afterwards you will need a way to check that your system has not grown any hard dependencies on AWS and will still work in the client's setup. Every update to the system is going to require some special consideration for that customer. You won't have their data on hand to check that your migration procedure is perfect. They may decide that they don't want your latest upgrade but that means that one day there will be a big, scary jump and you won't be able to monitor it and check that it went ok. I think it's worth trying to ensure that you're solving the correct problem - if you simply made the effort to test your code on an alternate cloud service all the time to show that you have a recovery plan ... would that be enough to make the sale? |
|
|
All your points are valid and can be included in the contract: - We'll be the ones to choose the cloud provider, - We'll take servers that are big enough, - The client should upgrade their server according to our specs, - Upgrades are mandatory.
Any idea what other (simpler) recovery plans we can have besides on-premise?