4 ms·
Why does anyone drive their own cars when they could instead ride in a taxi, ride Greyhound, fly, or rent a car? The simple answer is that different approaches
by BrandonM 18y ago
Why does anyone drive their own cars when they could instead ride in a taxi, ride Greyhound, fly, or rent a car? The simple answer is that different approaches are appropriate in different situations.
To actually answer your question, though, AWS really constrains the way you do things. On your own servers, you can run whatever programs you want. You can write your own server from scratch (see http://python.org/doc/1.5.2p2/lib/module-BaseHTTPServer.html http://python.org/doc/1.5.2p2/lib/module-BaseHTTPServer.html), you can run background jobs that reprocess the data sitting on your server without having to pay any extra for it, you can add memory or hard drives or double your RAID when hardware upgrades are needed, you can be confident in your backup system, etc. etc.
Personally, I have old computers around at home. I have a mostly-always-on cable connection. I have an outward-facing domain name for it thanks to http://www.dyndns.com/ http://www.dyndns.com/ -- a dynamically-updating nameserver. If I want to put up a new service and I'm not too worried about uptime, I can install lighttpd and run it on an old computer right out of my house. I can easily hook up to the live server to investigate any errors or problems I'm having.
If my service starts getting popular such that uptime is important but there still aren't a ton of visitors, I can move to a lighttpd shared hosting solution: just move the server root to the shared host. Now I have a great development platform at home (I could even point beta.mywebsite.com at it if I wanted), and I can commit tested functionality to the shared host. Do you have a nice AWS model at home that you can use to debug your AWS application?
Once uptime and bandwidth become an issue, then I can make the decision on whether it makes sense to go with a higher-tier shared hosting, a dedicated server, or with a service like AWS. In most cases, though, it's going to be hard to make AWS do everything that you need it to do. And with the necessity to have failover solutions for the three or more major outages that Amazon has every year, the need for some other solution is always going to be there.
And through all that, we haven't even touched on security or other guarantees that must be made to customers for certain applications, or on those instances where AWS is more expensive. In short, there are plenty of reasons to go with a solution that does not solely depend on AWS.