* Buy 75k hardware. * Two colos <= 30k yearly + full managed support. * One PT SA 45K.
That AWS budget doesn't touch scaling like the ability to scale across two sites and physical hardware for multiple years.
Would probably work just fine if they don't do anything heavyweight but just some CRUD/form processing with a billing integration and a few extras, like many websites/webapps essentially are. ;)
In this sense it's probably a reasonable to not bother about the initial infrastructure before you actually need it. Just don't tie yourself to the cloud, because it'll bite very painfully.
1. Over provisioning
2. Under provisioning, burstability
3. Prefers capex to opex
4. Requires hiring SA / IT forever
5. Changes in architecture become prohibitive
#4 is FUD. You'll hire them or some devops guy(s) anyway. $5 Architecture changes that require stack wide redesign are maybe common in your world but they aren't in mine. If you need to do this you probably need to be entirely month by month anyway.
1. Makes use of the skillset I already have (sysadmin managing servers), rather than requiring me to learn something new
2. Doesn't allow developers to build and iterate quickly without my permission / allowance
3. Allows me to be paid a salary and benefits that I will never factor into the costs when comparing to cloud infrastructure
4. Allows me to manage my own backups, deal with vendor finger-pointing, respond to and handle any hardware failures, amortize and replace hardware on some schedule, etc.
5. Allows me to pat myself on the back for ensuring the company theoretically avoids platform lock-in, which unsurprisingly results in more lowest-common-denominator architecture (servers needing managing, which of course, I'll manage), even if it greatly increases time to our minimum viable product